DNS

DNS is the distributed system that maps names to data. It helps applications find services, delegates authority between organizations, caches answers for speed, and provides a control point for availability and security.

What DNS Provides

The Domain Name System is both a hierarchical database and the protocol used to query it. Its best-known job is translating a name such as www.example.com into an IPv4 or IPv6 address, but DNS also publishes mail routes, service locations, zone authority, certificate policy, and security signatures.

Concept	Plain meaning
Forward lookup	Starts with a name and requests data such as an A or AAAA address.
Reverse lookup	Starts with an IP address and requests a PTR name under in-addr.arpa or ip6.arpa.
Resolver	Software that finds an answer. A host normally uses a small stub resolver, while a recursive resolver performs the wider search.
Authoritative server	Answers from zone data for which it is authoritative rather than looking elsewhere.
Resource record	One typed item of DNS data, such as an address, name server, or signature.

Read the DNS Namespace

A domain name is read from the most specific label on the left toward the DNS root on the right. The final dot in a fully qualified domain name is the root and is commonly omitted in everyday use.

• TLD: the level directly below the root. Examples include generic TLDs such as .com and country-code TLDs such as .in.
• Second-level domain: commonly the registrable name below a TLD, such as example in example.com.
• Subdomain: any delegated or organizational branch below another domain, such as eu.example.com.
• Label: one component between dots. A fully qualified domain name, or FQDN, identifies the complete path to the root.

How DNS Resolution Works

A typical DNS lookup uses both recursion and iteration. The difference is who is responsible for following referrals to find the answer.

Recursive — “Resolve it for me.” The client's stub resolver asks its configured recursive resolver for a final result. That server takes responsibility for the lookup, using cached data or querying other servers. It returns an answer or an error, rather than a referral for the client to follow.

Iterative — “Tell me the answer or who to ask next.” The requester sends non-recursive queries. Each server replies with the information it has: an answer, an error, or a referral to another server. The requester follows each referral itself. In a typical lookup, that requester is the recursive resolver, not the user's device.

One lookup, two kinds of work Find the A record for www.example.com

RecursiveThe client delegates the lookup

ClientApp + stub resolver

1 · Request a final answer

5 · Return 192.0.2.10

Recursive resolverChecks its cache first

IterativeBetween 1 and 5, the same resolver does this work

Same resolverStarts at the root

2 · Ask the root

Referral: .com servers

Root serverKnows the TLD servers

Same resolverFollows the referral

3 · Ask a .com server

Referral: example.com servers

.com TLD serverKnows the domain's servers

Same resolverFollows the next referral

4 · Request the A record

Answer: 192.0.2.10

Authoritative serverServes the example.com zone

What can shorten this path? A cached answer avoids upstream queries; a cached delegation can skip the root or TLD step. This diagram assumes neither is available and omits extra lookups such as aliases or nameserver addresses. A forwarding resolver may instead ask another resolver to complete the lookup. Before replying, the resolver validates DNSSEC when enabled and caches reusable data according to its TTL.

On the wire: RD=1 requests recursion; iterative queries use RD=0. A response with RA=1 advertises recursion support—it does not prove that upstream queries were needed.

DNS Caching and TTL

Caching reduces delay and upstream traffic. A result may exist in the browser, operating system, local network appliance, or recursive resolver cache. The record's time to live (TTL) tells a cache how long it may reuse that answer.

• Positive caching stores successful data such as an A record.
• Negative caching stores a proven absence, such as NXDOMAIN or NODATA, for a controlled period.
• Expiration removes the cached answer after its TTL. Changing authoritative data does not instantly remove older copies from caches.

Operational consequence: A short TTL permits faster change but increases query load. A long TTL improves cache efficiency but makes migrations and failover slower to reach every client.

DNS Server Roles and Enterprise Patterns

