Website owner reviewing DNS records that route a domain to web, mail and application servers

Editorial illustration; the records shown are examples, not a real domain.

You type your website address and get a browser error. The hosting dashboard says the server is running. Your colleague says the site works for them. Then someone suggests changing the nameservers, deleting an A record or moving the site to a new host.

That is how a small DNS problem turns into a much larger outage.

DNS, short for Domain Name System, is the part of the internet that helps a browser turn a name such as example.com into the address of a server. When that translation is wrong, incomplete or still changing around the internet, the website may appear offline even though the web server itself is perfectly healthy.

The useful question is not “Which DNS setting should I change?” It is “Which part of the journey is failing?”

Quick Answer

Start by checking the problem from more than one network. Then confirm which nameservers are authoritative, inspect the relevant DNS records, test the hostname that visitors actually use, and compare the result with the hosting provider’s expected target.

Do not change nameservers or delete records until you know which company is currently authoritative for the domain. A DNS fix should make one precise correction, followed by verification. It should not be a sequence of guesses.

What DNS Is Actually Doing

When a visitor opens www.example.com, several pieces can be involved:

  1. The domain is registered with a registrar.
  2. The registrar delegates the domain to a set of nameservers.
  3. Those authoritative nameservers publish records such as A, AAAA, CNAME, MX and TXT.
  4. A resolver used by the visitor looks up the record and may cache the answer.
  5. The browser connects to the returned destination.

These are separate responsibilities. Your registrar may be one company, your DNS provider another, and your website host a third. The control panel where you bought the domain is not necessarily the panel where the live DNS records are edited.

That distinction explains many confusing incidents. A developer edits an A record at the registrar, but the domain’s nameservers point to a different DNS provider. Nothing changes because the edited zone is not the live zone.

Step 1: Confirm the Scope of the Failure

First, record what fails and where. Try the bare domain and the www hostname separately. Test from a phone using mobile data and from the normal office or home connection. If possible, ask one person on another network to test without changing anything.

Pay attention to the exact message:

  • NXDOMAIN usually means the queried name does not exist from the resolver’s point of view.
  • A timeout can indicate a network path, firewall, nameserver or server availability problem.
  • A certificate warning means DNS may have worked, but the HTTPS identity or configuration is wrong.
  • An HTTP 404 or 500 means the request reached a web service; the problem is probably beyond basic DNS.

Do not treat every browser error as a DNS error. A failed application can still have perfectly correct DNS.

Step 2: Identify the Authoritative Nameservers

Find the nameservers delegated for the domain. You can use the registrar’s domain settings or a DNS lookup tool. The important result is not merely the nameserver names; it is knowing which provider is answering for the public zone.

For example, if the domain delegates to a managed DNS service, editing a similarly named zone at the hosting company will not change the public answer. Likewise, if you recently moved DNS providers, some systems may still show the old delegation while others show the new one.

Write down the nameservers before making a change. This simple note prevents a common mistake: changing a record in the wrong dashboard and then assuming the change needs more time.

Step 3: Check the Exact Hostname Visitors Use

The root domain and www are different DNS names. A record for example.com does not automatically guarantee that www.example.com works. The same is true for shop.example.com, api.example.com and a mail host.

Check the record for the failing hostname and compare it with the host’s documented target. An A record normally points to an IPv4 address. An AAAA record points to an IPv6 address. A CNAME points one hostname to another name.

One common trap is an outdated AAAA record. Some visitors connect over IPv6 and reach an old or unconfigured server, while others use IPv4 and see the correct site. If only certain networks fail, compare both address families instead of assuming the problem is random.

Step 4: Compare DNS with the Hosting Provider

Hosting dashboards usually tell you what destination a domain should use. That may be an IP address, a CNAME target or a platform-specific hostname. Compare the live public answer with that instruction character by character.

Check for:

  • An old IP address left after a hosting migration.
  • A CNAME pointing to a deleted project.
  • A typo in the hostname.
  • A record at the root that conflicts with the provider’s recommended setup.
  • A www record that points somewhere different from the bare domain.

If a hosting provider uses a changing or shared destination, follow its documented record type rather than copying a value from a different project. The correct fix is often to restore the provider’s intended mapping, not to guess a new IP.

