What is TLD?
Top-level domain
A TLD (top-level domain) is the last label of a domain name, such as net, com, org or au, run by a registry and delegated from the DNS root zone.
DNS names are read right to left as a tree. Above every TLD is the root zone, which holds NS records delegating each TLD to that registry's nameservers and, for signed TLDs, a DS record linking it into the DNSSEC chain of trust. The TLD's own zone then delegates second-level names such as example.net to their owners' nameservers, again with a DS record for each signed domain. A resolver looking up www.example.net with an empty cache therefore asks a root server, which refers it to the net servers, which refer it to example.net's servers. TLDs fall into a few groups:
- Generic TLDs (gTLDs) such as com, net, org and the newer ones like app.
- Country-code TLDs (ccTLDs), two letters taken from ISO 3166, such as au, uk and nz.
- arpa, the infrastructure TLD that holds reverse DNS under in-addr.arpa and ip6.arpa.
The root zone's contents are managed by IANA.
Engineers mostly meet TLDs through the registry and registrar system: you register a name with a registrar, which passes your NS and DS records to the TLD registry, and a wrong DS there breaks validation for the whole domain. Some names are reserved and will never be delegated, including example, test, invalid and localhost (RFC 2606), which is why documentation uses them, and why making up a private TLD for internal hosts invites clashes. The PowerDNS on Debian lesson builds its own root and net zones so you can follow a lookup and its chain of trust from the top.
Lessons that use TLD
- PowerDNS on Debian: authoritative, secondary, DNSSEC and recursorTeaches this term · Intermediate · 60 min
Build a complete DNS service on Debian with PowerDNS: authoritative primary and secondary servers with NOTIFY and AXFR, zones by pdnsutil and the HTTP API, DNSSEC signed all the way from a lab root, and a validating recursor for the office.