What Is DNS and How Does It Work?

The Domain Name System (DNS) translates memorable names such as example.com into technical information used by internet services. It works like a distributed directory: people use the name, while software looks up the address or service information required for a website, email delivery, or verification.

The path of a DNS query

When a user enters a domain, the device asks a resolver, usually operated by an ISP or a public DNS service. If the result is not cached, the resolver follows the DNS hierarchy to the domain's authoritative nameservers and requests the relevant record. It returns the answer and stores it temporarily for later queries.

Authoritative nameservers and the DNS zone

Authoritative nameservers hold the official DNS zone for a domain. The zone is the collection of records describing its services. Nameservers indicate who can answer authoritatively; records provide the actual destinations. Explore that distinction further in the guide to nameservers.

Common record types

• A maps a hostname to IPv4.
• AAAA maps it to IPv6.
• CNAME makes one hostname an alias of another.
• MX identifies mail servers and their priorities.
• TXT publishes verification data and policies such as SPF, DKIM, or DMARC.

These records have separate jobs. Changing a website's A record does not move its mail service automatically.

TTL and caching

Time To Live tells a resolver how long it may cache an answer before asking again. Caching reduces latency and query load. A lower TTL can help during a planned change, but it cannot erase an answer already cached under the previous value and does not make every resolver refresh simultaneously.

Why changes may appear at different times

Resolvers cache records at different moments. Browsers, operating systems, company networks, and ISPs may add their own caching layers. The gradual expiry and refresh of these answers is commonly called DNS propagation. It is not a single file being copied worldwide.

Registrar, DNS provider, and hosting provider

The registrar manages registration. The DNS provider operates the authoritative zone. The hosting provider runs the website or application. One company can perform all roles, but the roles remain distinct. Identifying them prevents changing records in a dashboard that is not authoritative.

Safe operational thinking

Before editing DNS, record the current values, confirm the intended destination, and change only what the service requires. Test the authoritative answer as well as one or more public resolvers. Waiting cannot correct an inaccurate IP or a missing record; the source data must be right first.

A simple zone example

example.com might have an A record for the web server, a CNAME for www, two MX records for mail, and TXT records for verification and DMARC. No single record contains the website. Each publishes one precise piece of service information.

From an application request to the destination service

The sequence begins with a browser or application asking a recursive resolver for an answer. If no valid cached response exists, the resolver follows the DNS hierarchy until it reaches the authoritative nameservers for the zone. It requests the record type associated with the hostname, then returns an IP address, another hostname, a mail destination, or verification data.

A recursive resolver performs the lookup on behalf of the client and caches the result. An authoritative DNS server does not search elsewhere for data within its own zone; it publishes the official records it holds. This distinction explains how an authoritative answer can already contain a new value while a resolver legitimately returns an older cached response.

Website and email records are independent

The apex domain may have A and AAAA records, www may be a CNAME, and MX records may route email to another provider. TXT records can publish SPF, DKIM, DMARC, or service-verification tokens. A website migration can therefore change web records without touching mail. Replacing an entire zone without inventory, however, can remove a record for an apparently unrelated service.

What an incorrect record can cause

A wrong A or AAAA value can send visitors to the wrong server or create different behaviour over IPv4 and IPv6. A broken CNAME can point to a hostname that does not exist. Incorrect MX values can interrupt inbound mail, and faulty TXT policies can affect verification or deliverability. DNS may be responding normally while returning operationally wrong information.

The TTL lifecycle

When a resolver caches an answer, its remaining TTL counts down. The cached value may be reused until expiry. The next query then retrieves a fresh authoritative response and starts a new cycle. This design improves speed and resilience, but it also makes planning important when destinations change.

One domain can route several independent services

DNS does not send every request to one destination. The root domain can point the website to one platform, www can be an alias, MX records can route mail to another provider, and TXT records can publish verification or authentication information. That separation explains why a website can work while email fails, or the reverse. When diagnosing a problem, identify the affected service and inspect the record type responsible for it instead of treating the whole DNS zone as a single switch.

Frequently asked questions

Does DNS store the website?

No. It publishes routing and service data; files and databases live on the host.

Is a DNS zone the same as nameservers?

No. The zone is the record set; nameservers are the authoritative servers publishing it.

Does every DNS change cause downtime?

No. Preparation, validation, and overlap reduce risk, although zero downtime cannot be guaranteed for every configuration.