When DNS
stops working.

01 / The fundamentals

How a name becomes an address.

When an application needs a name, the device normally asks a recursive resolver. That resolver may already have the answer in its cache. If not, it follows DNS delegation to ask the name’s authoritative servers, which publish records for that domain, and returns the result.

A name can have IPv4 addresses in A records and IPv6 addresses in AAAA records. DNS also carries information used by services such as email. A cached answer has a lifetime, called a time to live or TTL; resolvers and devices can keep answers for a time, including some unsuccessful responses.

02 / Recognize the symptoms

What might people notice?

A slow resolver can add delay to a lookup. It is only one part of the time required to load an application; changing DNS will not increase the physical speed of an Internet circuit or fix every slow website.

03 / Troubleshooting

Check before changing settings.

1. 01

   Define the scope

   Record the affected name, time, error message, device, and network. Check whether the issue affects several users or just one, and whether other public and internal names work.

2. 02

   Ask the configured resolver

   On macOS, Windows, or Linux with nslookup installed, open a terminal and run the first command below. Use a public name appropriate to your situation. The output identifies the DNS server queried and its response.

3. 03

   Compare an approved public resolver

   If company policy permits and the network allows it, run the second command to ask Cloudflare directly. This is a diagnostic query; it does not change system DNS settings, but the public resolver receives the queried name. Do not send confidential internal names to it.

4. 04

   Share the evidence

   Give your IT team or provider the results, affected names, timestamps, and scope. A successful DNS answer does not prove the website or application itself is healthy.

nslookup stealth.net

nslookup stealth.net 1.1.1.1

If the normal query times out while the comparison succeeds, investigate the configured resolver, its upstreams, and the path to it. If both fail for one name but other names work, the domain’s records or authoritative servers may be involved. A direct query may be blocked or redirected by network policy, affected by VPN routing, or fail at the resolver; a difference alone does not identify the cause. The command may not follow the same DNS path as a browser using encrypted DNS or an application using VPN-specific resolution.

An NXDOMAIN response says the queried name was reported as nonexistent. SERVFAIL indicates the resolver could not complete the lookup. A timeout means no response arrived in time. Each is evidence to investigate, not a complete diagnosis. Valid answers may differ between resolvers because of caching, location, filtering, or DNS configuration.

04 / Public resolvers

Well-known public DNS options.

These widely used services offer public recursive DNS. Their addresses are useful for comparisons or for a network design approved by your IT team. A primary and alternate address from the same provider improve address and path options, but they remain dependent on that provider’s service.

These are examples, not a ranking. Review the provider’s current documentation, privacy policy, filtering, support model, and behavior on your network. Filtering can block harmful domains, but it is not complete protection and legitimate domains can sometimes be blocked.

05 / Business networks

Keep internal names and controls working.

Many businesses use managed DNS for internal applications, Active Directory, VPN access, security filtering, or private cloud services. Public resolvers normally cannot answer private company names. Replacing managed DNS on a workstation or firewall can break those services or bypass company policy.

Your IT team can design internal resolution and forwarding for public names as appropriate. If you use different external providers for resilience, check that their filtering and answers are compatible with the services you need. Operating systems and resolvers do not all use a primary and alternate in the same order; an alternate is not guaranteed to stay idle until a failure.

06 / Security & privacy

Know who can see the queries.

Your DNS resolver can see the names it is asked to resolve. Review the provider’s logging, retention, filtering, and data handling against your business requirements. Some systems also use security products that depend on visibility into DNS traffic.

Traditional DNS is commonly sent without encryption. DNS over HTTPS (DoH) and DNS over TLS (DoT) can encrypt queries between a compatible client and its configured resolver; entering a public IP address alone does not enable either. Encryption does not hide queries from that resolver or automatically encrypt every later connection.

DNSSEC validation can help a resolver detect certain forged or altered DNS responses for signed domains. It is not a confidentiality tool and does not establish that a website or business is trustworthy.

07 / Resilience

Plan for more than one failure.

Two Internet circuits can still use the same DNS resolver. Likewise, two resolver addresses may be operated by the same organization or reached through shared infrastructure. Ask which failures the design can tolerate and whether a backup resolver uses equivalent security and internal-name policies.

If your business operates a domain, also review its authoritative DNS: provider diversity where appropriate, registrar access, DNSSEC configuration, and the procedures for making and checking changes. Redundant authoritative servers need correct records and delegation to be useful.

Test from representative office, remote, and VPN connections. Record expected behavior, alerting, ownership, and recovery steps; repeat after meaningful changes. Our Internet redundancy guide covers shared risks elsewhere in the connection.

08 / Planning checklist

Questions for your IT team.

• Which resolvers do office, remote, VPN, and managed devices use?
• Which internal applications and identity services depend on private DNS?
• Who operates the recursive and authoritative services, and how are their failures detected?
• How are backup resolvers selected, and do they enforce compatible security policies?
• What information is logged, for how long, and where?
• Are encrypted DNS and DNSSEC validation used where appropriate?
• Who can change DNS and registrar settings, and how are changes tested and rolled back?
• Have both IPv4 and IPv6 resolution and connectivity been tested where the business uses them?