Role or pattern	Purpose
Recursive resolver	Finds a complete answer for a client and commonly caches it.
Caching resolver	Emphasizes reuse of earlier answers; most recursive resolvers also cache.
Forwarding resolver	Sends selected or all unresolved requests to another resolver instead of resolving them directly.
Authoritative server	Serves original data for a zone. A primary accepts the maintained copy; secondary servers synchronize copies.
Root or TLD server	Publishes referrals that guide resolvers toward the next delegated zone.
Stub zone	Holds limited delegation data to track the authoritative servers for another zone.
Conditional forwarding	Forwards only matching namespaces, often to a partner, cloud, or internal resolver.
Forward-only / forward-first	Forward-only fails if the forwarder cannot answer; forward-first may fall back to direct resolution.
Split-horizon DNS (split DNS)	Presents different internal and external views of the same namespace.

An enterprise commonly separates internal recursive resolution from public authoritative hosting. Central resolvers can apply policy and logging, while external authoritative servers publish only public zone data. Keep the layers redundant and avoid exposing recursive service to untrusted networks.

Essential Resource Records

Type	What it publishes	Typical use
A	IPv4 address	www.example.com → 192.0.2.10
AAAA	IPv6 address	www.example.com → 2001:db8::10
CNAME	Alias to a canonical name	Point one hostname to another; other data normally cannot coexist at that owner name.
MX	Mail exchanger and preference	Route mail to domain mail servers.
NS	Authoritative name server	Declare zone authority or a delegation.
TXT	Text strings	Publish verification and policies such as SPF data.
PTR	Name associated with a reverse address	Reverse DNS and service discovery.
SOA	Zone authority and timing metadata	Identify the zone apex, serial, and transfer timers.
SRV	Service priority, weight, port, and target	Locate a named service.
CAA	Certificate-authority policy	Authorize certificate issuers and reporting.
DNSKEY, DS, RRSIG	DNSSEC keys, delegation link, and signatures	Build and validate signed DNS data.
NSEC, NSEC3	Authenticated proof that a name or type does not exist	Validate negative DNSSEC answers.

Records with the same owner name, type, and class form a resource record set (RRset). DNSSEC signs RRsets rather than individual records in isolation.

DNS Messages and Transport

A DNS message contains the question, response data, and control information. Its basic structure is the same whether it travels over UDP or TCP.

Message part	Purpose
Header	Transaction ID, flags, response code, and section counts.
Question	Queried name, type, and class—normally class IN for Internet data.
Answer	Records that directly answer the question.
Authority	Authority or referral information, such as NS or SOA records.
Additional	Related data that may help complete resolution, including glue addresses or EDNS information.

Read a response: For dig www.example.com A, a shortened response might look like this. The data below is illustrative, not a live lookup.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24173
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:
;www.example.com.      IN  A

;; ANSWER SECTION:
www.example.com. 300   IN  A   192.0.2.10

• Header: id helps match the reply to its query; qr marks a response, rd reflects the recursion request, and ra advertises recursion support.
• Question and answer: the lookup requests an IPv4 address. The answer supplies 192.0.2.10 with a TTL of 300 seconds.
• Section counts: AUTHORITY: 0 means no authority records were included. Here, ADDITIONAL: 1 counts the OPT pseudo-record, which dig displays separately.
• EDNS: udp: 1232 advertises UDP payload capacity in bytes; it is not the actual response size.

UDP and TCP

Traditional DNS uses server port 53 for both transports. UDP avoids connection setup and is common for ordinary lookups. General-purpose DNS implementations must also support TCP; it can be selected from the start, reused for multiple queries, and is used for full zone transfers (AXFR).

Truncation fallback: UDP query → response marked TC=1 (truncated) → retry over TCP for the complete response. Blocking TCP/53 can therefore break lookups even when small UDP queries succeed.

EDNS: Extending the Message

Without EDNS, DNS messages over UDP are limited to 512 bytes. EDNS(0) adds an OPT pseudo-record in the Additional section to advertise a larger UDP receive capacity and carry extended flags, response codes, and options. OPT describes the exchange; it is not an ordinary zone record and is not cached.

Larger capacity is useful for DNSSEC and other large answers, but it does not guarantee delivery. Network packet-size limits and blocked IP fragments can still cause failures; TCP remains necessary.

DNS Cookies: Checking the Exchange

