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: 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
Severity: High
Fixed in: CoreDNS 1.13.0
Impact: DNS cache pinning via etcd Lease ID confusion