05. DNS Mechanics

DNS is effectively a globally distributed, cached lookup system.

Clients request a specific record type (A, AAAA, MX, TXT, etc.), and authoritative servers return structured data. DNS does not interpret the meaning of that data. Applications decide how to use it.

Humans communicate using words. Computers route traffic using numbers.

DNS bridges that gap through a hierarchical and delegated architecture¹:

• DNS is hierarchical and distributed
• Recursive resolvers fetch and cache answers
• Authoritative nameservers define truth
• Delegation establishes authority
• TTL (time to live) controls caching duration
• DNSSEC (DNS Security Extensions) validates authenticity, not confidentiality

Treat DNS as infrastructure plumbing. Keep it simple, explicit, and predictable.

5.1. Resolution Flow

When a client requests example.com, DNS does not broadcast that request globally. It follows a defined chain of authority.

Resolution typically proceeds as follows²:

1. Stub Resolver (Client) The operating system forwards the query to a configured recursive resolver.

2. Recursive Resolver The resolver performs iterative queries on behalf of the client. If it already has a valid cached answer, it returns it immediately.

3. Root Nameservers The resolver asks the root: “Who is authoritative for the .com TLD?”

4. TLD Nameservers The .com registry responds with the authoritative nameservers for example.com.

5. Authoritative Nameserver The resolver asks the domain’s nameserver for the requested record (A, AAAA, MX, etc.).

6. Response Returned and Cached The recursive resolver returns the answer to the client and caches it according to TTL.

Each step narrows the search space.

Root → TLD → Domain → Record.

This hierarchy mirrors how authority is delegated in the DNS system.

Client
  |
Recursive Resolver
  |
Root (.)
  |
TLD (.com)
  |
Authoritative (example.com)
  |
Answer (A / AAAA / MX / etc.)

5.2. Recursive vs Authoritative Roles

DNS has two primary operational roles.

Recursive Resolver

• Accepts queries from clients
• Performs iterative lookups
• Caches responses
• Does not own domain data

Recursive resolvers reduce load on authoritative servers and improve performance through caching. They are not part of your domain’s control surface.

Authoritative Nameserver

• Hosts the official zone file for a domain
• Provides final answers
• Does not recurse outward

If you change DNS providers, you are changing authoritative nameservers. If you change recursive resolvers (e.g., ISP vs public DNS), you are changing who performs lookups on your behalf.

5.3. Core Record Types

DNS is a record-based system. Each label in a domain can hold one or more records of specific types. Each record type answers a different category of question.

5.4. Delegation and Nameservers

DNS authority is established through delegation.

At the TLD level, your domain is associated with one or more nameservers. These nameservers are responsible for answering authoritative queries about your domain.

example.com → ns1.provider.net  
example.com → ns2.provider.net  

This mapping is stored at the TLD registry. When a recursive resolver reaches the TLD layer during resolution, it receives the list of authoritative nameservers for the domain. It then queries those servers directly for records.

Changing nameservers changes who is authoritative for your domain.

Editing records changes data inside the current authority.

Delegation Change

When you update nameservers at your registrar:

• You are changing which DNS provider is authoritative
• The TLD registry updates its delegation
• Recursive resolvers will begin querying the new nameservers once cached delegation records expire

This is sometimes referred to as “nameserver propagation,” but it is simply cache expiration at the TLD layer.

Record Change

When you edit an A, AAAA, MX, or TXT record:

• You are modifying data inside the authoritative zone
• No registry change occurs
• Propagation depends only on the record’s TTL

Record edits and delegation changes operate at different layers of the hierarchy.

Root (.)
  |
TLD (.com)
  |
example.com → ns1.provider.net
             ns2.provider.net
                  |
            Zone File (A, AAAA, MX, TXT)

Operational Implications

• If records are not updating as expected, confirm which nameservers are authoritative
• Mixing registrar DNS and third-party DNS is a common source of errors
• Changing nameservers is a higher-impact change than editing records
• Delegation changes may take longer to appear because TLD-level records are also cached

When troubleshooting DNS issues, first verify:

1. Which nameservers are delegated at the registry
2. Which nameservers are actually answering queries
3. Whether the expected records exist in the authoritative zone

5.5. Zones and the Start of Authority (SOA)

A zone is the complete set of DNS records served authoritatively for a domain.

When you edit records in a DNS provider’s dashboard, you are modifying the domain’s zone file.

A zone contains at minimum:

• An SOA (Start of Authority) record
• NS (nameserver) records
• All defined A, AAAA, MX, TXT, CNAME, and other records

The zone represents the authoritative truth for that domain.

The SOA Record

Every DNS zone contains exactly one SOA record.

The SOA defines:

• The primary nameserver
• Administrative contact
• Serial number
• Refresh interval
• Retry interval
• Expire interval
• Default negative TTL

The serial number is particularly important. It allows secondary nameservers to determine whether the zone has changed. When the serial increases, replicas know to fetch updated data.

Primary and Secondary Nameservers

Authoritative DNS is typically replicated across multiple servers. One server is designated as primary. Others operate as secondary replicas. Secondary servers periodically check the SOA serial number. If it has changed, they synchronize the updated zone.

This replication provides availability and resilience. It does not change authority.

Negative Caching

If a resolver queries for a record that does not exist, the authoritative server returns a negative response. This response is also cached according to the SOA’s negative TTL value⁵.

Newly created records may appear not to exist until negative caches expire.

Operational Implications

• A DNS provider’s dashboard is an interface to a zone file
• Changes increment the SOA serial (automatically in most managed DNS systems)
• Authoritative servers replicate the zone based on serial comparison
• Resolvers cache both positive and negative responses

Understanding zones explains why DNS behavior can appear inconsistent during transitions.

5.6. DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic signatures to DNS records⁶. Without DNSSEC, recursive resolvers trust responses based on matching query IDs, source addresses, and transport-layer assumptions.

With DNSSEC, DNS responses are digitally signed. Resolvers can validate that the data was not modified in transit.

What DNSSEC Protects Against

DNSSEC helps mitigate:

• DNS cache poisoning
• Certain man-in-the-middle attacks
• Forged DNS responses

It validates authenticity of DNS data.

DNSSEC does not:

• Encrypt DNS traffic
• Hide queried domain names
• Prevent DDoS attacks
• Prevent domain suspension by a registry

Chain of Trust

DNSSEC works through a hierarchical chain of trust.

1. The DNS root zone is signed
2. TLD zones (e.g., .com) are signed
3. Your domain zone is signed
4. A DS (Delegation Signer) record at the TLD links your domain to its public key

If each link in the chain validates, the resolver can trust the final answer.

Key Components

DNSSEC introduces additional record types that support signing and validation⁷:

Enabling DNSSEC

To enable DNSSEC:

1. Your DNS provider must support zone signing
2. Your registrar must support publishing DS records
3. The TLD must support DNSSEC

If the DS record is incorrect or mismatched, resolvers will treat the domain as invalid. DNSSEC failures are fail-closed. If validation fails, resolvers will not return the record⁸.

Operational Implications

• DNSSEC improves authenticity, not confidentiality
• It adds operational complexity
• Misconfiguration can render a domain unreachable
• Managed DNS providers typically automate key rotation and signing

For personal self-hosted infrastructure, DNSSEC is optional but defensible. For publicly reachable services with long-term domain stability, enabling DNSSEC is reasonable.

DNSSEC strengthens the integrity of DNS data. It does not change who controls the namespace.

5.7. Layer Boundaries Matter

DNS resolution, delegation, zone authority, and DNSSEC operate at different layers of the same system. Most operational mistakes come from confusing these layers.

Treat them as separate responsibilities.