Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Re-Engineering the DNS – One Resolver at a Time

62 views

Published on

Re-Engineering the DNS – One Resolver at a Time

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Re-Engineering the DNS – One Resolver at a Time

  1. 1. 1 Re-engineering the DNS – One Resolver at a Time Paul Wilson Director General APNIC …channeling Geoff Huston APNIC Chief Scientist
  2. 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. 3. 3 The DNS…
  4. 4. DNS naming • The Domain 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. 5. DNS delegation • The DNS 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. 6. 104.28.22.118 DNS resolution 6 Root server 198.41.0.4 www.bdnog.org? Local server 10.128.128.128 .org server 22.123.1.1 .bdnog.org server 63.128.0.1 A 104.28.22.118 10.128.1.15
  7. 7. DNS caching • Full resolution 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 • NOTE, name servers don’t cache names that don’t exist – The vast majority (66%) of queries to the root zone servers generate a “no-such-name” (NXDOMAIN) response
  8. 8. Local server 10.128.128.128 104.28.22.118 DNS caching 8 Root server 198.41.0.4 www.bdnog.org? .org server 22.123.1.1 .bdnog.org server 63.128.0.1 A 104.28.22.118 10.128.1.15
  9. 9. 9 Attacking the DNS…
  10. 10. How to be Bad 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. 11. How to be Bad 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. 12 Root Servers are a 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. 13. 13 Defenses…
  14. 14. How can we defend 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. 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. 16. www.root-servers.org 16
  17. 17. How can we defend the Root? • Larger Root Server platforms? • More Root Server Letters? • More Anycast Instances? • Change DNS behaviour? 17
  18. 18. 18 DNSSEC…
  19. 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?
  20. 20. RFC7706 – Local rootserver • 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
  21. 21. RFC 8198 – NSEC caching • 66% of queries seen at the root are for non-existent domains, due to non- caching of “non-existent” domain names. • DNS does provide the NXT record type to allow non-existent ranges to be identified. • With DNSSEC, the NSEC record type (Nxt-SECure) is a signed version of the NXT record, allowing these non-existent ranges to be reliably identified. • If resolvers cached this range and the signed response, they can then answer a query (negatively) for any name that falls within the same label range. • This will prevent queries for non-existent domains from being passed to the root and other nameservers
  22. 22. Example If we query the 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
  23. 23. Impacts… • Instead of relying 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
  24. 24. 26 The good news
  25. 25. Coming to a Bind 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
  26. 26. 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
  27. 27. 29 Thanks dg@apnic.net

×