[Podcast] Testing RSSAC 028 DNS root server name choices

'A rose by any other name would smell as sweet.' - William Shakespeare, Romeo and Juliet. Image generated by the author using Nano Banana 2.

In this episode of PING, we talk with Willem Toorop about a measurement of six choices for naming the root servers of the global DNS. This measurement was motivated by RSSAC 028, a 2017 technical analysis for ICANN of the naming scheme used by the root DNS servers.

Root name servers are part of the global DNS system, and they provide basic bootstrapping for every other DNS resolver and authoritative name server worldwide. This is their primary role, but they also handle query load relating to the global DNS system all day and every day.

There are 13 distinctly named root servers, each one identified by a letter from A to M under the domain . Although there are only 13 distinct 'labels', there are in fact thousands of machines providing this service as independently operated clusters behind each of these letters, using the BGP 'anycast' method we have discussed on PING before.

The special zone was created in 1995 and is delegated in the usual way under the Top-Level Domain (TLD), which itself is delegated from the DNS root zone.

At first glance, this creates an apparent circular dependency. A newly bootstrapped DNS resolver needs to locate a root server, but the names of the root servers are within the domain. To resolve a name in , the resolver would first need to know how to reach the zone. However, discovering the .net delegation normally requires querying a root server in the first place.

The circular dependency is resolved by the contents of an initial 'priming' response. This response provides the additional 'glue' information to seed direct knowledge of how to find each of these named root servers as is, without all the intermediate logic of the circular dependency.

This glue is inherently not signed in DNSSEC. It's insecure. The priming response is very carefully curated for both its size and the content, but it would be good to give it some content security and increase trust in the message. RSSAC 028 explored the impact of applying DNSSEC over this domain, which in turn would add DNSSEC signatures to the priming response and impact a goal of keeping this a small 512-byte backwards-compatible UDP packet.

By keeping the priming response small, it remains compatible with legacy systems across the Internet. Nothing happens quickly in DNS evolution, however, and this naming question has now been under consideration for almost a decade. Willem and his colleagues at NLnet Labs and SIDN have produced two reports examining the candidate naming schemes, the implications of applying DNSSEC, and the resulting impact on the bootstrap fetch.

The surprising outcomes are discussed in this episode of PING.

Read more about RSSAC 028, the study, and its methodology

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.