DNS explained: how names find websites and why lookups fail

What happens when you enter a website address?

Suppose you enter www.example.com in a browser. The browser and operating system first check whether a usable answer is already available. If another lookup is needed, the device asks its configured recursive resolver. That resolver may answer from its own cache or follow the DNS hierarchy to find the authoritative server responsible for the name. A response can contain an address or an alias that leads to another lookup. The device then uses the resulting information to attempt the website connection.

This distinction matters when diagnosing a failure. A correct DNS answer can still lead to a server that is unavailable, a blocked connection or a certificate error. Conversely, working Wi-Fi and a reachable router do not prove that name resolution works. Modern websites can use multiple addresses and content delivery networks, so two legitimate DNS answers may differ. Comparing only one address with an old screenshot is not enough to establish that either answer is wrong.

Resolver, authoritative DNS, domain registrar and hosting are different roles

The recursive resolver is the service your device normally asks. It is often supplied through the router by the internet provider, although a browser, VPN or device setting can select another resolver. The authoritative DNS service holds the records published for a domain. A registrar manages the domain registration and the delegation to its name servers. The website host runs the website. These roles can be handled by one supplier or several independent organisations.

A useful question is therefore: which part do you control? A home user can investigate the DNS settings on their own device or router, but cannot repair another organisation’s authoritative records. A domain administrator can amend records, but changing a visitor’s router will not repair a missing website record. A managed work network may deliberately use an internal resolver for private names. Replacing that resolver without permission can break business resources even while public websites appear to work.

Which DNS records affect websites and email?

A records associate a name with IPv4 addresses; AAAA records associate it with IPv6 addresses. CNAME records point a name to another name rather than directly to an address. MX records identify mail destinations and their preference values. TXT records carry text used for purposes such as domain verification and email authentication. NS records identify authoritative name servers. These records do different jobs, so copying only a website address during a migration can leave email or verification broken.

Use the exact record type, name and value supplied by the responsible service. A website can need separate records for the bare domain and www. Email authentication also uses specific names and syntax; an extra or contradictory record can cause problems. Do not treat every TXT record as disposable text. Keep a dated export or screenshot of the existing zone before a change, with account secrets protected. If you do not administer the domain, share the observation with its owner instead of guessing a replacement.

• A / AAAA: addresses associated with a host name.
• CNAME: an alias to another DNS name.
• MX: the mail servers designated for the domain.
• TXT: published text, including service verification and email-policy information.
• NS: the authoritative servers delegated for a domain.

Why does a DNS change appear on one device before another?

DNS answers have a time to live, usually called TTL. A cache can reuse an answer while that lifetime remains valid. A resolver that obtained the old record shortly before a change may keep answering with it, while another resolver that has no cached answer obtains the new record. Devices, browsers and recursive resolvers can each introduce caching. Failed lookups may also be cached. This is why the vague instruction “wait for propagation” should be replaced with a check of the actual delegation, records and relevant cache lifetimes.

Lowering a TTL immediately before changing a record does not retroactively shorten copies already cached with the previous TTL. Plan ahead when the domain is under your control. Clearing the cache on one laptop affects that laptop’s local cache, not every public resolver. Repeatedly changing the record while waiting makes diagnosis harder and can prolong inconsistent results. First confirm that the authoritative servers agree, record the old and new values, and allow existing valid cache entries to expire.

Read the failure before changing settings

A name-not-found result, often represented as NXDOMAIN, means the queried name was reported not to exist. Check spelling, the exact subdomain and whether the record exists. A timeout means no usable answer arrived within the allowed time; the resolver, network path or filtering may be involved. SERVFAIL indicates that the resolver could not complete the request. Misconfigured delegation, DNSSEC validation problems and upstream failures are among the possibilities. A browser’s simplified message alone does not establish the cause.

