DNS Architecture and Domain Management: Performance, Security, and Disaster Recovery

Published: May 23, 2026 · Author: Marcin Szewczyk-Wilgan

This article covers DNS architecture from the level of a single query all the way to disaster recovery strategies. Topics include query recursion anatomy, a comparison of authoritative servers (BIND 9, NSD) and resolvers (Unbound), record types and their security implications (CAA, DNSSEC), encrypted DNS transports (DoH, DoT, DoQ), GeoDNS, split-horizon, and procedures for recovering from a domain takeover.

Introduction – DNS as the most overlooked single point of failure

The Domain Name System (DNS) is a fundamental layer of internet infrastructure without which no website, email service, or API endpoint functions. Yet DNS remains the most frequently overlooked single point of failure (SPOF) in web application architecture. Engineers spend weeks optimizing databases and web servers while treating DNS configuration as a one-time task done at domain registration and never revisited.

The consequences can be catastrophic. In April 2026, a DNS hijacking attack on the CoW Swap platform – carried out through social engineering targeting the Finnish registry Traficom – caused losses of approximately $1.2 million USD. Users typed the correct domain address and were silently redirected to an identically styled malicious copy of the site.

Operation FrostArmada, disclosed in April 2026 by the FBI, Microsoft, and the UK's NCSC, revealed that APT28 (GRU) had seized DNS control over more than 18,000 SOHO routers across 120 countries, conducting mass surveillance of internet traffic.

Anatomy of a DNS query – from browser to authoritative response

When a user types an address into a browser, the operating system initiates a cascade of queries that typically completes in under 50 milliseconds – but involves multiple layers of infrastructure along the way.

Local cache and the system resolver

The first checkpoint is the operating system's local cache. If the domain was recently visited and its record has not yet expired (TTL is still positive), the answer is returned immediately without any network contact.

When the cache is empty, the query goes to the recursive resolver – the DNS server configured in network settings (for example Cloudflare's 1.1.1.1, Google's 8.8.8.8, or a local Unbound instance). The resolver takes over responsibility for finding the answer.

Recursion – traversing the DNS hierarchy

The recursive resolver performs the lookup in several steps:

• It queries one of the 13 root servers, which point to the servers responsible for the top-level domain (TLD), such as .com or .uk.
• The TLD server points to the authoritative name servers for the specific domain (for example ns1.example.com).
• The authoritative server returns the final answer – the IP address associated with the requested name.

Each step is a separate network query. The resolver caches intermediate answers, so subsequent queries for the same TLD or authoritative server skip the already-visited layers.

TTL and its role in performance and migrations

The TTL (Time To Live) value tells the resolver and client how long they may cache a response before re-querying the authoritative server.

Choosing TTL is an engineering trade-off. A high TTL (for example 86400 seconds – 24 hours) minimizes queries to the authoritative server and speeds up name resolution for users. A low TTL (for example 300 seconds – 5 minutes) allows rapid propagation of changes but increases load on the DNS server.

TTL strategy is critical during server migrations. At least 48–72 hours before a planned IP address change, reduce the TTL to 300 seconds. After the migration and verification of the new server, restore the production value (3600–86400 seconds). Skipping this step means a portion of users will continue reaching the old server for many hours, even after the DNS records have been updated.

Authoritative servers versus recursive resolvers

One of the most common configuration mistakes is conflating two fundamentally different DNS server roles.

The authoritative server – source of truth

An authoritative server stores and serves DNS records for the zones it is responsible for. It does not perform recursion – it answers only queries for its own zones.

Two dominant open-source solutions exist:

BIND 9 (Internet Systems Consortium) – the oldest and most feature-rich DNS software, combining authoritative and recursive resolver functions in a single process. Current production releases are 9.18.x (ESV, supported through 2026) and 9.20.x (ESV). BIND 9 supports DNS over HTTPS (DoH) and DNS over TLS (DoT). In May 2026 ISC released security updates (9.18.49, 9.20.23) patching six vulnerabilities, including memory leaks in DNSSEC validation code.

NSD (NLnet Labs) – a lightweight, high-performance authoritative-only server, designed for raw throughput. It deliberately does not implement recursion. NSD is the default authoritative server on FreeBSD and OpenBSD.

The recursive resolver – client intermediary

A recursive resolver accepts queries from clients and performs full recursion independently, caching results.

Unbound (NLnet Labs) – a validating, recursive resolver with built-in DNSSEC support, DNS over TLS, and DNS over HTTPS. The current production release is 1.25.1. Unbound replaced BIND as the default resolver on FreeBSD and OpenBSD, where it is considered smaller, more modern, and more secure. In May 2026 NLnet Labs released patches for four vulnerabilities (including CVE-2026-42923 – a denial-of-service via uncontrolled NSEC3 hash computation).

