DNS Fundamentals

The Domain Name System, or DNS, is a distributed database and a query-response protocol. It connects domain names to typed data called resource records.

People often describe DNS as an Internet phone book. That comparison explains name-to-address lookup, but it misses most of the design. DNS also delegates authority, directs email, publishes service information, and caches both positive and negative answers.

The key idea is division of responsibility. No single server stores every answer. The DNS namespace forms a tree rooted at the DNS root. Administrators divide that tree into zones and delegate child zones to other authoritative servers.

The resolution path

Your application normally sends a question to a recursive resolver. The question includes a domain name and a record type. If the resolver has a usable cached answer, it returns that answer. Otherwise, it follows referrals through the hierarchy.

For a first lookup of www.example.com, the path can look like this:

application
    -> recursive resolver
    -> root server
    -> com authoritative server
    -> example.com authoritative server
    -> recursive resolver cache
    -> application

The root server does not usually return the final address. It refers the resolver toward servers for com. A server for com refers it toward servers for example.com. An authoritative server for example.com can then answer from that zone.

This distinction gives you two separate jobs:

• A recursive resolver finds answers on behalf of clients and caches results.
• An authoritative server answers from data for a zone it serves.

A server can perform more than one role, but the roles remain different. During troubleshooting, identify which role produced the response.

Names, zones, and delegation

A domain name is an ordered list of labels. Dots separate labels in presentation format. The final root label is usually omitted, so www.example.com and www.example.com. can represent the same fully qualified domain name.

A zone is an administratively managed portion of the namespace. A zone is not the same thing as a domain. A delegation creates a boundary where authority for a child name moves to another set of servers.

An NS record names an authoritative server for a zone. The parent zone publishes delegation information that directs resolvers to the child. Address records supplied with a referral can act as glue when the resolver needs an address to reach the delegated server.

Resource records

Every resource record has an owner name, type, class, time to live, and type-specific data. The Internet class is written as IN.

Common types include:

Type	Main purpose
A	Map a name to an IPv4 address
AAAA	Map a name to an IPv6 address
CNAME	Make one owner name an alias for another name
MX	Identify mail exchangers and their preference values
NS	Identify authoritative servers for a zone
SOA	Describe a zone's authority and administrative values
PTR	Point from a reverse-DNS name to another domain name
TXT	Store one or more character strings

The requested type matters. A successful A lookup does not prove that an AAAA, MX, or TXT record exists at the same name.

Caching and change

Each record has a time to live, or TTL. A resolver may reuse cached data while its TTL remains valid. This reduces latency and repeated queries, but it also delays how quickly a changed answer reaches every client.

DNS also caches negative answers. NXDOMAIN means the queried name does not exist. A NOERROR response with no requested record can mean the name exists but has no data of that type. These outcomes are different, and their cached results can continue until the applicable negative TTL expires.

Treat a DNS change as a distributed cache transition. Lowering a TTL shortly before a change helps only after older cached records with the previous TTL have expired.

Responses and transport

DNS responses include a response code and sections for the question, answer, authority information, and additional information. Common response codes include NOERROR, NXDOMAIN, and SERVFAIL.

Classic DNS uses both UDP and TCP. Most traditional queries use UDP, while a full DNS implementation must support TCP. A response can signal truncation so the client retries with a transport that can carry the complete response.

Security boundary

Classic DNS does not prove that received data is authentic. DNS Security Extensions, or DNSSEC, add origin authentication and integrity protection for DNS data through signed records and a chain of trust.

DNSSEC does not encrypt DNS data or hide the names you query. It also does not prove that the host named by a valid record is safe or available. Authentication of DNS data is one layer of a larger security design.

When DNS is useful

Use DNS when clients need stable names while addresses or service targets may change. Use delegation when different teams or providers must control different parts of one namespace. Use record types that express the actual routing or discovery requirement.

Do not treat DNS as an instant global configuration store. Caching is part of the protocol. Do not treat one successful lookup as proof that every resolver sees the same answer. Resolver caches, delegation paths, record types, and local policy can differ.

A useful learning path

1. Learn names, labels, the root, zones, and delegation.
2. Trace the difference between a client, recursive resolver, and authoritative server.
3. Read common record types and response codes.
4. Predict positive and negative caching from TTL values.
5. Inspect referrals, authority sections, and complete answers with DNS tools.
6. Study DNSSEC validation and encrypted DNS transports as separate topics.
7. Practice isolating client, resolver, delegation, authority, and network failures.