Without a LEG to Stand On
By Mark McFadden
The Domain Name System (DNS) is one of the bedrock protocols that makes the Internet work. It's also the home to incredible innovation and transformation. Almost 70 different RFCs document best practices, protocol evolution and operational procedures for the DNS. It's understandable: the DNS is the most extensible, reliable, global database on the Internet. As a result, many people want to use it for many different purposes.
One of the best features of the DNS is that it doesn't require a central authority to maintain the namespace. Instead, the DNS namespace uses its hierarchical structure to distribute the responsibility for maintaining the DNS records. The technique uses something called a "NS record" to point to the authoritative nameserver for a delegated set of DNS records.
A nameserver is one type of a DNS server. It is the computer that stores all DNS records for a delegated domain. Usually, domains rely on multiple nameservers to increase availability. If a nameserver becomes unavailable, queries can be directed to an alternate. The alternate nameservers store exact copies of the DNS records in the primary server.
Not Just Where to Go, but How to Get There
However, the NS record is pretty spartan. Besides the location of the authoritative server, it contains just a time-to-live value. This number indicates how long the information in the NS record should be used before querying for a fresh copy. Any other information about the authoritative server has to come from other sources.
Suppose a DNS operator - or owner of an individual domain - preferred that queries to an authoritative server be performed using DNS over TLS. The NS record provides no mechanism to even hint about that preference.
An interesting proposal has emerged in the IETF's DNSOP Working Group that suggests a possible solution to this dilemma. The proposal suggests that a new kind of DNS record, called DELEG, be created so that when a resolver asks for information about a particular domain, it gets the new DELEG record along with the NS record. The main idea is that DELEG would be backward compatible with DNS resolvers which didn't implement DELEG, but would provide a method to signal capabilities to DNS resolvers that did understand DELEG.
DNSOP at the IETF
Keeping up with changes to the DNS protocol means monitoring and participating in the IETF's DNSOP Working Group. DNSOP is intended to be operational, focusing on how DNS software is deployed, administered, configured and run on Internet networks.
The proposal for DELEG comes to the IETF in the usual way: a group of interested authors have written a first version of an Internet-Draft for others to comment upon. However, what happened next was a little unexpected. DNSOP ran an interim meeting in January 2024 to discuss the DELEG proposal and figure out a path forward for the proposed change to the DNS. DNSOP averages roughly a single interim meeting annually, allowing those interested in the DNS and its operation to meet outside the three regularly scheduled annual meetings.
At the January interim meeting, there was a presentation on the DELEG proposal, a discussion of some compliance testing that had taken place, and a set of observations on the current proposal from one interested party. The result of the discussion was that a proposal for a Birds of a Feather (BoF) session should be amended and sent for approval by the IESG to hold a BoF on DELEG at the IETF 119 meeting in Brisbane, Australia.
Why it Matters
BoF's are a mechanism for addressing emerging use cases, technologies and requirements in the IETF. Sometimes, the BoF is an initial step to form an IETF Working Group. Other times, a BoF is simply an exploration of whether or not there is interest in the IETF to work on a particular problem. However, for people who aren't regular participants in the standards work of the IETF, BoFs are an excellent indication of the emergence of new technology on the Internet.
In the case of DELEG, the BoF may result in the work being done outside DNSOP. That would hint that the work is of real significance to the future of the DNS. It is also an indication of how full DNSOP's current agenda is for standardization. The DNSOP meetings at regular IETF meetings are some of the busiest in the entire IETF. The BoF would also be an opportunity for people who wanted this capability, but saw other ways to provide it, to come forward and suggest alternatives to DELEG.
In all these cases, the DELEG proposal is likely to generate substantial discussion in the coming months.