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. 3
The DNS…

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. 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. 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. 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. 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
Attacking the DNS…

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. 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
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
Defenses…

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. 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. www.root-servers.org
16

17. How can we defend the Root?
• Larger Root Server platforms?
• More Root Server Letters?
• More Anycast Instances?
• Change DNS behaviour?
17

18. 18
DNSSEC…

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 – 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

23. 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

24. 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

25. 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

26. 26
The good news

27. 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

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. 29
Thanks
dg@apnic.net