The recommended production architecture separates the roles: NSD as the authoritative server combined with Unbound as the recursive resolver. BIND 9 is the right choice where a single service handling both roles is needed, but at the cost of a larger attack surface and more complex configuration.

DNS record types and their architectural impact

Address records: A, AAAA, and the CNAME limitation

An A record maps a domain name to an IPv4 address; an AAAA record maps it to an IPv6 address. In production environments both should be configured (dual-stack), as an increasing number of mobile operators and devices prefer IPv6.

A CNAME (Canonical Name) record creates an alias pointing to another domain name. It has an important constraint: it cannot coexist with other record types under the same name. This means a CNAME cannot be placed at the zone apex (for example example.com), where SOA and NS records must live. Some DNS providers (Cloudflare, Route 53) offer a pseudo-record called ALIAS (or ANAME) that behaves like a CNAME but is resolved server-side at the authoritative level and returns an IP address directly.

MX, SRV, and service records

An MX (Mail Exchanger) record designates the mail servers for a domain. Priority values (lower number = higher priority) allow backup servers to be configured. An SRV (Service) record extends this concept to arbitrary services, specifying port, priority, and weight.

CAA – controlling SSL certificate issuance

A CAA (Certification Authority Authorization, RFC 8659) record specifies which certificate authorities (CAs) are permitted to issue SSL/TLS certificates for a domain. Since 2017, all public CAs are required to check CAA records before issuing any certificate.

The absence of a CAA record means any CA may issue a certificate for the domain. Configuring CAA is one of the simplest yet most effective defenses against unauthorized certificate issuance. The record is inherited hierarchically – a CAA set on the root domain covers all subdomains automatically.

A minimal production CAA set should include the issue tag (permitted CAs), the issuewild tag (permitted CAs for wildcard certificates), and the iodef tag (an email address for notification of unauthorized issuance attempts).

DNSSEC – cryptographic zone signing

How it works

DNSSEC (DNS Security Extensions) adds a cryptographic layer to DNS responses. The authoritative server signs records with a private key, and validating resolvers verify the signatures using the public key published in the parent zone – forming a chain of trust that leads back to the DNS root servers.

This allows a resolver to detect whether a response was modified in transit (man-in-the-middle attack) or originates from a rogue server (cache poisoning). DNSSEC does not encrypt queries – it protects only the integrity of responses.

Adoption landscape

Despite more than two decades in existence, global DNSSEC adoption remains low. An analysis of 240 million domains from February 2026 found that only 4.27% have DS (Delegation Signer) records confirming active signing. Resolver-side validation is higher – EU average 49.4%, global 35.4% (JRC data, Q3 2025).

Nordic ccTLDs (.se, .no, .dk) achieve 70–75% adoption thanks to aggressive registry policies and pricing incentives. The strongest predictor of adoption is not security awareness among domain owners but whether the DNS provider enables DNSSEC automatically – analogous to the HTTPS revolution driven by Let's Encrypt and Cloudflare.

Operational risks

DNSSEC introduces additional operational complexity. Failing to renew signing keys (key rollover) or misconfiguring DS records in the TLD registry causes validating resolvers to reject responses – making the domain unreachable for users whose resolvers enforce DNSSEC. Deploying DNSSEC therefore requires automated key rotation and continuous signature health monitoring.

Encrypted DNS: DoH, DoT, and DoQ

DNSSEC protects the integrity of responses but does not conceal the content of queries. Any network intermediary – an ISP, a corporate firewall, a coffee shop router – can see which domains a user is visiting. Encrypted DNS transports solve this problem.

DNS over TLS (DoT) – port 853

DoT (RFC 7858) encrypts DNS queries with TLS on dedicated port 853/TCP. The advantage is transparency for network administrators: DoT traffic can be easily identified and controlled (blocked or permitted) at the firewall. The disadvantage is that same transparency – restrictive networks can simply block port 853. Typical latency is 20–25 ms.

DNS over HTTPS (DoH) – port 443

DoH (RFC 8484) wraps DNS queries inside standard HTTPS on port 443. Queries are indistinguishable from regular web traffic, making blocking difficult. Major browsers (Firefox, Chrome) enable DoH by default. Typical latency is 12–18 ms – lower than DoT thanks to better HTTPS infrastructure optimization. The downside is reduced visibility for corporate network administrators.

DNS over QUIC (DoQ) – the protocol of the future

