[Podcast] DNS cold start

In this episode of PING, APNIC Chief Scientist Geoff Huston and I discuss how the DNS behaves during a 'cold start', when a resolver's cache contains no data from previous queries. The discussion was prompted by a talk from Ondřej Surý that Geoff attended in the DNS Working Group at the recent RIPE 92 Meeting in Edinburgh.

A cache is where you keep information from previous work. It's a fundamental technique in computer science for overcoming the large speed differences between parts of a system. Frequently used data is kept in fast memory close to the CPU, avoiding the need to retrieve it from slower memory, or worse, from disk or tape storage. The size and performance of a cache can have a significant impact on overall system speed. Comparing CPU performance with and without cached data is a good way to demonstrate its value.

In DNS, caching avoids waiting for a remote system to respond over the network, with all the associated round-trip delays. Instead, answers can often be constructed from information retained from previous queries and responses.

Cold start is a well-known problem in large distributed systems. The challenge is not unlike that faced by power generators. Industrial systems such as coal-fired plants and gas turbines need time to start up, but during a so-called 'black start' they face an additional problem: Energizing the generator's magnetic field coils. These coils require a separate source of DC power to excite the generator so that the turbine's rotational force can be converted into electrical energy.

Without that initial source of power, the generator may spin, but it will not produce electricity. The required DC power typically comes from an independent source, such as a small diesel generator, or from a part of the grid that remains operational. Utilities contracted to provide this contingency power play a critical role, and failure to be available when needed can have serious consequences.

The DNS is not an electrical generation network, but it exhibits similar kinds of complex dependencies. Its role is to map a fully qualified domain name to the IP addresses associated with that name.

The 'D' in DNS stands for 'Domain'. The labels in a domain name form a hierarchy of administrative domains, separated by dots. Each domain boundary can, in principle, be served by a different authoritative nameserver that defines how names are managed beneath that point in the hierarchy.

As a result, what appears to be a simple query, such as 'What is ?', can trigger a sequence of lookups. Resolving the name may require querying information about multiple domains in the hierarchy, potentially involving three or more separate steps before the final answer is obtained.

When you have a cache, it contains the name-to-address mappings you've already learned, including the addresses of nameservers for domains you've previously visited. Those nameservers can then provide the answers you're looking for, either directly or by referring you to another server.

But what happens when there is no cache? Imagine asking for the nameservers of and being told they are and How do you locate and when discovering is the very problem you're trying to solve?

This circular dependency lies at the heart of the DNS cold-start problem: How do you begin resolving names when you don't yet know where any of the relevant servers are?

Geoff has been exploring this cold-start behaviour and what it reveals about the choices operators make when naming hosts and services, and when designing the DNS infrastructure behind them. It also highlights how intermediaries that insert themselves into the DNS resolution process, as well as mechanisms intended to mitigate cold-start risks, can increase the overall query load for clients around the world.

Read more about DNS cold start and presentations at the RIPE NCC DNS Working Group:

You can stream and subscribe to PING via the following channels:

If you're interested in sharing your insights or research, please get in touch - we're always looking for great stories from the community. Please let us know what you think of the podcast and the APNIC Blog so we can keep improving.

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.