DNS delegation and its possible evolution with DELEG

Administrative and technical context

Figure 1 : Tree diagram of domain names (partial!)

The administration of domain names is decentralised. If you are the owner of wikipedia.org, you can add or remove sub-domains such as fr.wikipedia.org, allocate values (for example an IP address) to the name wikipedia.org, all without having to ask anyone’s permission: there is no central authority¹.

A domain name consists of several components separated by dots, so decentralisation consists of delegating a sub-domain to another entity. The fact that there is a dot does not mean that there must necessarily be delegation (for example fr.wikipedia.org and wikipedia.org are under the same authority, there is no delegation) but when there is delegation it must be defined by a dot². For instance, Afnic delegates u-bourgogne.fr to the University of Bourgogne which can decide in turn whether or not³ to delegate iut.u-bourgogne.fr to the university’s IUT⁴.

Delegation can be purely administrative. For example, gouv.fr is managed technically by Afnic, under the .fr TLD, but administratively it is independent: the French government takes its own decisions on the creation or deletion of names under gouv.fr.

But delegation can also be, and indeed mostly is, technical, as allowed by the DNS, the computer protocol on which the functioning of these domain names depends, along with that of the services they provide. This takes from in the DNS by way of the creation of NS records which contain a list of the authoritative name servers for the delegated name. For example, in June 2024, u-bourgogne.fr was delegated to three servers: dns1.u-bourgogne.fr, dns2.u-bourgogne.fr, and ufc.univ-fcomte.fr. When a DNS resolver (the server that your computer queries to obtain DNS information) needs to provide data on u-bourgogne.fr, it will query one of these three servers.

Figure 2: DNS resolution, with the resolver and authoritative servers

This is how decentralisation works: the holder of u-bourgogne.fr (the university) can create, delete and change the names under u-bourgogne.fr as they see fit. No authorisation is needed, from Afnic or any other entity, and the registry for the TLD concerned (.fr in this case) is not even informed.

A contiguous set of domain names delegated together is referred to as a zone⁵. Thus gouv.fr is in the fr zone but u-bourgogne.fr is in its own zone.

So how can we tell whether or not there has been technical delegation? The simplest way is to ask for the NS or SOA records, which can only be at the apex of the zone. If they are there, then the domain has been delegated. If not, then it hasn’t been. Thus DNS client software shows⁶ that gouv.fr has not been technically delegated but that museedesconfluences.fr has been:

% dig gouv.fr SOA

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59426

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

…

(No error, but zero response.)

% dig  museedesconfluences.fr SOA

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10536

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

…

;; ANSWER SECTION:

museedesconfluences.fr. 10800 IN SOA ns1.gandi.net. hostmaster.gandi.net. (

                        1718236800 ; serial

                        10800      ; refresh (3 hours)

                        3600       ; retry (1 hour)

                        604800     ; expire (1 week)

                        10800      ; minimum (3 hours)

                        )

…

(One response.)

Its limitations

Fasten your seat belts (and brace yourself), because we’re now going to have to take a deep dive and get a lot more technical in order to understand the limitations of this technical delegation mechanism and the proposed reform.

The usual DNS records, such as AAAA (IP addresses), TXT (free text), MX (names of email servers), and recent HTTPS (names and characteristics of HTTP servers⁷), are located in the domain concerned, as is logical. But there are two exceptions to this rule: the first concerns the NS records (names of authoritative DNS servers) mentioned earlier. These records are in both the domain concerned and the parent domain. And they are supposed to be kept identical, which in practice is not always the case. DNS resolvers start with the root and follow the indications in the NS records to arrive at the authoritative servers. So NS records in the parent domain are indispensable, although sometimes neglected.

NS records give only the names of the servers. It is not possible to indicate their characteristics, such as the port number used (it must be 53) and above all whether or not secure encoded communication is possible using DoT (DNS over TLS⁸). At present (August 2024), very few authoritative servers have this protection⁹, partly because the DNS client, the resolver, does not know in advance whether it can use TLS.

Another exception to the principle of records being in the domain concerned relates to DS (delegation signer) records (signing of DNSSEC keys of the sub-delegated domain). These records are only in the parent domain.