Separate the scope of the symptom. If one website fails but other websites and email work, investigate that name and service. If every name fails on one device, compare another device on the same network. If the whole network fails, inspect the router and provider connection before assuming DNS. An HTTP error, a login error or a certificate warning after a successful lookup belongs to a later stage. Do not bypass a certificate warning merely because a diagnostic tool returned an address.

• Write down the exact name, time, error and whether a VPN was connected.
• Compare the same name on a second device and, if available, a separate trusted connection.
• Record the resolver configured on the affected device and any browser secure-DNS setting.
• Ask for the relevant record type; do not rely on a website ping alone.
• Escalate an authoritative-record or delegation issue to the authorised domain administrator.

A safe troubleshooting sequence for a home or small office

Start with an observation that changes nothing: check whether the network connection is active, which resolver is configured and whether several unrelated names resolve. On Windows, nslookup can query a name through the configured resolver or through a specified server. Other platforms offer equivalent tools. Save the result, including the server used and record type. Querying an A record and finding no answer does not prove that a name with only an AAAA record is absent. A tool’s output needs interpretation in the context of the service.

Next compare the affected device with a working device. If browser secure DNS or a work VPN is active, it may use a different resolution path from the operating system tool. Test one authorised change at a time and keep a way to restore the previous setting. A temporary comparison with another resolver can help isolate a problem on a personal network, but it is not a universal repair. Managed networks, parental filters and private domains may require the original resolver. A factory reset is rarely an appropriate first diagnostic step.

• Preserve the original DNS configuration before an authorised change.
• Use a known legitimate diagnostic tool rather than a random “DNS repair” download.
• After a correction, retest the original failing name, email and any internal service.
• Remove temporary settings that are no longer needed and document the final configuration.

Encrypted DNS, DNSSEC and website safety answer different questions

DNS over HTTPS and DNS over TLS can encrypt the connection between a client and the resolver it uses. They do not make the user anonymous, hide all connection information or certify the destination. The chosen resolver still participates in the lookup. Browser settings can also differ from device settings, which explains why a name may work in one application but fail in another. Choose a resolver with an understood policy and avoid silently bypassing the rules of a work or school network.

DNSSEC allows validating resolvers to check signed DNS data and its chain of trust. It is not encryption and does not inspect a website for fraud or malware. A stale DS record after moving authoritative DNS can make a correctly entered address appear unavailable to validating resolvers. Domain administrators should follow their DNS provider’s documented migration procedure instead of switching DNSSEC off at random. Continue to use HTTPS, inspect unexpected login requests and keep account security separate from DNS troubleshooting.

Changing hosting without losing website or email access

A domain migration needs an inventory before it needs a change. Identify which supplier owns registration, DNS, hosting and email. Record the authoritative name servers and all service records that must survive. Confirm that the replacement DNS zone contains the required records before changing delegation. Check the provider’s DNSSEC instructions, including the handling of DS records at the registrar. Schedule the change with a rollback plan and a person authorised to update the domain.

Afterwards, verify the authoritative answers, the public website, incoming and outgoing email and any verification-dependent services. Keep the previous service available for the planned transition where practical. Do not assume that moving the website automatically moves mailboxes, or that changing name servers copies the old zone. If you are a visitor rather than the domain owner, the useful action is to report the exact failing name and time. Changing your own DNS cannot create a record that the domain has never published.

Example: the new website works, but email stops arriving

Imagine a small office moving its website to a new hosting platform. The administrator changes the domain’s name servers and sees the new homepage. Email then stops arriving. The DNS zone at the new provider contains the website address but lacks the previous MX records and required email-authentication records. This is an illustrative scenario, not a reported client result. The website and email use the same domain while depending on different DNS records.

The appropriate response is to compare the saved old zone with the new zone, obtain the exact mail records from the active mail provider and restore them through the authorised administrator. Check the actual authoritative responses before asking everyone to clear caches. Confirm that the mailboxes themselves remain active. Retest delivery in both directions and allow valid older cache entries to expire. Prevention is straightforward: inventory each service, preserve its records and verify the complete zone before changing name servers.