DNS Cookies are small protocol tokens carried as an EDNS option—not browser cookies. A client sends a client cookie; a supporting server returns it with a server cookie that the client includes in later requests. Checking these tokens helps reject forged traffic and limit amplification from off-path attackers, who cannot observe the exchange.

Both endpoints need to support Cookies for the protection to apply. Cookies do not encrypt traffic, authenticate a user, or validate DNS record contents; they do not replace DNSSEC or encrypted DNS.

Response Codes

Code	Meaning	First check
NOERROR	The server processed the query successfully. The answer can still be empty, producing NODATA for the requested type.	Inspect the answer and authority sections.
FORMERR	The server could not interpret the request.	Check malformed packets or unsupported formatting.
SERVFAIL	The server failed while processing the query.	Check upstream reachability, authoritative health, and DNSSEC validation.
NXDOMAIN	The queried domain name does not exist.	Check spelling, search suffixes, delegation, and negative caching.
NOTIMP	The requested operation is not implemented.	Check opcode and server capability.
REFUSED	The server rejected the operation by policy.	Check access controls, recursion policy, and transfer permissions.

Zones, Delegation and SOA

A zone is the portion of the namespace served as one administrative unit. Its apex is the top name in that zone, and a zone file is one possible representation of its records. Forward zones normally map names to data; reverse zones publish PTR records for address space.

A parent delegates a child zone with NS records at a delegation point. When a delegated name server is inside the child being delegated, the parent supplies address glue so resolvers can reach it without circular dependency.

Read an SOA record

example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. (
  2026091301 ; serial
  3600       ; refresh
  900        ; retry
  1209600    ; expire
  300        ; negative cache TTL
)

• The first name is the primary authority and the second encodes the responsible mailbox, with the first unescaped dot representing @.
• The serial changes when zone data changes. Secondaries compare it to decide whether synchronization is required.
• Refresh, retry, and expire control secondary-server synchronization. The final value contributes to negative caching.

Transfers, Dynamic Updates and TSIG

Secondary authoritative servers synchronize zone data from a primary. AXFR transfers a full zone; IXFR transfers changes when both sides support it. Restrict transfer sources and monitor failures because a transfer may expose the zone's full contents.

DNS UPDATE allows authorized clients to add or remove records dynamically, which is useful for DHCP-integrated registration and automation. Apply narrow update policies rather than broad write access.

TSIG uses a shared secret and HMAC to authenticate a DNS message and protect its integrity, commonly for transfers and updates. It does not encrypt the message and is different from DNSSEC: TSIG protects a transaction between parties that share a secret; DNSSEC lets validators authenticate published DNS data.

Security Fundamentals

Goal	DNS concern	Typical controls
Integrity	Prevent or detect altered answers and unauthorized zone changes.	DNSSEC validation, protected administration, TSIG, change control.
Authenticity	Confirm that data originates from the expected signed zone or trusted transaction peer.	DNSSEC, TSIG, authenticated encrypted resolver transport.
Confidentiality	Limit exposure of query names and responses in transit.	DoT, DoH, or DoQ between supported endpoints.
Availability	Keep resolution and authoritative service reachable under faults or attacks.	Redundancy, anycast, capacity, rate controls, monitoring, tested recovery.

Recognize the threat pattern

Threat	What happens and what to check
DNS spoofing	A forged response tries to make a client or resolver accept false data. Check unexpected answers against the appropriate authoritative source and inspect DNSSEC validation where available.
Cache poisoning	False data enters a resolver's cache and can affect later clients until removed or expired. Compare cached and authoritative answers; investigate the cause rather than only flushing the cache.
DNS tunnelling	Data or commands are encoded in DNS queries and responses. Look for unusual label lengths, query patterns, volume, and endpoint activity. TXT records and long names alone are not evidence of a tunnel.
Reflection and amplification	UDP queries spoof a victim's source IP, directing larger replies at that victim. Restrict recursion to intended clients, use appropriate response-rate controls, and prevent source-address spoofing at network boundaries.
Fast flux	A malicious domain rapidly rotates through IP addresses, often with short TTLs, to keep its infrastructure reachable and harder to block. Correlate address churn with reputation and endpoint activity; legitimate CDNs also rotate addresses.
Domain generation algorithms (DGA)	Malware generates candidate domain names to find command-and-control servers. Many failed lookups or unusual names may be clues, but generated names can also resemble ordinary words.
Random-name floods / NXDOMAIN abuse	Large numbers of distinct, nonexistent names can force extra resolution work and overload DNS services. Check query rate, name diversity, affected zones, and clients. NXDOMAIN itself is a normal response—not an attack verdict.