A third and final exception to the rule that zone data must be in the zone itself concerns what are known as glue records. These contain the IP addresses of name servers that are in the same zone as the zone they serve. The need for them comes from the way DNS resolution works. When the resolver receives a delegation, it receives a list of name servers and domain names. It has to resolve these domain names to IP addresses in order to establish contact with them. If these authoritative server names are in another zone, there is no particular problem. But if they are in the zone that they serve, a dependency loop is created, a chicken-and-egg problem; the delegation of caf.fr implies being able to talk to ns.caf.fr and ns1.caf.fr. But to resolve ns.caf.fr, the resolver has to go through the caf.fr servers! So to prevent this dependency loop, when a name server is in the same domain as that which it serves, the parent must also indicate the IP addresses, and these indications are referred to as glue records. Here is an example of a delegation by an authoritative name server for .fr, indicating the glue record at the end:

% dig @d.nic.fr www.caf.fr

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65266

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3

…

;; AUTHORITY SECTION:

caf.fr.                 3600 IN     NS ns.caf.fr.

caf.fr.                 3600 IN     NS ns1.caf.fr.

;; ADDITIONAL SECTION:

ns1.caf.fr.       3600 IN     A 91.231.174.241

ns.caf.fr.        3600 IN     A 91.231.174.240

The use of servers in the zone served comes with constraints: for example, if these servers change IP address, the parent zone has to be asked to change the glue record. In practice, this step is sometimes forgotten.

And as if the situation were not already complicated enough, we should point out that NS and glue records in the parent zone are not authoritative, being merely copies, in theory, of information in the child zone, whereas DS records are in the parent zone only and are authoritative.

The role of the DNS operator

When a domain name is delegated technically, the parent domain is informed of the names of the authoritative servers for this domain. These servers are hosted by one or more DNS operators. This operator or these operators may be the Registrar, a DNS hosting provider other than a registrar, or the holder itself, which is not only technically possible but actually simpler than having an HTTP server hosted. Where this operator is neither the registrar nor the holder, it has no explicit role in the Registry-Registrar-Holder relationship. It cannot change the delegation of its own accord. So if a DNS operator with a set of four name servers were to tell its clients first that they had to give this list to the registry and then that it wished to add a fifth server, it would have to send the new list to all its clients and hope that they would inform the registry of the change, possibly through the registrar.

For example, DNSSEC keys¹⁰ are typically managed by the DNS operator. It would therefore be advantageous for the operator to be able to change the DS records (which point to the DNSSEC keys) itself, rather than having to rely on its client to do so, via the registrar, as at present. If the registrar is also the operator, the situation is simple, but otherwise there is additional communication, complexity and risk of error.

The DELEG project

This project is sponsored by the IETF, the standards organisation referred to above. It aims to resolve a number of problems:

• the fact that the DNS operator is not explicitly involved, which makes certain operations difficult, since these must pass through all the name holders that are clients of the operator,
• the fact that the NS records in the parent domain and the delegated domain have to be synchronised,
• the fact that NS records do not allow indication of the technical characteristics of the name servers, for example the use of a network port¹¹ other than the usual port 53, or the fact that they accept not only DNS in clear text but also encrypted DNS, DoT (DNS over TLS), DoH (DNS over HTTP¹²) or DoQ (DNS over QUIC¹³).

The DELEG project therefore envisages replacing NS records in the parent domain with more comprehensive DELEG resource records (RRs). Unlike NS records but in common with DS records, they will be authoritative and will therefore be signed if DNSSEC is used. I’ll give two examples, but keep in mind that DELEG is just a project and that nothing has been definitively decided yet:

1. Suppose we want to delegate to example.com, which accepts DoT. A DELEG RR might look like this: DELEG ns1.example.com ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 alpn=dot, to indicate both the IP addresses (glue records) and the fact that DoT works¹⁴. It is important to note that the list of key-value pairs is extensible: this mechanism will allow other things to be indicated on the name servers in the future.
2. Suppose we have a separate DNS operator, net, and we simply wish to make reference to the set of servers. We will use an alias, DELEG config2.example.net, and in config2.example.net we find the list of servers, stored in a single place, which the DNS operator will easily be able to change without having to disturb its clients.

The intention is to use the SVCB (Service Binding) and Parameter Specification general recording framework standardised in RFC 9460. The first case, with the syntax of the zone files as produced by dig, might look like this:

example.com.  86400  IN DELEG  1 ns1.example.com. (

                   ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 alpn=dot)

And the second case:

example.com.  86400  IN DELEG 0   config2.example.net.

Finally, with the operator:

config2.example.net. 3600    IN SVCB 1 . (

                   ipv4hint=192.0.2.54,192.0.2.56

                   ipv6hint=2001:db8:2423::3.2001:db8:2423::4 )

