Typing a web address feels like asking one simple question: where is this site? The answer may come from the browser’s memory, a resolver across town, or an authoritative server several referrals away. DNS makes that chain feel instant most of the time—which is why it can be so confusing when an old answer refuses to disappear.

Underneath, DNS maps names such as www.example.com to records that applications can use. It is distributed rather than kept in one global database, allowing each organization to manage its part of the namespace while resolvers cache answers close to users.

The Main Roles in a DNS Lookup

Several roles take part in a typical lookup, but they are not necessarily separate machines.

Stub resolver

An application usually asks the operating system’s stub resolver for an answer. The browser or operating system may already have a cached result. If not, the stub sends a recursive query to a configured resolver.

Recursive resolver

A recursive resolver accepts the task of finding a complete answer. It may be operated by a home router, an ISP, an organization, or a public DNS provider. It is normally also a caching resolver and may forward some or all queries to another resolver.

If the answer is not cached, the resolver performs iterative queries through the DNS hierarchy:

  1. A root server refers it to the relevant top-level-domain servers, such as those for .com.
  2. A TLD server returns the delegation for the requested domain.
  3. An authoritative server for the relevant zone returns the record or a negative response such as NXDOMAIN. That denial is cryptographically authenticated only when DNSSEC supplies valid signed proof, normally through NSEC, NSEC3, or another standardized DNSSEC mechanism.

There is no special “second-level domain server” role. The final server is authoritative for a DNS zone, and zone boundaries do not always match the labels people informally call second- or third-level domains.

Authoritative server

An authoritative server publishes data for a zone. It answers from configured zone data rather than recursively looking up the name on behalf of the client. Root and TLD servers are themselves authoritative servers for their respective zones.

Delegation, Glue, and Caching

A parent zone delegates a child zone through NS records. When a delegated name server’s hostname is inside that child zone, the parent may also need to provide an address as a glue record. Glue breaks the circular dependency that would otherwise arise while trying to find the name server.

Most positive and negative answers can be cached. A record’s time to live (TTL) tells a resolver how long it may reuse that data. Changing a record does not instantly clear copies already held by resolvers, so DNS changes should be planned with existing TTLs in mind.

Common DNS Record Types

Zone and delegation records

  • SOA: Describes the zone’s administrative origin, serial number, and timing values used by authoritative servers and negative caching.
  • NS: Names an authoritative server for a zone or delegation.
  • DS: Publishes a digest of a child zone’s DNSSEC key in the parent, linking the chain of trust.

Address and alias records

  • A: Maps a name to an IPv4 address.
  • AAAA: Maps a name to an IPv6 address.
  • CNAME: Makes one owner name an alias of another canonical name. A CNAME normally cannot coexist with other data at the same owner name.
  • DNAME: Redirects descendants of one name to another subtree; it does not alias the DNAME owner itself.
  • PTR: Maps an address-derived name in a reverse-DNS zone to another name.

An APL record represents an address prefix list. It is a specialized record type and is not a general Internet routing mechanism.

Mail and service discovery

  • MX: Lists mail exchangers for a domain, with preference values.
  • SRV: Advertises the hostname and port for a named service.
  • NAPTR: Applies ordered rewrite rules and is often used with SRV in systems such as SIP.
  • URI: Publishes a URI associated with a service.
  • SVCB: Advertises an endpoint and connection parameters for a service.
  • HTTPS: A specialized form of SVCB for HTTP services. It can advertise alternative endpoints and parameters such as supported application protocols.

SVCB and HTTPS records overlap with some SRV use cases, but they are not drop-in replacements for every SRV deployment.

Text and policy records

  • TXT: Stores one or more character strings. Common uses include domain verification, SPF policy, and DKIM public keys.
  • CAA: States which certificate authorities are authorized to issue certificates for a domain.
  • TLSA: Associates a TLS service with certificate or public-key information for DANE, normally alongside DNSSEC.
  • SSHFP: Publishes SSH host-key fingerprints; clients need a trusted DNSSEC result for it to provide strong protection.

SPF policy is published in TXT records. The separate SPF record type was made obsolete.

DNSSEC records

  • DNSKEY: Contains a zone’s public DNSSEC key. The corresponding private key is kept off the public DNS and is used to create signatures.
  • RRSIG: Contains a signature over a DNS record set.
  • NSEC / NSEC3: Proves that a name or record type does not exist.
  • DS: Connects a signed child zone to its signed parent.

DNSSEC authenticates DNS data and detects tampering. It does not encrypt DNS queries or hide which names a client requests. DNS-over-TLS and DNS-over-HTTPS address transport privacy between a client and resolver, which is a different problem.

Less common records

Types such as HINFO, LOC, RP, SMIMEA, AFSDB, EUI48, and EUI64 exist for specialized uses but are uncommon on the public web. They should be introduced when a real deployment needs them, not simply because the record type exists.

A Practical Lookup

Tools such as dig show both the answer and the path used to obtain it:

Terminal window
dig example.com A
dig example.com MX
dig +trace example.com
dig +dnssec example.com

+trace follows referrals from the root, while +dnssec asks for DNSSEC-related data. Neither option by itself proves that a local validating resolver accepted the result; check the authentication status and the resolver’s configuration as well.

Conclusion

DNS is a hierarchy of delegated zones served by authoritative servers and queried through recursive resolvers. Understanding who is authoritative, what has been cached, and what each record actually represents makes domain changes easier to plan and DNS failures much easier to diagnose.