Download to read offline
Uploaded byAPNIC
bdNOG 7 - Re-engineering the DNS - one resolver at a time
The document discusses the vulnerabilities of the DNS and root servers to DDoS attacks and outlines current and proposed mitigation techniques, including the use of DNSSEC and anycast. It highlights the importance of caching in DNS resolution and introduces RFC proposals for improving efficiency and security. APNIC's involvement in initiatives to enhance DNS resilience, particularly through collaboration and updates, is also emphasized.
More Related Content
Similar to bdNOG 7 - Re-engineering the DNS - one resolver at a time
![Understanding and Deploying DNSSEC, by Champika Wijayatunga [APRICOT 2015]](https://cdn.slidesharecdn.com/ss_thumbnails/dnssec-final1425360815-150318234332-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]](https://cdn.slidesharecdn.com/ss_thumbnails/dnssec-cw1410840227-140916002907-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
bdNOG 7 - Re-engineering the DNS - one resolver at a time
- 1. 1 Re-engineering the DNS –One Resolver at a Time Paul Wilson Director General APNIC …channeling Geoff Huston APNIC Chief Scientist
- 2. In this presentation… •the DNS, and root servers in particular • vulnerabilities of the DNS to DDoS attack, and current mitigations • new mitigation techniques relying on DNSSEC • a recent initiative by APNIC to try and improve the situation. 2
- 3.
- 4. DNS naming • TheDomain Name System (DNS) is a distributed database representing the hierarchical structure of domain names • DNS names read left-to-right 1. The “www” service 2. In the “bdnog” domain 3. In the “org” TLD www.bdnog.org.
- 5. DNS delegation • TheDNS involves delegation of authority from the “root” registry, to a top-level domain, to a domain owner. • DNS delegations read right-to-left 1. The “root” or “.” zone… 2. Delegates to authority for ”org”… 3. Delegates to authority for ”bdnog”… 4. Defines terminal label “www” www.bdnog.org.
- 6.
- 7. DNS caching • Fullresolution of DNS names is expensive! • Recursive name servers use caches to remember recent query results – This decentralises the DNS “database” across millions of servers – The root server is only queried when a domain name, and its parent zone, are not cached in local name caches • Name servers can cache “no-such-name” NXDOMAIN results – However, the vast majority (66%) of queries to the root zone servers still generate a NXDOMAIN response
- 8.
- 9.
- 10. How to beBad 10 If an attacker can prevent the root servers from answering queries then the entire DNS will suffer! Every DNS resolution starts with a query to the root!
- 11. How to beBad 11 But caching ensures that the DNS is distributed and the root servers are shielded. To reach the root servers you need to get past DNS resolver caches. This can be done by querying for non-existent names, which creates the opportunity for a DDoS attack.
- 12. 12 Root Servers area highly visible attack target If root servers can be effectively attacked, resolvers will stop getting answers from the root, and will stop answering queries as their local cache expires. This will cause a DNS outage and major disruption.
- 13.
- 14. How can wedefend the Root? • Larger Root Server platforms? • More Root Server Letters? • More Anycast Instances? 14 1. DDoS attacks are growing faster than upgrades can handle 2. Limit of 13 distinct servers within UDP packet constraint. In any case more letters will not help!
- 15. Anycast Root Servers •12 of the 13 root server operators use “anycast” – All the servers in a constellation share the same public IP addresses – The routing system will direct queries to the “closest” server • Anycast provides… – Faster responses to queries to the root for many DNS resolvers – Greater resilience by load sharing widely distributed attacks across the entire anycast constellation • As root server load increases, we keep on adding more instances to the existing anycast clouds – Is it scalable?
- 16.
- 17. How can wedefend the Root? • Larger Root Server platforms? • More Root Server Letters? • More Anycast Instances? • Change DNS behaviour? 17
- 18.
- 19. DNSSEC changes Everything •Before DNSSEC we assumed that if we queried a root server, then the response was genuine • With DNSSEC, a signed response assures us that the answer is genuine • Because it is signed, that response can come from anywhere • How can we use this?
- 21. RFC7706 – Localrootserver • RFC7706 proposes the use of a local rootserver, carrying a local copy of the root zone • DNSSEC signing ensures the root zone is valid • However: – Significant operational overhead in maintenance of this server – Fragility in case of failure of server, or failure to update the root zone
- 23. RFC 8198 –NSEC caching • 66% of queries seen at the root are for non-existent domains, due to limited caching of “non-existent” domain names. • With DNSSEC, the NSEC record type (Next-SECure) allows entire ranges of non-existent names to be reliably identified. • If resolvers cache this range and the signed response, they can then answer a query (negatively) for any name that falls within it. • This will prevent queries for non-existent domains from being passed to the root and other nameservers
- 24. Example If we querythe root server for the non-existent name www.example. the returned response says that there are NO TLDS between everbank. and exchange. The identical response can be used to respond (negatively) to queries for any TLD between these labels. So we can cache this signed response and use it to respond to subsequent queries that fall into the same range. Name server software upgrade is required, but no operational impact in involved. 24
- 25. Impacts… • Instead ofrelying on endless scaling of the root server system, existing deployed resolvers can help mitigate DNS DDoS attacks • This will also improve overall DNS efficiency by absorbing most of the current root query load in the resolvers • Also, individual resolvers will operate more efficiently in both response time (for failed queries) and cache performance. • Win, Win, Win! 25
- 26.
- 27. Coming to aBind Resolver near you • APNIC has sponsored the inclusion of NSEC caching in the forthcoming Bind 9.12 release – Enabled by default – Available early 2018 • Then… – To be included in Linux distros – Replicated in other DNS resolvers? – Operators must upgrade: OS or Bind, or both
- 28. In the meantime •Anycast rootserver deployment continues – At request of rootserver operators, since recent attacks • APNIC working with F, I, K, M – Especially at neutral IXPs – Especially in developing countries • Let APNIC know if we can help • Stay tuned! 28
- 29.