DoQ uses the QUIC protocol (UDP), combining low latency (no TCP three-way handshake) with built-in encryption. Adoption is still in early stages, but broader deployment is expected from 2027 onward, particularly on mobile devices and in environments with unreliable connectivity.

Recommendations: for production servers, run Unbound as a local resolver with DoT to upstream providers (such as 1.1.1.1 or 9.9.9.9). For end users, DoH in the browser delivers the best combination of privacy and performance. For corporate networks, DoT at the firewall with DNS traffic inspection is the right balance.

GeoDNS and latency-based routing

GeoDNS is a technique that returns different IP addresses depending on the geographic location of the client. The querying resolver is identified by its IP address (or via the EDNS Client Subnet mechanism – ECS, RFC 7871), and the authoritative server responds with the address of the geographically nearest server.

Common applications include routing European users to a European CDN edge while directing North American users to a US node, minimizing round-trip latency. A more advanced variant – latency-based routing – measures actual network latency rather than relying on approximate geographic location.

GeoDNS is available through managed DNS services (Cloudflare, Route 53, Hetzner DNS) or through self-hosted BIND 9 with the GeoIP module.

Split-horizon DNS – separating views

Split-horizon (also called split-brain DNS) is a technique that returns different answers depending on where the query originates. A typical use case: internal corporate network users receive private IP addresses for services (for example 10.0.1.50 for a staging environment), while external users receive public production addresses.

In BIND 9 this is implemented using view blocks; in Unbound it is handled through the local-zone mechanism combined with access-control. Split-horizon is especially useful in environments with separate staging and production instances, avoiding the need to maintain /etc/hosts overrides on developer machines.

DNS monitoring and alerting

DNS deserves the same monitoring rigor as databases and web servers. Key metrics to track include:

• Resolver response time – a rise above 100 ms signals a connectivity problem or server overload.
• Authoritative server availability – checked from multiple geographic locations, not just one.
• DNSSEC signature validity – an expired signature makes the domain unreachable to validating resolvers.
• Record consistency across NS servers – divergence indicates a configuration error or an incomplete zone transfer.
• MX and CAA record correctness – a broken MX means lost email; a missing CAA creates risk of unauthorized certificate issuance.

Tools such as dns-oarc/dnsmon, check-soa, or simple cron-driven dig scripts allow early detection of problems. A DNSSEC signature expiry alert should be configured with at least 7 days of advance notice.

Disaster recovery – what to do when a domain is under threat

Domain expiry

An unpaid domain passes through several phases: grace period (30–45 days, renewal possible at no extra cost), redemption period (30 days, expensive renewal), and pending delete (5 days, after which it returns to the open pool). Once dropped, the domain can be seized instantly by domain sniping bots.

Defense: enable automatic domain renewal, configure registrar notifications, and monitor expiry dates independently (for example with a script that queries whois).

DNS hijacking and registrar compromise

An attacker gains access to the registrar control panel (phishing, social engineering, weak password) and changes the NS servers or A records. Effective defenses include:

Registry Lock – a lock at the domain registry level that requires manual verification by the registrar and the registry, often by phone, before any NS server change. This is the most effective defense against hijacking: even if an attacker compromises the registrar account, they cannot alter critical records without this additional authorization. Available for .com, .net, .pl, and most ccTLDs.

Two-factor authentication (2FA) on the registrar account – an absolute minimum. In 2025 the FTC imposed sanctions on GoDaddy for failing to enforce MFA and for inadequate security monitoring.

Transfer Lock – prevents unauthorized transfer of the domain to a different registrar.

Recovery plan

A DNS disaster recovery procedure should include: a full backup of zone configuration (zone file export), documentation of all records (A, AAAA, MX, CNAME, TXT, CAA, NS, SRV) in a Git repository, a contact list for the registrar and registry with an emergency escalation procedure, and a secondary DNS provider at an independent operator serving as a backup NS.

Recovery time (RTO) for DNS depends on the TTL of propagated records – after restoring correct entries, full propagation takes anywhere from a few minutes (low TTL) to 48 hours (high TTL on some resolvers).

Conclusion

DNS is a layer that is easy to configure once and forget – but whose failure paralyzes the entire infrastructure. Proper separation of roles (authoritative server vs resolver), deliberate TTL selection, deployment of DNSSEC and CAA, encrypted DNS transports (DoT/DoH), signature health monitoring, and Registry Lock together form the foundation of a secure and performant domain architecture.

The incidents of 2025–2026 – from Operation FrostArmada to the CoW Swap domain takeover – demonstrate that DNS is an active attack vector, not merely a theoretical risk. Investing in DNS security is many times cheaper than the cost of reputation recovery and reclaiming a hijacked domain.

FAQ – DNS and domain management