These patterns overlap: a forged answer may poison a cache, and DGA activity may produce NXDOMAIN spikes. Misconfiguration, typos, and legitimate applications can produce similar signals. Unauthorized zone changes, registrar takeover, and expired domains are separate risks addressed below.

DNSSEC

DNS Security Extensions add origin authentication, data integrity, and authenticated denial of existence to DNS data. DNSSEC does not encrypt queries, hide metadata, or guarantee service availability.

A validator begins with a configured root trust anchor, authenticates the root zone's DNSKEY data, and then follows each signed parent DS-to-child DNSKEY link until it can validate the requested RRset.

Keys, signatures and proof of absence

• A zone's private key creates signatures; public DNSKEY records let validators check them. The key tag helps identify a key and the algorithm field states the signing method.
• A Zone Signing Key (ZSK) commonly signs ordinary RRsets. A Key Signing Key (KSK) commonly signs the DNSKEY RRset and links to the parent's DS record. Implementations may use combined roles.
• An RRSIG has an inception and expiration time. Signing, publication, rollover, and clock accuracy must be coordinated.
• NSEC links existing names and lists present record types. NSEC3 uses hashed owner names to make casual zone enumeration harder. Both can authenticate NXDOMAIN and NODATA responses.

Validation states

State	Meaning
Secure	A valid chain reaches a configured trust anchor and the relevant signatures validate.
Insecure	No chain of trust exists for this unsigned branch, but that absence is properly established.
Bogus	Validation was expected but failed—for example because of a bad signature, missing proof, or broken chain.
Indeterminate	The validator cannot determine a conclusive state, often because required information is unavailable.

DNS Privacy and Encrypted Transport

Cleartext DNS can expose the names a client requests and the resolver it uses. Encrypted DNS protects the transport between participating endpoints, most commonly between a client and recursive resolver. It does not automatically encrypt resolver-to-authoritative traffic, remove metadata visible to the chosen resolver, or make an answer trustworthy.

Method	Transport	Key point
DoT	TLS over TCP, normally port 853	Dedicated encrypted DNS transport with resolver authentication when configured correctly.
DoH	HTTPS, normally port 443	Carries DNS in HTTP and can use HTTP/2 or HTTP/3.
DoQ	QUIC over UDP, normally port 853	Uses QUIC security and independent streams to reduce cross-query blocking.

Keep the distinction clear: DNSSEC authenticates DNS data and detects modification. DoT, DoH, and DoQ encrypt a transport hop and authenticate the resolver endpoint. They solve different problems and can be used together.

Filtering, RPZ, Sinkholes and Protective DNS

DNS filtering applies policy to queries or answers using allowlists, blocklists, categories, reputation, and contextual rules. A Response Policy Zone (RPZ) can trigger on query names, client addresses, response names, or response addresses, then return an action such as NXDOMAIN, redirection, a sinkhole answer, or pass-through behavior.

A sinkhole redirects selected domains to a controlled address. It can disrupt malicious connections and expose affected clients through connection logs, but the sinkhole must be isolated and operated safely. Protective DNS combines filtering with threat intelligence, analytics, policy responses, logging, and operational support. Evaluate coverage, latency, privacy, bypass resistance, false positives, and incident workflows—not only block counts.

Logging, Monitoring and SIEM

Collect the fields that support a defined use case rather than logging without purpose.

