DNS Records & Concepts
What is authoritative DNS?
Authoritative DNS refers to the nameservers and the DNS infrastructure that hold the definitive, official DNS records for a domain. When a recursive resolver needs to find the IP address for example.com it ultimately queries the authoritative DNS for that domain, the nameservers that hold the zone data configured by the domain owner. The authoritative nameserver returns the actual record value from the zone file, not a cached copy, not an approximation, but the current authoritative truth.
The word authoritative is precise, these nameservers speak with authority about the domains they serve. An authoritative DNS response is one that comes directly from the nameserver holding the zone data for the queried domain. It carries the flag aa: authoritative answer, in the DNS response indicating the response came from the authoritative source rather than from a cache or intermediate resolver.
Authoritative DNS is the write side of the DNS system, the infrastructure where domain owners configure and update their DNS records. Recursive resolvers are the read side, they query authoritative nameservers and distribute the answers to clients worldwide through caching. Every DNS record that a browser or application ultimately receives originated as an authoritative answer from an authoritative nameserver before being cached and distributed.
How authoritative DNS works
Authoritative DNS operates through nameservers that hold DNS zones: the collections of DNS records for specific domains. When a domain owner adds a CNAME record, updates an A record, or configures an MX record they are making changes to the zone data on the authoritative nameservers for their domain.
When a recursive resolver performs a DNS lookup and reaches the authoritative nameserver for a domain the authoritative nameserver processes the query against its zone data and returns the matching record. The response includes the record value, the TTL, and the authoritative answer flag. The recursive resolver receives this authoritative response, caches it, and serves it to clients.
The authoritative nameserver does not perform recursive resolution, it only answers questions about the zones it holds. If a resolver queries an authoritative nameserver for example.com about a domain it is not authoritative for, say otherdomain.com: the authoritative nameserver either returns a referral to the correct nameserver or returns an error indicating it has no authority for the queried domain.
This limited scope is intentional. Authoritative nameservers are specialists, they know everything about their zones and nothing about zones they do not hold. Recursive resolvers are generalists, they know how to find the answer for any domain by navigating the DNS hierarchy to the appropriate authoritative nameserver.
Authoritative vs recursive DNS
The distinction between authoritative and recursive DNS describes two fundamentally different roles in the DNS infrastructure that work together to make domain resolution function.
Authoritative DNS: holds zone data for specific domains. Returns authoritative answers about those domains. Does not perform recursive lookups. Does not cache records from other zones. Operated by DNS providers, domain registrars, and organisations managing their own DNS. Every domain has authoritative nameservers specified in its NS records.
Recursive DNS: performs lookups on behalf of clients. Queries authoritative nameservers to find answers. Caches results for the TTL duration. Returns answers to clients without exposing the full resolution process. Operated by ISPs, public resolver services, and organisations for their own users. Every client device is configured with recursive resolver addresses.
The workflow combines both. A client queries its recursive resolver. The resolver queries root nameservers, then TLD nameservers, then the authoritative nameserver for the domain. The authoritative nameserver returns the record. The resolver caches it and returns it to the client.
Neither type can function effectively without the other. Authoritative nameservers without recursive resolvers would require every client to implement the full resolution process themselves, impractical. Recursive resolvers without authoritative nameservers would have no source of ground truth for DNS records.
How authoritative nameservers are designated
The designation of authoritative nameservers for a domain happens through the DNS delegation hierarchy, the system of NS records that specify which servers hold authority for which zones.
Domain registration: when a domain is registered the registrar stores the nameserver information and submits it to the TLD registry. The TLD registry publishes NS records in the TLD zone, .com, .net, .org: delegating authority for the domain to the specified nameservers. Any recursive resolver that needs to look up a record for the domain is referred to these nameservers by the TLD.
Zone configuration: the domain owner configures DNS records in the zone at the authoritative nameservers. Adding an A record, CNAME record, MX record, or any other record type creates or updates entries in the zone file. The authoritative nameservers serve these records in response to queries.
NS records in the zone: the zone itself contains NS records identifying its authoritative nameservers. These zone-level NS records should match the delegation NS records at the TLD level. A mismatch between zone NS records and TLD delegation records can cause resolution inconsistencies.
Changing authoritative nameservers: updating the nameserver settings at the registrar changes the delegation records at the TLD level. After the change propagates all recursive resolvers are referred to the new nameservers for the domain. The new nameservers must have the zone configured before the change is made, otherwise DNS resolution fails for the domain during and after the transition.
Types of authoritative nameservers
Authoritative DNS infrastructure takes several forms depending on the scale, requirements, and technical sophistication of the domain operator.
Registrar-provided nameservers: when a domain is registered most registrars provide authoritative DNS hosting as part of the registration. The domain owner manages records through the registrar’s control panel. The registrar’s nameservers serve as the authoritative DNS for the domain. This is the simplest setup, DNS management and registration in one place, but registrar DNS quality varies significantly.
Managed DNS provider nameservers: dedicated DNS providers, Cloudflare, Route 53, Google Cloud DNS, NS1, DNSimple, and others, operate authoritative nameserver infrastructure as their primary business. Domains point to the provider’s nameservers through a nameserver change at the registrar. The DNS provider’s control panel or API manages records. Managed DNS providers typically offer better performance, reliability, security, and features than registrar-provided DNS.
Self-hosted authoritative nameservers: organisations with specific requirements, internal DNS resolution, custom features, compliance requirements, operate their own authoritative nameserver software. BIND, Berkeley Internet Name Domain, is the most widely deployed open-source authoritative nameserver. PowerDNS, Knot DNS, and NSD are alternatives. Self-hosted nameservers require operational expertise to maintain correctly, software updates, security patches, monitoring, and hardware management.
Cloud DNS services: AWS Route 53, Google Cloud DNS, and Azure DNS provide authoritative DNS as cloud services integrated with their respective cloud platforms. Domains using these services benefit from the cloud provider’s global infrastructure while maintaining programmatic control through APIs. Particularly appropriate for domains whose web infrastructure already runs on the same cloud platform.
Authoritative DNS and anycast
Modern authoritative DNS infrastructure overwhelmingly uses anycast routing, announcing the same IP addresses from multiple geographic locations simultaneously. Network routing directs each DNS query to the nearest announcement point based on network topology rather than geographic distance strictly.
Anycast provides two critical benefits for authoritative DNS.
Low latency: queries are answered by the nearest anycast node rather than routing to a central location. A resolver in Europe queries an authoritative nameserver and reaches a European node. A resolver in Asia reaches an Asian node. Response times are consistently low regardless of where in the world the query originates.
Resilience: if one anycast location becomes unavailable, power failure, network problem, hardware failure, queries automatically route to the next nearest location. No single point of failure exists. The same IP address continues to be reachable from working locations while the failed location is offline.
Cloudflare, AWS Route 53, Google Cloud DNS, and most major managed DNS providers use anycast for their authoritative nameserver infrastructure. Anycast is one of the key reasons managed DNS providers offer significantly better performance and reliability than self-hosted nameservers on non-anycast infrastructure.
Authoritative DNS and zone transfers
DNS zones can be distributed across multiple authoritative nameservers, a primary server where records are managed and secondary servers that receive copies through zone transfers. Zone transfers keep all authoritative nameservers in sync with the same zone data.
AXFR, full zone transfer: transfers the complete zone file from primary to secondary. All records are included regardless of whether they changed. Simple but inefficient for large zones.
IXFR, incremental zone transfer: transfers only the records that changed since the last successful transfer. The secondary specifies its current serial number and receives only the differences. More efficient for large zones with frequent small changes.
Zone transfer security: unrestricted zone transfers expose all DNS records for a domain to anyone who can query the nameserver. The complete zone data, every record type including internal records, is visible to anyone who can initiate a transfer. Authoritative nameservers should restrict zone transfers to specific IP addresses, only the IP addresses of authorised secondary nameservers.
Modern managed DNS providers do not use traditional zone transfers internally, they use proprietary synchronisation that pushes changes to all nameservers simultaneously. Zone transfers remain relevant for organisations running self-hosted authoritative nameservers in primary-secondary configurations.
Authoritative DNS response codes
Authoritative nameservers return specific response codes that indicate the outcome of a query. Understanding these codes helps interpret DNS query results and diagnose issues.
NOERROR with answer: the query was successful and the requested record was found. The response includes the record value in the answer section. The authoritative answer flag is set.
NOERROR without answer, NODATA: the query was successful and the domain exists but there is no record of the requested type. Querying for an AAAA record for a domain that only has an A record returns NOERROR with an empty answer section. The domain exists but the specific record type does not.
NXDOMAIN: the queried domain name does not exist in the zone. No records of any type exist for this name. Recursive resolvers cache NXDOMAIN responses for the minimum TTL duration from the SOA record.
SERVFAIL: the authoritative nameserver encountered an error processing the query. May indicate a configuration problem, a DNSSEC validation failure, or a server error. Does not indicate the domain does not exist, only that the query could not be answered correctly.
REFUSED: the authoritative nameserver refused to answer the query. Common when zone transfers are attempted from unauthorised IP addresses or when queries are received from sources that have been blocked.
Authoritative DNS and DNSSEC
DNSSEC, DNS Security Extensions, is implemented at the authoritative DNS layer. Domain owners configure DNSSEC signing on their authoritative nameservers adding cryptographic signatures to DNS records that validating resolvers can verify.
Zone signing: the authoritative nameserver signs all records in the zone with a private key. The corresponding public key is published in the zone as a DNSKEY record. The public key hash is submitted to the parent zone, the TLD, as a DS record establishing the chain of trust.
Signature records: each signed record has a corresponding RRSIG record containing the cryptographic signature. When a resolver requests a record the authoritative nameserver returns both the record and its RRSIG. Validating resolvers verify the signature using the public key from the DNSKEY record.
Key management: DNSSEC requires managing cryptographic keys with care. Keys have validity periods and must be rotated periodically, key rollover. Incorrect key rollover, removing the old key before the new key has propagated, breaks DNSSEC validation for the domain causing SERVFAIL for validating resolvers.
Managed DNS providers that support DNSSEC handle key generation, signing, and rollover automatically, abstracting the complexity from domain owners. Self-hosted DNSSEC requires careful attention to key management procedures.
Authoritative DNS and redirect management
Authoritative DNS is the foundation on which redirect management is built, the records configured in the authoritative zone determine where DNS routes visitors before any HTTP redirect can be applied.
DNS records connect domains to redirect infrastructure: adding a CNAME record or A record in the authoritative zone pointing to redirect management infrastructure is what connects the domain to the redirect service. The authoritative nameserver serves these records to recursive resolvers which cache and distribute them to visitors worldwide. Without the correct authoritative zone records no visitor reaches the redirect infrastructure regardless of what redirect rules are configured.
Changes to authoritative records propagate: when redirect configuration requires DNS changes, connecting a new domain updating infrastructure IP addresses adding verification TXT records, those changes are made in the authoritative zone. The authoritative nameserver immediately serves the new values to any resolver that queries it. Propagation to resolvers worldwide happens as their cached copies of old records expire according to the TTL.
TTL control at the authoritative level: the TTL on DNS records is set in the authoritative zone. Domain owners control propagation speed by configuring TTL values, lower TTLs mean faster propagation of changes to redirect infrastructure. The pre-migration TTL reduction strategy, lowering TTL before making planned DNS changes, is executed by updating TTL values in the authoritative zone.
Verification records in the authoritative zone: redirect management platforms often require TXT records or CNAME records in the authoritative zone for domain ownership verification and SSL certificate provisioning. These are configured in the zone like any other record and are queried by the platform from the authoritative nameserver as part of the verification process.
Checking authoritative DNS
Several tools allow querying authoritative nameservers directly, bypassing resolver caches to see the current authoritative values.
dig to authoritative nameserver: first find the authoritative nameservers then query one directly:
Returns the authoritative nameserver hostnames. Then query one directly:
Returns the A record directly from the authoritative nameserver, not from any resolver cache.
dig with authoritative answer flag: the aa flag in dig output indicates an authoritative answer. An authoritative response shows flags: qr aa rd: the aa flag distinguishes it from a cached resolver response which would not include aa.
dig +trace: traces the full resolution path from root through TLD to authoritative nameserver showing the delegation at each step and the final authoritative answer:
Checking for zone consistency: querying multiple authoritative nameservers for the same record verifies they are all serving consistent data. Inconsistencies between authoritative nameservers indicate a zone transfer problem or configuration mismatch:
Both should return the same value. Different values indicate the nameservers are out of sync.