DNS TLD Domain Delegation

While testing the name servers for my domain after its transfer, I suddenly realized I wasn’t sure to fully understand DNS delegation anymore¹, more specifically how precisely the zone of the TLD registry (say .fr) gets updated².

Domain creation

You see, I can change the NS (name server) records of my zone (foudil.fr) at my registrar, via the web console and probably via their API as well. Even my registrar has a special feature to only update the domain name servers. But what happens exactly so that the TLD name servers eventually know about these new name servers? In other words maybe, how does domain delegation works technically between registrars and registries?

We don’t have to look at a complex case like a domain transfer by the way, we can simply consider the creation of a domaine.

With some readings and the invaluable help of great engineers in my network ✌, I finally have the answer.

So when you create a domain at a registrar, mainly from a DNS perspective (not looking at WHOIS or RDAP), what happens is:

1. The registrar requests the domain creation at the registry, via EPP (Extensible Provisioning Protocol) or some registry API³. Note the request can include a list of name servers.
2. After validation, the registry stores the new domain information into a database.
3. The registry uses that information to update their DNS name servers, authoritative for the TLD zone of the domain.

All this is well explained in more details in this excellent AFNIC post.

But the last point requires some explanations. Before looking at how the update is automated, let’s recap what delegation is.

DNS zone delegation

On the name servers delegating the zone (the ones authoritative for .fr), the zone needs to include:

foudil.fr.              10800   IN      NS      ns-65-c.gandi.net.
foudil.fr.              10800   IN      NS      ns-17-b.gandi.net.
foudil.fr.              10800   IN      NS      ns-63-a.gandi.net.
; We could optionally define glue records here: the A records for the gandi name servers.

On the name servers for the delegated zone (the ones authoritative for the zone foudil.fr, which can be the ones from my registrars or my own or yet others), the zone needs to include:

foudil.fr.              10800   IN      SOA     ns1.gandi.net. hostmaster.gandi.net. 1690416000 10800 3600 604800 10800
foudil.fr.              10800   IN      NS      ns-65-c.gandi.net.
foudil.fr.              10800   IN      NS      ns-17-b.gandi.net.
foudil.fr.              10800   IN      NS      ns-63-a.gandi.net.
ns-65-c.gandi.net.      133     IN      A       217.70.187.66
ns-17-c.gandi.net.      600     IN      A       217.70.187.18
ns-63-c.gandi.net.      600     IN      A       217.70.187.64

That’s basically it.

One quick word on glue records as we often hear about them in the context of zone delegation. Citing Ron Aitchison - Pro DNS and BIND 10 - 2011:

Strictly speaking, glue records (the IP address of the name server defined using an A or AAAA RR) are only required for every name server lying within the domain or zone for which it is a name server. The query response—the referral—must provide both the name and the IP address of the name servers that lie within the domain being queried.

According to the principle that the name servers for the foudil.fr domain (ns-17-c.gandi.net for instance) lie outside of the zone, the TLD .fr does indeed not store related glue records⁴.

Zone update

Let’s finally get to how the NS records get added to the TLD zone.

Well my initial best bet was Dynamic DNS (DDNS – RFC 2136)⁵. This extension to the DNS protocol allows to create, update or delete zone records. I later got confirmation that it was the case at some registries.

If I had to do it, I would either use BIND’s nsupdate or any programming library that supports DDNS. So something like:

#!/bin/sh

nsupdate -d <<EOF
  server 10.0.0.10
  zone fr
  update add foudil.fr. 10800 IN NS ns-65-c.gandi.net.
  send
EOF

NSD, another name server implementation, although advertised as “ideally suited for Top Level Domain implementations”, doesn’t support DDNS. Since modifying a zone requires a full reload, I, among others, wonder then how zone changes are made in practice at TLDs using it. Maybe with a load-balancer and network-shared zone files? I hear a better setup is to use NSD as a secondary name server, updates being applied to a hidden primary.

Conclusion

There’s a lot more to say about the DNS. The post Why is DNS still hard to learn? lists a lot of unexpected gotchas.

It’s amazing to see how seemingly simple protocols, especially among the older ones like SMTP or FTP, sometimes explicitly meant to be so, turn out to be quite involved in the real world.

This post was kindly reviewed by Stéphane Bortzmeyer.