DNS & DNSSEC operational best practices - Sleep better at night with KINDNS in your network
0 likes33 views
The Domain Name System (DNS) is a critical part of the Internet infrastructure. DNS translates the domain names of websites and email addresses that people can remember to the IP addresses that computers can understand. It is a large distributed system with many moving parts. KINDNS is simple framework for stable and secure DNS operations. The KINDNS guidelines are current best practices for DNS operators to improve the security and reliability of their operations.
![Sign your zones
• Avoid administrative overhead of resigning zones
– BIND does that automatically
zone "example.com" in {
type master;
file ”db.example.com";
key-directory "/etc/bind/keys";
inline-signing yes;
auto-dnssec maintain;
};
Where named should look
for the DNSSec key files
BIND keeps unsigned zone
and creates a signed zone
off
allow
maintain
Default. Keys are managed manually
Allows uploading keys and resigning the zone
when user runs “rndc-sign [zone-name]”
Same as “allow” +automatically
adjusts the keys on schedule](https://image.slidesharecdn.com/kindns-bdnog-2025-v117459835921-250523172450-e8c40ea4/85/DNS-DNSSEC-operational-best-practices-Sleep-better-at-night-with-KINDNS-in-your-network-27-320.jpg)
DNS & DNSSEC operational best practices - Sleep better at night with KINDNS in your network
- 1. DNS & DNSSEC operational best practices Sleep better at night with KINDNS in your network! These materials are licensed under the Creative Commons Attribution 4.0 International licence. http://creativecommons.org/licenses/by/4.0/
- 2. Acknowledgements • NSRC funds my time and my travel • KINDNS is an ICANN initiative
- 3. Enough about me. Who are you? • A quick round of introductions. • What are your hopes and dreams?
- 4. KINDNS: background KINDNS /ˈkaɪndnəs/ (noun) Knowledge-Sharing and Instantiating Norms for DNS and Naming Security A simple framework that can help a wide variety of DNS operators, from small to large, to follow both the evolution of the DNS protocol and the best practices that the industry identifies for better security and more effective DNS operations. See also: https://kindns.org
- 5. What kind of DNS operator are you? • KINDNS “core guidelines” for everyone • Additional guidelines for different deployments: – TLDs and critical zones – Public recursive resolvers – Other second-level domains – Shared recursive resolvers – Private infrastructure not reachable from the open internet • No “One Size Fits All” checklists!
- 6. KINDNS: targeted operators Authoritative operators Resolver operators TLDs & critical zones SLDs Closed & private Shared private Public Hardening the core system By joining the KINDNS initiative, DNS operators are voluntarily committing to adhere to the identified practices and act as “goodwill ambassadors” within the community.
- 7. CORE GUIDELINES (FOR EVERYONE) Basic common-sense guidelines for DNS operations of all shapes and sizes
- 8. Core guidelines (for everyone) 1. ACLs restrict traffic to DNS servers 2. BCP38 egress filtering 3. DNS servers run DNS and nothing else 4. Access to DNS servers by DNS operators only 5. DNS configuration in revision control 6. Restrict access to management interfaces 7. Management access control with cryptographic keys or 2FA 8. User access control following sound credential management
- 9. ACLs restrict traffic to DNS servers • Only permit DNS traffic inbound – TCP & UDP 53 – If DoT also 853 – If HTTPS also 443 • Only permit necessary outbound traffic – Software updates – NTP – DNS • Explicitly block bogon origins – Even if blocked at the edge (defence in depth)
- 10. BCP38 • We should not need a slide about this in 2024!
- 11. DNS servers run DNS and nothing else • Anything not related to DNS should not be installed • But you must monitor your DNS installation – Anything you need to monitor can be installed – Restrict access to monitoring per best practices
- 12. DNS configuration in revision control • See also my “Git for everyone” presentation ☺
- 13. Credential management • No user accounts • Restrict access to management interfaces • Management access control with cryptographic keys or 2FA • User access control following sound credential management
- 14. RECURSIVE RESOLVER OPERATORS DNSSEC validation is easy – turn it on already!
- 15. Best practices 1. DNSSEC validation must be enabled 2. Restrict client access to your networks 3. QNAME minimisation must be enabled 4. Resolvers must not coexist with authoritative DNS servers 5. You must have at least two recursive resolvers 6. Monitor your DNS infrastructure 7. (Bonus) DoT and DoH should be supported
- 16. DNSSEC in a nutshell 1. I know NS of com. — Cached 2.Do I know example.com.? — No! 3. Send query to TLD server ... wait 5 “.” Root Server Recursive Resolver “example.com.” Authoritative Server “.com.” TLD Server Client (Stub Resolver) What is the IPv6 address of www.example.com? 1 1.Do I have answer in cache? — No! 2.Do I have a resolver? – Yes! 3.Query: www.example.com. AAAA 4.Send to recursive resolver ...wait 2 1. Do I have answer in cache? — No! 2.Do I know example.com.? — No! 3. Send query to root server ... wait 3 1. Do I know www.example.com.? — No! 2.Do I know com.? — Yes! 3. Reply: com. nameservers’ IPs 4 1. Do I know www.example.com.? — No! 2.Do I know example.com.? — Yes! 3. Reply: example.com. Nameservers’ IPs 6 1.I got AAAA of www.example.com.— Cache 2.Reply: AAAA of www.example.com is 2001:db8::80 9 1. Do I know www.example.com. AAAA? — Yes! 2.Reply: AAAA of www.example.com is 2001:db8::80 8 1.Return AAAA of www.example.com 2. Store in cache for TTL seconds 10 2 9 3 5 6 7 8 Query? Response! 7 1. Know NS of example.com.— Cache 2.Send query to nameserver ... wait 4 Recursive Resolver is prepopulated with root DNS server addresses and the root’s public key root key Set DO bit +DS,RRSIG,DNSKEY +DS,RRSIG,DNSKEY +RRSIG,DNSKEY Set AD bit com key example key root pubkey Set DO bit Set DO bit Set DO bit Diagram credit: Md Abdul Awal
- 17. Enabling DNSSEC • BIND: on by default • Unbound: on by default • PowerDNS: on by default • Windows DNS: on by default (allegedly) (but…) If you don’t turn it off, it will Just Work!
- 18. Enabling DNSSEC (2) • There is no reason to turn off DNSSEC validation. Ever.
- 19. Split-horizon DNS & other edge cases (1) • Separate DNS views usually a net-negative – Consider your need • Alternative 1: Internal sub-domain – Sign as normal – Do not resolve outside organisation – See relevant KINDNS guidelines • Alternative 2: Separate internal domain – Sign as normal too
- 20. Split-horizon DNS & other edge cases (2) • If you absolutely must use split-horizon – Don’t sign two copies of your zone! – Authenticated denial of existence will bite you • Consider an internal root of trust – Must deploy trust anchor to all internal hosts
- 21. Restrict access to your networks • Don’t be an open resolver! • ACL DNS queries at the edge if you can • Defence in depth: drop queries on your DNS servers too • (Include BIND/unbound/PowerDNS config files)
- 22. Enable QNAME minimisation • BIND: on by default • Unbound: on by default • PowerDNS: on by default • Windows DNS: no support Cannot run KINDNS-compliant recursive DNS on Windows (but why would you want to try…?)
- 23. Availability and resilience • Resolvers must not coexist with authoritative DNS servers • You must have at least two recursive resolvers • Monitor your DNS infrastructure
- 24. Monitoring • All infrastructure must be monitored • Remember to monitor both success & failure cases – Test your monitoring • Common metrics – Latency – Known-good responses – DNSSEC “AD” bit
- 25. AUTHORITATIVE ZONE OPERATORS DNSSEC is not optional. It’s not as hard as it looks.
- 26. Best practices 1. Zones must be DNSSEC signed 2. Zone transfers must be restricted to your secondaries 3. Zone file integrity must be monitored 4. Authoritative DNS servers must not coexist with resolvers 5. Your zone must have at least two authoritative resolvers 6. Monitor your DNS infrastructure
- 27. Sign your zones • Avoid administrative overhead of resigning zones – BIND does that automatically zone "example.com" in { type master; file ”db.example.com"; key-directory "/etc/bind/keys"; inline-signing yes; auto-dnssec maintain; }; Where named should look for the DNSSec key files BIND keeps unsigned zone and creates a signed zone off allow maintain Default. Keys are managed manually Allows uploading keys and resigning the zone when user runs “rndc-sign [zone-name]” Same as “allow” +automatically adjusts the keys on schedule
- 28. Zone file integrity Primary server Secondary server Dynamic Update Query/Response (Secondary server) Resolver Client (Stub Resolver) Zone data synchronization Update Station Query/Response (Primary server) Zone File Zone data access DNS Query/Response Cache impersonation Unauthorized updates Corrupting Data Impersonating master Cache pollution by data spoofing Data protection Server protection
- 29. Availability and resilience • Authoritative DNS servers must not coexist with resolvers • You must have at least two authoritative servers for your zone • Monitor your DNS infrastructure
- 30. CCTLDS AND CRITICAL ZONES Focus on resilience
- 31. Best practices – same as authoritative 1. Zones must be DNSSEC signed 2. Zone transfers must be restricted to your secondaries 3. Zone file integrity must be monitored 4. Authoritative DNS servers must not coexist with resolvers 5. Your zone must have at least two authoritative resolvers 6. Monitor your DNS infrastructure
- 32. Separation of duties • Authoritative servers must not provide recursive service
- 33. At least two distinct name servers • This is usually a requirement for leaf zones too – but especially important for ccTLDs and critical zones. • Should go without saying: your name servers must always be in sync. • Ideally these will be anycast clouds.
- 34. Software diversity • Run different software stacks in your organisation – FreeBSD, Linux, Solaris,… maybe not Windows – BIND, NSD, Knot, PowerDNS • A critical bug in Linux or BIND should not compromise your operations • Remember to give each software stack equal exposure • Automation makes things a little bit easier
- 35. KINDNS SELF-ASSESSMENT Assess your operational practices and correct/adjust unaligned practices
- 36. KINDNS enrolment • Operators can enrol to participate in one or many categories covered by KINDNS – Participation in KINDNS means voluntarily committing to implement and adhere to agreed norms and practices – Participants become goodwill ambassadors and promote best practices
- 37. Join the KINDNS initiative! • KINDNS mailing list operated by ICANN: kindns-discuss@icann.org • KINDNS wiki: https://community.icann.org/display/KINDNS