An Overview of Secure Name Resolution

DNSSEC uses public-key cryptography to sign (not encrypt) public data in the Domain Name System. With knowledge of the root public key resolvers (DNS clients) can verify names along a chain of trust. A new type of resource records allows for secure denial of existence of mistyped names.

Deployment of DNSSEC proceeds gradually. The root zone is signed since July 2010 and the major top-level domains support DNSSEC, though most second-level domains are unsigned. .br, .cz, .nl and .se have >10% of their domains signed. An estimated 70-80% of the queries seen at authoritative nameservers originate from resolvers that are capable of parsing DNSSEC answers but this does not imply that validation is enabled (or works) on all of them. About 5-10% of Interwebz clients are using validating resolvers, with CZ, SE and US having validation ratios of >10%. Current operating systems do not support DNSSEC validation and thus rely on full-blown nameservers in the local network or at the ISP's premises. The last mile between OS and validating nameserver is currently not secured by DNSSEC.

Implications of DNSSEC deployment:

• CPU and network load increases on resolvers and nameservers.
  • Amplifications attacks become more effective: rate-limiting nameserver responses will be a must-have in future.
• Complexity increases: expect new bugs.
• Rogue DNS redirects become impossible.
  • Zensurursula-like attack won't redirect to government STOPP website, but block the website without notice.
  • NXDOMAIN response redirected by ISP to spam website will look (almost) like it originally should.
  • Collateral damage caused by China DNS injection will decrease if you have alternative transit pathes.
• If a domain administrator fails over his DNSSEC configuration, validating ISPs will be blamed for blocking. Expect outages of large sites.

DNSCurve is an alternative concept to secure DNS. While DNSSEC sticks to the original idea of shoving around resource records and preserving forwarders in the query path, DNSCurve uses a secured direct connection between the recursive nameserver and the authoritative nameserver. Using link-level security has the benefits of abandoning amplification attacks, encrypting the communication and hassle-free negative responses, but the down-sides of losing multi-hop caching and the necessity for online signing on authoritative nameservers. DNSCurve carries the public key in self-authenticating domain names instead of dedicated resource records.

Namecoin is an experimental adoption of the Bitcoin concept to domain names. Miners invest computation time to acquire Namecoins and can use them to register and refresh domain names. The namespace of Namecoin is flat and Namecoin suffers from the same scalability issues as Bitcoin does, but enables a peer-to-peer naming system that can not be controlled by a centralized instance. For secure name resolution, resolvers need to participate in the Namecoin peer-to-peer system.

References from Slides

1. DNSCurve: The nsec3walker tool, 2011-01-03
2. ICANN: TLD DNSSEC Report, 2012-12-26
3. Registro.br: Domínios Registrados por DPN, 2012-12-26
4. VeriSign: Domains Secured with DNSSEC, 2012-12-26
5. CZ.NIC: Statistics, 2012-12-25
6. PowerDNS: Total number of DNSSEC delegations in the .NL zone, 2012-12-01
7. SIDN: Statistics, 2012-12-01
8. .SE: Domain Growth per Type, 2012-12-26
9. RFC 3514: The Security Flag in the IPv4 Header, 2003-04-01
10. RIPE NCC: Status for k.root-servers.net, 2012-08-09
11. Comcast DNS: Analysis of NASA.GOV Validation Failure, 2012-01-24
12. Simon McCalla: DNSSEC incident report, 2010-09-24
13. Keith Cowing (NASA Watch): Comcast Blocks Customer Access to NASA.gov, 2012-01-18
14. P. Vixie, V. Schryver: DNS Response Rate Limiting (DNS RRL), 2012-06
15. Ondrej Caletka: Wildcard domains DNSSEC resolver test
16. Red Hat Bugzilla: Bug 824219
17. Anonymous: The Collateral Damage of Internet Censorship by DNS Injection, 2012-07-03
18. P. Eckersleyer & J. Burns: Is the SSLiverse a Safe Place?, 2010
19. RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA, 2012-08
20. RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
21. Image credit: Microsoft Bing Maps
22. Image credit: Terremark Inc.
23. Image credit: Kim Davies, KSK Ceremony 1, 2010-06-16
24. Image credit: ICANN, <http://data.iana.org/ksk-ceremony/>
25. Fingerprint of root KSK as of 2012-12-26: “. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5”
26. Jakob Schlyter: Hardware Security Modules
27. T. Okubo et al.: DNSSEC Practice Statement for the Root Zone ZSK operator, 2010-05-28
28. <http://dnscurve.org/>
29. Matthew Dempsky: DNSCurve: Link-Level Security for the Domain Name System, 2010-02-26
30. Image credit: <http://root-servers.org> & Google Maps, 2012-12-27
31. <http://dot-bit.org>
32. Matthäus Wander: How Bitcoin Works, 2011-06-29
33. Zooko Wilcox-O'Hearn: Names: Decentralized, Secure, Human-Meaningful: Choose Two, 2003-09-22
34. Image credit: Sven Wolter, Wikimedia Commons