What Is DNS and Why Does It Matter?
The Domain Name System (DNS) is one of the most fundamental protocols in modern networking. Every time you type a domain name into your browser, open an email client, or connect to a remote server, DNS is silently working in the background to translate human-readable names into machine-readable IP addresses. Without DNS, you would need to memorize the numeric IP address of every website, API endpoint, or mail server you wanted to reach.
At its core, DNS is a globally distributed, hierarchical database. No single server holds all the records for every domain on the internet. Instead, responsibility is spread across millions of servers organized in a tree-like structure, making DNS both highly scalable and fault-tolerant. Understanding how this system works is essential knowledge for any infrastructure engineer, network administrator, or developer who builds or operates networked systems.
The DNS Hierarchy Explained
Understanding DNS resolution requires understanding the delegation hierarchy that underpins it. Think of DNS like a chain of authority where each level delegates responsibility downward to the next.
- Root Zone (.): At the very top sits the root zone, managed by IANA (Internet Assigned Numbers Authority). Root name servers hold no record data for individual domains — they simply know which servers are authoritative for each top-level domain (TLD). There are 13 logical root name server addresses, labeled a.root-servers.net through m.root-servers.net, backed by hundreds of physical servers distributed globally via anycast.
- Top-Level Domains (TLDs): These are the .com, .net, .org, .io, and country-code zones like .uk or .de. Each TLD is operated by a registry. Verisign, for example, operates the .com and .net TLD servers. TLD servers know which authoritative name servers are registered for each second-level domain beneath them.
- Second-Level Domains: This is where solvethenetwork.com lives. The domain registrant controls which authoritative name servers are listed at the TLD level. Those name servers host the actual zone data.
- Subdomains: Additional labels like www.solvethenetwork.com or mail.solvethenetwork.com are fully managed within the zone by the domain owner. Subdelegation to child zones is also possible using NS records.
The Four Key Players in a DNS Query
Before walking through resolution step by step, let's clearly define the four components involved in every DNS lookup.
- Stub Resolver: A minimal DNS client built into the operating system. It does not perform its own recursive lookups. Instead it forwards queries to a recursive resolver and waits for a complete answer. On Linux, this is typically managed by
systemd-resolved
or configured directly in/etc/resolv.conf
. - Recursive Resolver (Full-Service Resolver): The workhorse of DNS. When your stub resolver asks it a question, the recursive resolver does the legwork — querying root servers, TLD servers, and finally the authoritative server iteratively until it obtains an answer. Common examples include ISP-provided resolvers, or public resolvers operated by infrastructure providers.
- TLD Name Servers: Operated by TLD registries. They hold NS and glue records that point to the authoritative name servers for each registered domain under their TLD.
- Authoritative Name Server: The final authority for a specific zone. When you manage solvethenetwork.com, your authoritative server holds all the A, MX, TXT, and CNAME records for that domain. It answers queries with the AA (Authoritative Answer) flag set.
Step-by-Step: How a DNS Query Is Resolved
Let's walk through exactly what happens when a client — sw-infrarunbook-01 at 192.168.10.50 — attempts to resolve www.solvethenetwork.com for the first time with an empty cache.
Step 1: The Client Checks Its Local Cache
Before sending any network traffic, the operating system checks its local DNS cache. If a record for www.solvethenetwork.com was fetched recently and its TTL has not yet expired, the cached answer is returned immediately. On Linux systems running systemd-resolved, you can inspect the cache directly.
# Check the local systemd-resolved cache on sw-infrarunbook-01
infrarunbook-admin@sw-infrarunbook-01:~$ resolvectl query www.solvethenetwork.com
www.solvethenetwork.com: 192.168.10.80 -- link: eth0
(TTL remaining: 243s, cache hit)In this walkthrough, the cache is empty, so the stub resolver proceeds to contact the configured recursive resolver.
Step 2: The Stub Resolver Contacts the Recursive Resolver
The stub resolver reads
/etc/resolv.conf(or the systemd-resolved configuration) to determine which recursive resolver to use and sends a query with the RD (Recursion Desired) bit set, meaning: "please do the work for me and return a final answer."
# /etc/resolv.conf on sw-infrarunbook-01
nameserver 192.168.1.53
nameserver 192.168.1.54
search solvethenetwork.comThe stub resolver sends a UDP packet to 192.168.1.53 on port 53 asking for the A record of www.solvethenetwork.com.
Step 3: The Recursive Resolver Checks Its Own Cache
The recursive resolver at 192.168.1.53 maintains its own cache shared across all clients. If another machine on the network recently queried the same name and the TTL has not expired, the resolver returns the cached answer immediately, setting the RA (Recursion Available) flag and leaving the AA flag unset (indicating this is a cached, non-authoritative response).
Assuming the cache is cold, the resolver begins iterative resolution.
Step 4: The Recursive Resolver Queries the Root Servers
The recursive resolver has a built-in list of root server addresses (called the root hints file). It picks one and sends a non-recursive iterative query: "Do you know the address of www.solvethenetwork.com?" The root server does not have this answer, but it knows which servers handle .com and returns a referral.
# Simulating what the recursive resolver does internally
# Query to a root server for www.solvethenetwork.com
; <<>> DiG 9.18.12 <<>> @a.root-servers.net www.solvethenetwork.com A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30Step 5: The Recursive Resolver Queries the TLD Name Servers
Armed with the .com TLD server addresses, the recursive resolver sends another iterative query — this time to a.gtld-servers.net. The TLD server still does not know the IP of www.solvethenetwork.com, but it does know which authoritative name servers are registered for solvethenetwork.com and returns a referral with glue records.
# Response from a.gtld-servers.net
;; AUTHORITY SECTION:
solvethenetwork.com. 172800 IN NS ns1.solvethenetwork.com.
solvethenetwork.com. 172800 IN NS ns2.solvethenetwork.com.
;; ADDITIONAL SECTION (glue records):
ns1.solvethenetwork.com. 172800 IN A 198.51.100.10
ns2.solvethenetwork.com. 172800 IN A 198.51.100.11Glue records are essential here: if the name servers are within the same domain being looked up (solvethenetwork.com), the TLD provides their IP addresses directly to avoid a circular dependency.
Step 6: The Recursive Resolver Queries the Authoritative Name Server
The recursive resolver now contacts ns1.solvethenetwork.com at 198.51.100.10 directly. This server is authoritative for the solvethenetwork.com zone and holds the actual DNS records. It returns the A record with the AA flag set.
# Query directed at the authoritative server
infrarunbook-admin@sw-infrarunbook-01:~$ dig @198.51.100.10 www.solvethenetwork.com A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19204
;; flags: qr aa rd; QUERY: 1, ANSWER: 1
;; ANSWER SECTION:
www.solvethenetwork.com. 300 IN A 192.168.10.80
;; SERVER: 198.51.100.10#53(ns1.solvethenetwork.com)
;; Query time: 3 msec
;; MSG SIZE rcvd: 68Notice the aa flag in the header — this confirms the response came directly from the authoritative server, not a cache.
Step 7: The Recursive Resolver Caches the Answer and Responds
The recursive resolver stores the answer (192.168.10.80, TTL 300 seconds) in its cache, then relays the response back to the stub resolver on sw-infrarunbook-01. Any subsequent client asking for the same name will receive the cached answer for up to 5 minutes without triggering a new iterative lookup.
Step 8: The Application Connects
The stub resolver passes the resolved IP address back to the calling application — a browser, curl, or SSH client. The application opens a TCP connection to 192.168.10.80. DNS has done its job in milliseconds. The entire chain from stub resolver to root to TLD to authoritative server typically completes in under 100ms on a warm network.
Tracing the Full Resolution Path with dig
The
dig +traceflag causes dig to simulate what a recursive resolver does — starting from the root and following referrals step by step. This is one of the most powerful troubleshooting tools available to DNS engineers.
infrarunbook-admin@sw-infrarunbook-01:~$ dig +trace www.solvethenetwork.com A
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
;; Received 1097 bytes from 192.168.1.53#53 in 1 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 22 ms
solvethenetwork.com. 172800 IN NS ns1.solvethenetwork.com.
solvethenetwork.com. 172800 IN NS ns2.solvethenetwork.com.
;; Received 704 bytes from 192.5.6.30#53(a.gtld-servers.net) in 18 ms
www.solvethenetwork.com. 300 IN A 192.168.10.80
;; Received 68 bytes from 198.51.100.10#53(ns1.solvethenetwork.com) in 4 msCommon DNS Record Types
DNS zones can hold many different record types. Each type serves a specific function in how names are resolved and services are located.
- A: Maps a hostname to an IPv4 address. The most common record type.
- AAAA: Maps a hostname to an IPv6 address.
- CNAME: Canonical Name — creates an alias pointing to another hostname. A CNAME target must itself resolve to an A or AAAA record. CNAMEs cannot coexist with other record types at the zone apex.
- MX: Identifies mail exchange servers. Includes a numeric priority — lower values are preferred.
- TXT: Stores arbitrary text strings. Widely used for SPF email policy, DKIM public keys, and domain ownership verification tokens.
- NS: Delegates authority for a zone or subdomain to a set of name servers.
- SOA: Start of Authority — defines zone-level metadata including the primary name server, administrator contact, serial number, refresh interval, retry interval, expire interval, and negative cache TTL.
- PTR: Reverse DNS — maps an IP address back to a hostname, defined in reverse zones (e.g., 10.168.192.in-addr.arpa).
- SRV: Locates services by protocol and port. Used by SIP, XMPP, and other service-discovery protocols.
- CAA: Certification Authority Authorization — specifies which certificate authorities are permitted to issue TLS certificates for the domain.
Sample Zone File for solvethenetwork.com
$ORIGIN solvethenetwork.com.
$TTL 300
@ IN SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
2024040301 ; Serial (YYYYMMDDnn format)
3600 ; Refresh — how often secondaries check for updates
900 ; Retry — how often secondaries retry after failure
604800 ; Expire — when secondaries stop answering if primary unreachable
300 ) ; Negative Cache TTL
; Authoritative Name Servers
@ IN NS ns1.solvethenetwork.com.
@ IN NS ns2.solvethenetwork.com.
; Glue / Name Server A Records
ns1 IN A 198.51.100.10
ns2 IN A 198.51.100.11
; Host Records
www IN A 192.168.10.80
mail IN A 192.168.10.25
vpn IN A 192.168.10.1
; Mail Exchanger
@ IN MX 10 mail.solvethenetwork.com.
; Aliases
blog IN CNAME www.solvethenetwork.com.
docs IN CNAME www.solvethenetwork.com.
; Email Policy
@ IN TXT "v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 ~all"
; CAA Record
@ IN CAA 0 issue "letsencrypt.org"Understanding TTL (Time to Live)
Every DNS record carries a TTL value expressed in seconds. This value instructs resolvers and clients how long they may cache the record before it must be discarded and re-fetched. TTL has a direct impact on how quickly DNS changes propagate across the internet.
- Low TTL (60–300 seconds): Changes propagate quickly after a record update. Useful before planned migrations, IP address changes, or failovers. However, low TTLs increase the query load on your authoritative servers because resolvers must refresh cached data more frequently.
- High TTL (3600–86400 seconds): Caching is efficient and resolver load is minimized. End users benefit from faster responses since resolvers serve from cache. But changes can take up to 24 hours to be visible globally for all resolvers that cached the old value.
Operational Best Practice: Before making any DNS change (IP migration, decommissioning a host, changing MX records), lower the relevant record's TTL to 300 seconds at least 24 hours in advance. This ensures the old high TTL has expired everywhere before you make your change. Once the change is live and confirmed, raise the TTL back to its original value.
Recursive vs. Iterative Queries
These two query modes work in tandem during every DNS resolution:
- Recursive Query: The client (stub resolver) asks the recursive resolver to do all the work and return a definitive answer — either the record data or an error like NXDOMAIN. The RD (Recursion Desired) bit is set in the query. The recursive resolver is obligated to follow referrals until it has a final answer.
- Iterative Query: The recursive resolver asks each server in the chain — root, TLD, authoritative — one at a time. Each server either returns the answer or a referral to a more specific server. The recursive resolver follows these referrals until resolution is complete.
Client machines almost always send recursive queries. Recursive resolvers use iterative queries when communicating with root and TLD servers (most authoritative servers do not perform recursion).
DNS Caching and Negative Caching
When a resolver successfully resolves a name, it caches the positive result for the record's full TTL. But what about names that do not exist? That is governed by negative caching, formalized in RFC 2308.
When an authoritative server returns an NXDOMAIN response (the queried name does not exist) or an empty answer (the name exists but has no record of that type), the resolver caches this negative result. The duration of negative caching is defined by the minimum TTL field in the zone's SOA record — the last numeric value in the SOA RDATA.
# NXDOMAIN response for a non-existent host
infrarunbook-admin@sw-infrarunbook-01:~$ dig ghost.solvethenetwork.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55821
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
solvethenetwork.com. 300 IN SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2024040301 3600 900 604800 300
;; Query time: 6 msecThe SOA minimum TTL of 300 seconds tells the resolver to cache this negative result for 5 minutes, preventing repeated queries for non-existent names from hammering the authoritative server.
Split-Horizon DNS
Split-horizon DNS (sometimes called split-brain DNS) allows a name server to return different answers for the same query depending on the source of the request. This is a common technique for returning internal private IP addresses to employees on the corporate network while returning a public IP to external clients — all for the same domain name.
For example, www.solvethenetwork.com might resolve to 192.168.10.80 for internal clients (reaching a server directly) but to 198.51.100.20 for external clients (hitting a load balancer or NAT). BIND implements this using the
viewdirective.
# /etc/bind/named.conf snippet — split-horizon using BIND views
acl "internal-nets" { 192.168.0.0/16; 10.0.0.0/8; 172.16.0.0/12; };
view "internal" {
match-clients { internal-nets; };
recursion yes;
zone "solvethenetwork.com" {
type master;
file "/etc/bind/zones/internal/db.solvethenetwork.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "solvethenetwork.com" {
type master;
file "/etc/bind/zones/external/db.solvethenetwork.com";
};
};DNS Security Fundamentals
Traditional DNS operates over plaintext UDP on port 53, making it vulnerable to several well-documented attacks that every infrastructure engineer should understand.
- DNS Cache Poisoning: An attacker sends forged DNS responses with a matching transaction ID to a recursive resolver before the legitimate authoritative server responds, injecting false records into the resolver's cache. RFC 5452 and source port randomization significantly raise the bar for this attack.
- DNS Amplification (DDoS): Attackers send queries with a spoofed source IP (the victim's address) to open recursive resolvers. The resolver sends large responses to the victim. Restricting your resolver to known clients (not operating an open resolver) prevents participation in these attacks.
- Man-in-the-Middle DNS Interception: On-path attackers intercept and modify DNS queries or responses. DNSSEC provides cryptographic authentication of DNS records. DNS over TLS (DoT, port 853) and DNS over HTTPS (DoH, port 443) encrypt the transport layer.
- Zone Transfer Leakage: Unrestricted AXFR (zone transfer) queries can expose your entire zone to any requester. Use TSIG (Transaction Signature) keys to authenticate zone transfers between primary and secondary servers.
# Generate a TSIG key for authenticated zone transfers
infrarunbook-admin@sw-infrarunbook-01:~$ tsig-keygen -a hmac-sha256 xfr-key.solvethenetwork
key "xfr-key.solvethenetwork" {
algorithm hmac-sha256;
secret "kR3zP9xQmT6lN2yV8wJdHaFbGcUiOsEp4tMvYnXqZA0=";
};
# Add to named.conf to restrict zone transfers
zone "solvethenetwork.com" {
type master;
file "/etc/bind/zones/db.solvethenetwork.com";
allow-transfer { key xfr-key.solvethenetwork; };
};Diagnosing DNS Problems from the Command Line
Effective DNS troubleshooting relies on a small set of essential tools.
digis the gold standard for DNS queries on Linux systems and is far more informative than
nslookup.
# Query A record using the system resolver
infrarunbook-admin@sw-infrarunbook-01:~$ dig www.solvethenetwork.com A
# Query a specific resolver directly (bypass system cache)
infrarunbook-admin@sw-infrarunbook-01:~$ dig @192.168.1.53 www.solvethenetwork.com A
# Trace full resolution path from root servers
infrarunbook-admin@sw-infrarunbook-01:~$ dig +trace www.solvethenetwork.com
# Reverse DNS lookup for an IP address
infrarunbook-admin@sw-infrarunbook-01:~$ dig -x 192.168.10.80
# Query MX records for mail routing
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com MX
# Inspect SOA record for zone serial and timing parameters
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com SOA
# Get short answer only (strip headers)
infrarunbook-admin@sw-infrarunbook-01:~$ dig +short www.solvethenetwork.com A
192.168.10.80
# Check NS delegation
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com NS
# Check TXT records (SPF, DKIM, verification tokens)
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com TXTFrequently Asked Questions
Q: What is the difference between a recursive resolver and an authoritative name server?
A: A recursive resolver (also called a full-service resolver) is the server your computer talks to when it needs to resolve a name. It does not hold zone data itself — instead it queries the DNS hierarchy on your behalf, following referrals from root servers to TLD servers to authoritative servers. An authoritative name server actually holds the zone file for a domain and is the final, definitive source of record data. When you manage solvethenetwork.com, you configure authoritative name servers that hold those records. The recursive resolver finds and queries them for you.
Q: What happens when a DNS record's TTL expires?
A: When a cached DNS record's TTL expires, the resolver discards it from cache. The next query for that name triggers a fresh iterative lookup all the way back to the authoritative server. The resolver fetches the current record, which may have a new IP address or updated value, and caches it again for the new TTL duration. This is the mechanism by which DNS changes propagate — you update the record on your authoritative server, and as old cached copies expire across resolvers worldwide, clients begin seeing the new value.
Q: Why does DNS primarily use UDP instead of TCP?
A: DNS uses UDP port 53 for standard queries because UDP is connectionless and low-overhead. Most DNS responses fit within a single 512-byte UDP packet (or up to 4096 bytes with EDNS0 extensions), making TCP's three-way handshake unnecessary overhead for simple lookups. DNS does fall back to TCP when a response exceeds the UDP payload size limit (the TC — TrunCation — bit is set in the response, signaling the client to retry over TCP), and TCP is always used for zone transfers (AXFR/IXFR).
Q: What is an SOA record and what does the serial number do?
A: The Start of Authority (SOA) record is the first record in every DNS zone and defines zone-level metadata. The serial number is a monotonically increasing integer that secondary name servers use to determine whether they have the latest copy of the zone. When the serial number on the primary increases (typically after a zone edit), secondary servers detect the change during their next refresh cycle and initiate a zone transfer to pull the updated data. The conventional format is YYYYMMDDnn, where nn is a two-digit daily increment counter — for example, 2024040301 for the first change on April 3, 2024.
Q: How do I check what DNS server my Linux machine is currently using?
A: On systems using systemd-resolved, run
resolvectl statusto see which DNS servers are configured per link. On older systems, check
/etc/resolv.conffor
nameserverentries. To verify which server actually answered a query, use
dig www.solvethenetwork.comand look for the SERVER line at the bottom of the output — it shows the IP and port of the resolver that responded.
infrarunbook-admin@sw-infrarunbook-01:~$ resolvectl status | grep "DNS Servers"
DNS Servers: 192.168.1.53 192.168.1.54Q: What is the difference between a CNAME and an A record?
A: An A record maps a hostname directly to an IPv4 address. A CNAME (Canonical Name) record creates an alias — it maps one hostname to another hostname, which must itself resolve to an address. When a resolver encounters a CNAME, it follows the chain until it reaches an A or AAAA record. CNAMEs are convenient for aliasing multiple hostnames to a single canonical name, so when the underlying IP changes you only update one A record. However, CNAMEs cannot be placed at the zone apex (the bare domain solvethenetwork.com) alongside other records, and they cannot coexist with NS or SOA records.
Q: What does NXDOMAIN mean and how is it different from SERVFAIL?
A: NXDOMAIN (Non-Existent Domain) means the queried name definitively does not exist in the DNS namespace — the authoritative server for that zone confirmed there is no such record. SERVFAIL means the resolver encountered an error while trying to resolve the name — this could indicate the authoritative server was unreachable, returned a malformed response, or DNSSEC validation failed. NXDOMAIN is a clean negative answer; SERVFAIL signals a resolution failure that warrants investigation. A third status, NOERROR with an empty answer section, means the name exists but has no record of the queried type.
Q: How long does a DNS change take to propagate globally?
A: Propagation time is bounded by the TTL of the record being changed — not 48 hours as is commonly claimed. If the old record had a TTL of 3600 seconds (1 hour), then within 1 hour all resolvers that cached the old record will have expired it and fetched the new value. The "48-hour propagation" myth comes from legacy default TTLs of 172800 seconds. Practical advice: lower your TTL to 300 seconds at least 24 hours before making a change so the old high TTL expires everywhere first. After your change is confirmed stable, raise the TTL back.
Q: What is a reverse DNS (PTR) record and why does it matter?
A: A PTR (Pointer) record performs the reverse of an A record lookup — it maps an IP address back to a hostname. Reverse DNS is used by mail servers to validate sending hosts (many receiving mail servers reject mail from IPs with no PTR record or a mismatched one), by security tools for logging human-readable hostnames instead of raw IPs, and by network monitoring systems. Reverse DNS zones are structured as the IP octets reversed followed by .in-addr.arpa — so the PTR record for 192.168.10.80 lives in the zone 10.168.192.in-addr.arpa. ISPs typically control reverse zones for their allocated IP blocks; you must request PTR record delegation from your upstream provider for your assigned ranges.
Q: What is DNSSEC and do I need it?
A: DNSSEC (DNS Security Extensions) adds cryptographic signing to DNS records, allowing resolvers to verify that a response was issued by the legitimate authoritative server and was not tampered with in transit. Each zone has a Zone Signing Key (ZSK) and a Key Signing Key (KSK). Records are signed with the ZSK, and the chain of trust is anchored at the root zone. DNSSEC protects against cache poisoning and spoofing but does not encrypt queries — for that you need DNS over TLS or DNS over HTTPS. For public-facing zones hosting sensitive services, DNSSEC is strongly recommended. It does add operational complexity: keys must be rotated, signatures have expiry times, and misconfiguration can make your entire domain unresolvable.
Q: What is DNS over TLS (DoT) and how is it different from regular DNS?
A: Standard DNS queries are sent in cleartext over UDP or TCP port 53. Any on-path observer — an ISP, a rogue Wi-Fi hotspot, or a network monitoring appliance — can read every DNS query your machine makes. DNS over TLS (DoT, RFC 7858) wraps DNS queries inside a TLS session on TCP port 853, encrypting the query and response between the client (or resolver) and the upstream resolver. This prevents passive eavesdropping and tampering of DNS traffic on the wire. DNS over HTTPS (DoH) achieves the same goal over HTTPS on port 443, making DNS traffic indistinguishable from regular web traffic.
Q: What are glue records and when are they required?
A: Glue records are A (or AAAA) records for name servers that are provided in the additional section of a TLD referral response. They are required when a domain's authoritative name servers are within the same domain being delegated — a circular dependency that would otherwise make resolution impossible. For example, if solvethenetwork.com is served by ns1.solvethenetwork.com, a resolver cannot find ns1.solvethenetwork.com without first knowing where solvethenetwork.com is served — a chicken-and-egg problem. The TLD registry breaks this cycle by including the IP addresses of ns1 and ns2 as glue in the delegation. When registering name servers within your own domain, you must provide glue records to your registrar.