Area	Useful data
Query context	Timestamp, client IP or identity, resolver IP, queried domain, type, transport, and policy view.
Response context	Response code, answer, TTL, DNSSEC status, policy action, latency, query size, and response size.
Health	Query and response volume, response-code ratios, cache performance, resolver availability, authoritative reachability, and validation failures.
SIEM use	Normalize events, enrich domains and clients, correlate with endpoint or proxy activity, build focused dashboards, and alert on defined behaviors.

Examples worth investigating include repeated SERVFAIL spikes, sudden NXDOMAIN growth, rare or newly observed domains, unusually long labels, high-volume TXT queries, unexpected resolver use, DNSSEC failures, and clients contacting sinkhole addresses. Treat these as signals that require context, not proof of compromise.

Registrar Security and the Domain Lifecycle

A registry operates a TLD database, a registrar sells and manages registrations, and the registrant holds the registration rights. The registrar account is therefore part of the DNS security boundary.

• Protect registrar access with phishing-resistant MFA, least privilege, named accounts, and monitored recovery channels.
• Use registrar lock and, where justified, registry lock to reduce unauthorized transfers or changes.
• Track ownership, contacts, renewal dates, payment continuity, nameservers, DNSSEC delegation, and approved change history.
• Understand the provider and TLD-specific lifecycle: registration and activation, renewal, expiration, possible grace and redemption periods, deletion, and transfer. Do not assume every TLD uses identical timing.

DNS, PKI, CAA and DANE

Public certificate authorities commonly use DNS-related evidence during domain validation, so control of DNS and registrar accounts affects certificate security.

Mechanism	Purpose
CAA	issue authorizes normal certificate issuance, issuewild addresses wildcard issuance, and iodef can publish an incident-reporting destination. Issuers also account for CAA lookup and inheritance rules.
DANE	Publishes TLS certificate or public-key associations in TLSA records. Its authenticity depends on a valid DNSSEC chain.
DNSSEC and PKI	DNSSEC secures DNS data; Web PKI validates certificates through trusted certificate authorities. DANE deliberately connects the two trust models.

Availability, Anycast and Traffic Distribution

DNS resilience starts with independent authoritative servers and recursive capacity, tested failover, geographic and network diversity, monitored delegation, and recoverable configuration.

• Anycast announces the same service IP from multiple nodes. Routing normally carries a client to a nearby reachable node, improving distribution and failure tolerance.
• Multi-provider DNS reduces provider dependency but requires compatible zone data, DNSSEC planning, controlled synchronization, and consistent change processes. Models include primary-secondary and multi-primary arrangements.
• DNS-based distribution may return records by round-robin, weight, geography, or measured latency. It influences where new lookups go; caches and TTLs mean it is not an instantaneous connection-level load balancer.

Internationalized Domain Names

Internationalized Domain Names allow Unicode characters to be presented to users. DNS itself carries an ASCII-compatible A-label, commonly beginning with xn--; the readable Unicode form is a U-label. Applications convert between them using IDNA rules.

Security note: Visually similar characters from different scripts can produce deceptive names. Logging and investigation tools should preserve the original value and make the ASCII form easy to inspect.

Service Discovery, mDNS and DNS-SD

An SRV record identifies a service using priority, weight, port, and target. Lower priority values are preferred; weight distributes selection among records at the same priority.

_ldap._tcp.example.com. 3600 IN SRV 10 60 389 ldap1.example.com.

Multicast DNS (mDNS) provides local-link name resolution using multicast, commonly for names under .local, without a conventional unicast DNS server. Its scope and trust model differ from enterprise DNS.

DNS-Based Service Discovery (DNS-SD) combines PTR records for service enumeration, SRV records for host and port, and TXT records for service metadata. A service instance name identifies the advertised instance. DNS-SD can operate with multicast DNS on a local link or with conventional unicast DNS.

DNS64 and NAT64

DNS64 helps IPv6-only clients reach IPv4-only services through NAT64. When suitable AAAA data is absent, a DNS64 resolver can synthesize an AAAA record by combining an IPv6 prefix—possibly the well-known prefix—with the destination IPv4 address. NAT64 then translates the traffic.

