CoreDNS behavior is plugin-driven, so hardening depends on safe plugin selection, network isolation, and strict update control. This guide provides security best practices for CoreDNS deployments.
- Enable only required plugins in
Corefile
- Remove experimental or debug plugins in production
- Review plugin behavior for external fetches or metadata exposure
- Audit third-party plugins for security vulnerabilities
- Keep a minimal plugin set to reduce attack surface
- Configure plugins with secure defaults
- Limit resource consumption with appropriate timeouts
- Validate inputs to plugins that accept external data
- Use ACL plugin to restrict access to sensitive plugins
- Bind to specific interfaces instead of all interfaces (0.0.0.0)
- Use localhost binding for administrative endpoints
- Separate internal and external DNS services if needed
Example:
127.0.0.1:53 {
# Internal queries only
file /etc/coredns/internal.db
}
- Allow only necessary ports (typically 53/UDP and 53/TCP)
- Restrict access to metrics and health endpoints
- Implement rate limiting at the network level
- Use IP whitelisting for administrative access
- Enable DNS over TLS (DoT) or DNS over HTTPS (DoH) for encrypted transport
- Use DNSSEC to validate responses
- Implement response rate limiting to prevent abuse
¶ Authentication and Authorization
Use the ACL plugin to control access based on source IP:
acl {
allow net 10.0.0.0/8
allow net 192.168.0.0/16
block
}
For secure zone transfers and dynamic updates:
.:53 {
tsig keyname {
algorithm hmac-sha256
secret <base64-encoded-secret>
}
transfer {
to * 10.0.0.10
}
}
- Run containers with minimal required capabilities
- Use non-root user when possible
- Implement read-only root filesystem where appropriate
- Mount only necessary volumes
Example secure Docker run command:
docker run -d \
--name coredns \
--security-opt=no-new-privileges:true \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
--read-only \
--tmpfs /tmp \
-p 53:53/udp \
-p 53:53/tcp \
-v $(pwd)/Corefile:/etc/coredns/Corefile:ro \
coredns/coredns:1.14.1 -conf /etc/coredns/Corefile
- Use official CoreDNS images from trusted sources
- Pin to specific versions instead of using ‘latest’
- Scan images for vulnerabilities regularly
- Keep images updated with security patches
¶ User and Permissions
- Run CoreDNS as a dedicated non-root user
- Use systemd drop-in files to set capabilities
- Limit file system access to necessary directories only
- Implement proper file ownership and permissions
- Disable unnecessary system services
- Implement SELinux/AppArmor policies if available
- Use kernel security modules for additional protection
- Monitor system logs for suspicious activity
- Enable DNSSEC validation for recursive queries
- Sign authoritative zones with DNSSEC
- Maintain proper key management practices
- Monitor for DNSSEC validation failures
CoreDNS doesn’t have a built-in rate limiting plugin in the core distribution. For rate limiting, consider these approaches:
Option 1: Use external plugins
.:53 {
# External ratelimit plugin (requires custom build)
forward . 8.8.8.8
}
Option 2: Implement at network level
- Use iptables/nftables for rate limiting
- Deploy behind a rate-limiting proxy
- Use firewall rules to limit DNS query rates
Option 3: Use the any plugin to block amplification attacks
.:53 {
any # Block ANY queries to prevent amplification
forward . 8.8.8.8
}
- Use DNSSEC validation
- Implement proper cache management
- Monitor for unusual query patterns
- Use multiple upstream resolvers
¶ Monitoring and Logging
- Enable logging
- Monitor for unusual query patterns
- Track SERVFAIL rates and error conditions
- Alert on configuration changes
- Protect log files from unauthorized access
- Implement log rotation and retention policies
- Use centralized logging for analysis
- Encrypt logs in transit if sent remotely
Example logging configuration:
.:53 {
errors
log {
class all
}
prometheus :9153
# Additional security monitoring plugins
}
- Apply principle of least privilege
- Use dedicated service accounts for CoreDNS
- Limit API access to necessary resources only
- Regularly audit RBAC permissions
- Implement network policies to restrict traffic
- Isolate CoreDNS from unnecessary network segments
- Use pod security policies/standards
- Monitor inter-pod communication
- Establish a patch management process
- Test updates in staging before production
- Subscribe to security mailing lists
- Monitor for CVEs affecting CoreDNS
¶ Backup and Recovery
- Regularly backup configuration files
- Test backup restoration procedures
- Store backups securely
- Document recovery procedures
- Develop incident response procedures for DNS outages
- Monitor for DNS-based attacks
- Have rollback procedures ready
- Coordinate with upstream providers during incidents
- Minimize logging of client IP addresses if privacy regulations apply
- Implement data retention policies
- Anonymize logs where possible
- Follow GDPR, CCPA, or other applicable regulations
- Maintain configuration change logs
- Document security controls
- Regular security assessments
- Compliance reporting procedures
- Regular scanning of CoreDNS deployments
- Penetration testing of DNS infrastructure
- Automated security testing in CI/CD pipelines
- Third-party security audits
- Regular review of Corefile configurations
- Automated compliance checking
- Security configuration templates
- Peer review of security-critical changes
Severity: High (CVSS 7.5)
Fixed in: CoreDNS 1.14.2
Impact: Denial of Service via predictable loop detection
The loop detection mechanism used insufficiently random values, allowing attackers to potentially bypass loop detection and cause denial of service.
Mitigation:
- Upgrade to CoreDNS 1.14.2 or later
- Monitor for loop detection bypass attempts
Severity: Critical
Fixed in: CoreDNS 1.14.2
Impact: Access Control List bypass allowing unauthorized DNS queries
An ACL bypass vulnerability allows remote attackers to circumvent access control restrictions and perform unauthorized DNS queries.
Mitigation:
- Upgrade to CoreDNS 1.14.2 or later
- Review ACL configurations after upgrade
- Implement network-level access controls as defense-in-depth
Severity: Medium (CVSS 6.6)
Fixed in: CoreDNS 1.14.0
Impact: Denial of Service via memory exhaustion
A denial-of-service vulnerability allows unauthenticated remote attackers to exhaust server memory by opening unlimited concurrent connections to gRPC, HTTPS, and HTTP/3 servers.
Mitigation:
- Upgrade to CoreDNS 1.14.0 or later
- Configure connection/stream limits in configuration
- Implement network-level rate limiting
Reference: GHSA-527x-5wrf-22m2
Fixed in: CoreDNS 1.14.1
Impact: Go runtime vulnerabilities
These CVEs affect Go versions prior to 1.25.6 and 1.24.12. CoreDNS 1.14.1 is built with patched Go versions to address these security issues.
Mitigation:
- Upgrade to CoreDNS 1.14.1 or later
Severity: High
Fixed in: CoreDNS 1.13.1
Impact: DoQ memory exhaustion via stream amplification
A vulnerability in DNS over QUIC (DoQ) allows attackers to cause memory exhaustion through stream amplification attacks. Remote attackers can exploit the QUIC protocol’s stream multiplexing to trigger excessive memory allocation.
Mitigation:
- Upgrade to CoreDNS 1.13.1 or later
- Limit concurrent QUIC streams if DoQ is enabled
- Monitor memory usage on DoQ-enabled endpoints
Severity: High
Impact: DNS cache pinning via etcd Lease ID confusion
A vulnerability in the etcd plugin allows DNS cache pinning attacks through etcd lease ID confusion. Attackers can manipulate lease IDs to cause stale or incorrect DNS records to persist in the cache.
Mitigation:
- Upgrade to CoreDNS 1.13.0 or later
- Review etcd lease configurations
- Monitor for anomalous cache behavior
CoreDNS has undergone multiple independent security audits:
- Cure53 (March 2018) - First independent security audit conducted by the renowned German security firm Cure53. The audit identified several vulnerabilities that were subsequently addressed.
- Trail of Bits (March 2022) - Comprehensive security assessment by Trail of Bits, focusing on the plugin architecture, core DNS processing, and cloud-native deployment security.