This weekend I attended the DNS-OARC workshop being held as a pre-meeting before the RIPE 70 meeting in Amsterdam. What became immediately apparent from this two-day series of presentations were the huge changes which the DNS has had to accommodate since its inception in the early 1980s.
Talks covered a range of issues emerging in the modern-day DNS.
- How do we operate widely distributed (anycast) DNS services, taking over 1 million queries per second?
- What kinds of mitigation against DNS denial-of-service and other attacks can we deploy, without damaging the core services the DNS represents to the world?
- We need to make significant changes to how we secure DNSSEC, which have risks of transition. How are we going to handle this?
- How can we coordinate law enforcement and other agencies interested in the anti-social behaviours being seen worldwide abusing the DNS?
- How does modern DNS behave? What are resolvers actually doing?
As originally envisioned, the DNS was a small, lightweight UDP-based protocol to provide the obviously required ‘name’ service: translate names humans can deal with, into the numerical and encoded information networks need to route packets. Originally, we had been living inside a simple name-to-value lookup in a file called HOSTS.TXT which was centrally maintained, and could be fetched by hand (or a script for the brave) and updated periodically. The file was not indexed, you searched it linearly. This had some amusing consequences: if (like I was) you worked at a location whose name was at the “back” of the alphabet (like University College London) then the time it took to search exhaustively this list, could exceed the time delay built into the telnet server: you literally couldn’t log into a remote node, because it took too long to look up your address at the login prompt!
DNS was borne into the world of mainframes, and multi-second delays to send packets. But DNS has remained with us as we move into a world of ubiquitous hand-held devices and unconstrained always-on microsecond speed networks. And its core has remained remarkably constant across that time.
But times are changing.
- We need to move from small UDP packets with query and response, to (probably) small query packets, but demonstrably larger responses. Many will have to flow over TCP not UDP, and incur more overheads on the system as a whole
- We need to move to signed DNS (DNSSEC) to ensure we aren’t being told lies in the DNS, and to provide the secure underpinnings to other activities built on top of trust in the DNS. DNSSEC is vital, but we did not completely specify many critical parts of DNSSEC which relate to the management of secure DNS: when we “roll” keys to a new signing, we have risks of leaving people stranded on the old keys because we don’t know how many understand the RFC5011 ‘key rollover’ signalling. And we have unavoidably hit the time where we need to roll the one key, the lord of the keys at the root of the DNS, over all other DNS keys.
This is going to be fun!
Lots of good presentations got made, and we’re encouraging the DNS-OARC workshop participants to consider proposing talks for future APNIC meetings so they can share the stories in detail in our region. Watch this space!
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.