If this project goes ahead, it will be necessary to modify several programs:

• when authoritative servers are queried on a name under a delegated domain, they will have to send back DELEG records, not NS records,
• resolvers will have to follow DELEG RRs instead of NS records to find the authoritative servers,
• registrars’ Web interfaces and APIs indicating information on delegations will have to be modified,
• as will test and debugging tools such as Zonemaster,
• EPPs¹⁵ for creating and modifying these DELEG RRs, and RDAPs¹⁶ for posting them will both need to be modified. For an article describing the process of sustaining domain names, see:
• Registries’ registration systems (databases, servers, etc.)

As you can see this is no minor change; it affects a large number of tools and actors. Furthermore, it goes without saying that not everyone will make the transition at the same time and that the interim period, during which both systems will co-exist, will last for many years. The old resolvers will ignore the DELEG records during this period, so it will still be necessary to publish correct NS records. This publication of two sets of information is unlikely to be problem-free.

An additional problem arises from the fact that the indications given by the DELEG records may be wrong, either having been wrong from the outset or becoming so over time. If a DELEG record says that a server accepts DoT but it doesn’t, or no longer does, the DNS client, the resolver, must be ready to quickly try without DoT¹⁷.

So where is the project at currently? The IETF DELEG working group was created on 27 June 2024 (visit https://datatracker.ietf.org/wg/deleg/ for the latest news). Its charter provides for the drawing up of a precise statement of requirements, followed by a specification of the technical changes to be made to the DNS¹⁸. Future modifications to other protocols, such as EPPs, will be the responsibility of other working groups¹⁹.

Here’s my personal prediction for what it’s worth. It seems to me that the extent of the changes to be made, and the need to manage both systems in parallel for a large number of years make it impossible to be optimistic about this project.

Conclusion

DELEG would be not just a technical change but also a political change, with power shifting to non-registrar DNS operators. This project would require the agreement of a large number of categories of actors, in a critical environment in which people are hesitant about any changes. The DNS delegation mechanism is far from perfect. DELEG is a good idea, but it is perhaps too late to envisage implementing it.

1 – It was not always so:  a long time ago in a galaxy far far away, all domain names were managed centrally, on a single list, managed by a single person, Elizabeth Feinler. Her retrospective article, “Host Tables, Top-Level Domain Names, and the Origin of Dot Com” is a recommended read. The invention of the DNS brought an end to this system, which would not have been able to cater to the growth of the Internet.

2 – In the case of technical delegation, a new zone is said to have been created. At its apex or top node, each zone has a set of NS (name server) records and an SOA (start of authority) record containing useful metadata. Thus gouv.fr is in the fr zone but cgt.fr is not – it is in a separate zone. In this article, to keep things simple, we will often refer to domains even when they may also be zones.

3 – This name was delegated in June 2024.

4 – Institut Universitaire de Technologie (University Institute of Technology)

5 – And the distinction between zone and domain, a trivial detail in most contexts, is crucial if the DNSSEC security mechanism is used.

6 – In the following examples we use dig, the most widely used DNS testing and debugging software application.

7 –% dig abeille-sucree.fr HTTPS

…

;; ANSWER SECTION:

abeille-sucree.fr.      300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.21.69.108,172.67.207.111 ipv6hint=2606:4700:3035::6815:456c,2606:4700:3035::ac43:cf6f

8 – TLS = Transport Layer Security, the same cryptography protocol as for HTTPS. RFC 8446.

9 – If you want to try for yourself, the authoritative servers for wikipedia.org accept DoT.

10 – Domain Name System Security Extensions, a signature mechanism to ensure the authenticity and integrity of records.

11 – Number identifying a particular service on a machine.

12 – Hypertext Transfer Protocol Security, the basis of most Internet servers, over which the DNS can be sent to protect the connection. DoH is standardised in RFC 8484.

13 – A transport layer protocol rivalling the classic TCP but including encryption to protect the connection. DNS over QUIC, DoQ is standardised in RFC 9250.

14 – ALPN stands for Application-Layer Protocol Negotiation, standardised in RFC 7301, a method for indicating which application protocol to use.

15 – Extensible Provisioning Protocol

16 – Registration Data Access Protocol

17 – RFC 9539 describes a method for trying various possible ways of communicating with a DNS server when we do not know its capabilities in advance.

18 – There are some rough drafts with no official value.

19 – You can consult these very preliminary rough drafts on EPPs and RDAP.