Step 5: Consider Caching Without Blaming It for Everything

DNS answers can be cached by browsers, operating systems, home routers, corporate resolvers and public DNS services. A record’s TTL, or time to live, tells resolvers how long they may keep an answer before asking again. It does not guarantee that every cache will refresh at exactly the same moment.

After a valid change, different users may temporarily receive different answers. That is normal during propagation. However, “DNS propagation” is not a useful explanation for an obviously wrong record at the authoritative nameserver. If the authoritative answer is wrong, waiting will not repair it.

To separate caching from an authoritative configuration problem, query the domain through more than one resolver and compare the result with the authoritative answer. Keep a timestamped note of what you changed so you do not make a second change while the first is still being observed.

Step 6: Check DNSSEC Carefully

DNSSEC adds signatures that let validating resolvers detect tampered or invalid DNS responses. It can improve trust, but a mismatch between the domain’s delegation and its signing configuration can make the domain fail for validating users.

This often appears after changing DNS providers while leaving an old delegation-signing record at the registrar. If the timing matches a nameserver migration and some resolvers report a DNSSEC-related failure, ask the registrar and DNS provider to verify the DS record and signing state together.

Do not disable security features casually. First determine whether the signing configuration is consistent with the authoritative provider.

Step 7: Remember That Email Uses Different Records

Fixing a website record should not involve deleting mail records. Email delivery commonly depends on MX records, while SPF, DKIM and DMARC use TXT records. A domain can serve a website correctly while email is broken, or the other way around.

Before editing the zone, make a short inventory of important services: website, email, verification records, APIs and third-party services. Remove only records that you can identify as obsolete. “Clean” DNS is not the same as an empty DNS zone.

Common Mistakes to Avoid

The most expensive DNS errors are usually simple:

  • Changing nameservers when only one record is wrong.
  • Editing a non-authoritative DNS zone.
  • Deleting MX or TXT records while fixing a website.
  • Checking only the root domain and forgetting www.
  • Ignoring AAAA records because IPv4 works.
  • Making several changes before the first one can be verified.
  • Treating an application error as proof that DNS is broken.

Take a screenshot or export the current zone before a major change. If another person manages the domain, communicate the exact record, old value, new value and reason. DNS work becomes much safer when it is reversible and documented.

A Calm Recovery Workflow

When a real incident happens, use this order:

  1. Record the browser error, hostname, time and networks affected.
  2. Confirm the authoritative nameservers.
  3. Query the failing hostname and inspect A, AAAA or CNAME answers.
  4. Compare those answers with the hosting provider’s expected destination.
  5. Check whether the web server responds directly, if the provider gives you a safe test address.
  6. Make one targeted correction.
  7. Re-test from a second network and monitor both the bare domain and www.
  8. Check email and other services before declaring the incident over.

If the record is correct but the browser still fails, move on to TLS, firewall, CDN, web-server and application checks. DNS is the beginning of the request path, not the entire path.

Why This Matters

DNS is easy to ignore because it usually works silently. But it is also a high-leverage dependency: one incorrect delegation or address can make every page, API call or email workflow appear unavailable. A documented zone, clear ownership and a small change process reduce the chance that a rushed fix creates a second outage.

Small websites benefit especially from this discipline. You may not have a network team, but you can still keep a record of where DNS is hosted, which services depend on it and what the expected values are.

My Take

The best DNS troubleshooting habit is to stop thinking of DNS as a mysterious “internet setting”. It is a chain of named responsibilities. Once you identify who is authoritative, which hostname fails and what destination is expected, the problem becomes much less dramatic.

I would rather spend five minutes documenting the current records than spend an hour changing settings that belong to different providers. A calm lookup is usually more valuable than a clever fix.

Bottom Line

When a website is down but the server appears healthy, verify the DNS path before rebuilding anything. Check scope, nameservers, exact hostnames, A and AAAA records, provider targets, caching and DNSSEC. Preserve email records, make one reversible change and verify from more than one network.

That process will not solve every outage, but it will tell you whether DNS is actually the problem—and prevent a guess from becoming the next one.