DNS Basics

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

An application normally asks a configured recursive resolver. If the answer is not cached, that resolver follows referrals through the hierarchy until it reaches an authoritative source.

A recursive query asks the server for a final result. An iterative query permits the best information available, often a referral. In common operation, the client makes a recursive request and the recursive resolver performs iterative work upstream.

1. The application asks the operating system's stub resolver.
2. The recursive resolver checks its cache.
3. On a miss, it asks a root server, then the relevant TLD server.
4. It asks an authoritative server for the requested record.
5. It validates the response when DNSSEC validation is enabled, caches it, and replies to the client.

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	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.

Messages, Transport, EDNS and Cookies

Traditional DNS uses port 53 over UDP for most queries and TCP when required, including responses that do not fit the permitted UDP size and operations such as full zone transfer. Modern implementations may also reuse TCP connections.

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.

EDNS(0) extends DNS without replacing the header. Its OPT pseudo-record advertises capabilities such as a larger UDP payload and carries extended flags and response codes. DNS Cookies exchange client and server cookies to improve request/response matching and provide limited protection against off-path spoofing; they are not encryption or user authentication.

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.

Common risks include spoofed or poisoned answers, open-recursion abuse, amplification, unauthorized domain or record changes, registrar takeover, tunnelling, algorithmically generated domains, and outages caused by bad delegation or expired domains. No single DNS control addresses all of them.

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.

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.