How DNS works: a step-by-step guide for UK beginners

You type a website name, and the page appears. DNS helps make that possible by resolving names into the information needed to find services. It is often compared with a directory, but the real process involves several cooperating systems and a useful amount of caching.

This walkthrough uses example.com as a documentation domain. It describes a simplified lookup when the resolver needs fresh information. A real visit may skip several steps because suitable data or an existing connection is already available.

Meet the main participants

These are roles, not necessarily five boxes you own. The resolver may be provided by your internet provider, business network or another configured service. The domain's authoritative DNS is chosen separately by whoever manages the domain.

Step 1: a hostname needs resolving

The browser interprets the URL and identifies the hostname. For https://www.example.com/about/, it needs information for www.example.com. The /about/ path is handled later by the web service; it is not part of the DNS record name.

The browser or operating system may already have useful cached information. An existing usable connection can also reduce the work needed. This is why a network trace does not always show a complete fresh lookup on every page visit.

Step 2: the device asks its configured resolver

The local resolution system sends a request towards a recursive resolver. The request concerns a name and record type, such as A for IPv4 or AAAA for IPv6. Applications may ask for more than one kind of information.

The recursive resolver checks its cache. If it has a usable answer, it can return it without beginning at the root. If it has a relevant cached referral, it may start further along the hierarchy.

Step 3: the resolver obtains a root referral

For an uncached path, the resolver contacts a root nameserver to find where to continue. The root does not need to hold the website's page or the final server address for every domain.

Its answer directs the resolver towards the appropriate top-level-domain service. For the documentation name example.com, that involves .com. For a UK name, the hierarchy involves .uk and any relevant delegations below it.

Step 4: the resolver follows the TLD delegation

The resolver asks the relevant TLD service and obtains information pointing towards the domain's authoritative DNS. This delegation is connected with the nameserver settings managed through the domain's registrar and registry arrangements.

A nameserver change affects this route. It tells resolvers which authoritative provider should answer, rather than moving website content by itself. The old delegation may remain cached temporarily by some resolvers.

Step 5: the authoritative service answers

The resolver asks an authoritative nameserver for the requested data. For a website hostname, the response may contain an address record or an alias that requires further resolution.

An A record gives IPv4 information; AAAA supplies IPv6 information. A CNAME identifies another hostname as the alias target. The resolver follows the relevant DNS process for that target as needed.

The authoritative provider is where the active zone is published. A saved record in some other hosting panel does not influence the lookup unless that panel controls the currently authoritative service.

Step 6: validation and caching are applied

A validating resolver can check DNSSEC information where the necessary signed chain is present. Successful validation concerns DNS data authenticity; it does not establish that the website's content or business practices are trustworthy.

The resolver can retain an answer for its permitted cache lifetime. Records carry TTL information, while negative answers have their own caching rules. Caching reduces repeated queries and helps later lookups complete with less work.

It also explains why changing a record does not instantly update every user. A resolver may still hold the old answer until its relevant cache lifetime passes.

Step 7: the device receives usable information

The resolver returns the result to the device. If suitable address information is available, the browser can attempt the connection required by the website protocol.

DNS itself has not downloaded the page. Network routing, the destination service, HTTPS and the application still have work to do. A successful lookup can therefore be followed by a connection failure or a certificate warning.

Step 8: the website responds to the request

For HTTPS, the browser establishes a protected connection and checks the certificate for the hostname. It then requests the resource through HTTP. The server or application returns content, a redirect, an error or another appropriate response.

The page may request images and scripts from additional hostnames, generating further lookups if needed. A single page can therefore work partly while a separate asset service fails.

Repeated visits usually take a shorter route

The full hierarchy is easiest to understand as a fresh lookup, but caches make ordinary use more efficient. A recursive resolver can already know a delegation or final answer, while the browser may retain information or reuse a suitable connection. It does not ask the root for every image on every page.

When demonstrating the process, distinguish the conceptual stages from an observed trace. A short trace is not evidence that the hierarchy is missing; it may simply show cached information being reused. That is normal behaviour, not an error to repair.

How the process changes for email

A sending mail system looks up the destination domain's MX records to find where incoming messages should go. It may then resolve the mail-server hostnames into addresses. This is different from looking up the website's A record.

TXT and other relevant records support sender authentication and verification. Moving a website does not require moving the mail service, provided the correct mail records remain available.

Four common reasons DNS appears to fail

Incorrect or missing records

The active zone may contain an old address, an absent hostname or an incorrect mail route. Compare the authoritative answer with the provider's actual instructions. Waiting does not repair a wrong source value.

Delegation or provider problems

The parent may identify the wrong nameservers, or the authoritative service may not serve the expected zone. Check registration and delegation separately from the website server.

Cached earlier answers

One network can see an old destination while another sees the new one. Compare resolver answers and TTLs with the authoritative data rather than treating every difference as an outage.

Registration or DNSSEC issues

An expired or suspended domain can disrupt resolution. A broken DNSSEC chain can also produce failures on validating resolvers. Check the actual domain state and validation evidence before changing records.

A beginner's investigation checklist

Write down the exact hostname, error and time. Ask which DNS provider is authoritative, what answer is expected and what a lookup currently returns. Tools such as dig and nslookup can inspect A, AAAA, MX and NS records separately.

Once resolution is correct, move on to the server, certificate and application. Keeping those layers distinct makes support requests clearer and prevents unnecessary domain changes in response to a missing page or a broken form.