This is a compatibility mechanism, not a general replacement for native IPv6. DNSSEC validation placement matters because synthesizing an answer can conflict with end-to-end validation of signed data.

Common DNS Tools

Tool	Useful command	Purpose
dig	dig example.com A	Inspect sections, flags, TTLs, server, and timing.
dig	dig +trace example.com	Follow delegation from the root; this does not reproduce every behavior of a normal recursive resolver.
dig	dig +dnssec example.com	Request DNSSEC records; requesting them is not the same as independently validating them.
nslookup	nslookup -type=mx example.com	Perform a widely available basic lookup.
Resolve-DnsName	Resolve-DnsName example.com -Type A	Query and inspect DNS from PowerShell.
host	host 192.0.2.10	Run a concise forward or reverse lookup.

A Practical Troubleshooting Workflow

1. State the exact question: record type, name, expected answer, affected client, resolver, and time.
2. Test the configured resolver: record the response code, answer, flags, TTL, latency, and DNSSEC status.
3. Compare deliberately: query another approved resolver or an authoritative server to separate client, cache, policy, delegation, and source-data problems.
4. Follow authority: inspect parent delegation, child NS records, glue, SOA serials, and server reachability over UDP and TCP.
5. Account for caching: check positive and negative TTLs before assuming an old answer proves a failed change.
6. Check the security layers: validation errors, filtering actions, encrypted-DNS policy, registrar changes, and recent zone updates.
7. Capture evidence: preserve commands, timestamps, queried servers, full responses, and relevant logs before making another change.

Start with the symptom

Symptom	Focused next check
Website does not load	Query the exact host's A and AAAA records and follow any CNAME chain. If the expected addresses resolve, continue into routing, TLS, and HTTP; a successful DNS answer does not prove the website is healthy.
Old answer after a change	Compare every authoritative server with the affected client's resolver, including TTLs and SOA serials. “Propagation” is not one global push: caches, negative answers, delegation changes, and incomplete provider updates can each delay the result.
Wrong answer or record missing	Check the full name, record type, zone, and intended DNS view. Split DNS can intentionally return different internal and external answers; a public resolver is not the reference for an internal-only name.
Incoming email fails	Use dig example.net MX, then resolve each MX target's A/AAAA records. Confirm the intended mail service and inspect the SMTP error too. An MX target must be a host name, not an IP address; see email routing and MX fallback.
Timeout or SERVFAIL	A timeout means no reply arrived; SERVFAIL means a server replied but could not complete the lookup. Compare approved resolvers and inspect reachability, delegation, and DNSSEC errors. Do not treat either as proof that the name does not exist.

Terminology Reference

Term	Concise definition
Stub resolver	Local client component that sends queries to a recursive resolver.
Recursive resolver	Server that finds a final answer for a client and usually caches it.
Authoritative server	Server that answers from authoritative zone data.
Zone	Administratively served portion of the DNS namespace.
Delegation	Parent-zone records that assign authority for a child zone.
Resource record / RRset	One typed DNS item / records sharing owner, type, and class.
TTL	Maximum time an answer may normally remain cached.
FQDN	Complete domain name extending to the DNS root.
TLD	Namespace level immediately below the root.
Trust anchor	Configured starting point for DNSSEC validation.
Forwarder	Resolver to which another resolver sends selected queries.
Glue record	Parent-side address data needed to reach an in-bailiwick delegated server.
Anycast	Routing design in which multiple nodes advertise the same service IP.
EDNS	Extension framework carried through the OPT pseudo-record.

Quick Recap

• DNS is a delegated hierarchy of zones, authoritative servers, resolvers, records, and caches.
• A recursive resolver follows referrals and caches the result for the record's TTL.
• Response codes, authority data, delegation, and cache state are as important as the visible answer.
• DNSSEC authenticates signed data; encrypted DNS protects a transport hop. Neither replaces resilient operations and access control.
• Enterprise DNS also supports policy, protective filtering, monitoring, service discovery, PKI controls, and IPv6 transition.
• Good troubleshooting compares the right sources and preserves exact evidence before changes are made.