What Is a DNS Server: Types, How to Find Yours and Fix It

In short. A DNS server turns a domain name into an IP address. A recursive resolver takes your query and finds the answer; root and TLD servers point the way; an authoritative server holds a domain's records. The address in your network settings, 1.1.1.1 or 8.8.8.8, is a recursive resolver. It caches, so DNS edits are never instant.

What is a DNS server, in plain words

Machines talk to each other over IP addresses such as 93.184.215.14. People type words. A DNS server is the translator between the two.

The word "server" here means two different things, and confusing them causes half of all DNS questions:

• Everyday meaning. "My DNS server" is the address configured on your network adapter or router: 192.168.1.1, 8.8.8.8, or whatever your ISP handed out. Technically that is a recursive resolver.
• Engineering meaning. Four distinct roles take part in resolution — root, TLD, authoritative and recursive. Each holds different data and answers a different question.

This article covers both readings: first the roles, then the practical side — how to find your resolver, change it, and what to do when it stops answering. For the protocol itself, record types and packet-level mechanics, see the companion piece: what DNS is and how it works.

What a DNS server does and does not do

It does: serve zone records — A and AAAA (addresses), MX (mail), TXT (SPF, DKIM, verification tokens), NS (delegation), CNAME, SRV, CAA. It caches other people's answers. It can filter — returning nothing instead of addresses for ad and malware domains.

It does not:

• Host your site. DNS hands back an address, nothing else. The content lives on a web server — different machine, often a different company.
• Carry your traffic. Once the browser has the IP, it connects to the site directly. Changing your DNS server does not change the route your packets take and does not speed up the page itself — only the first lookup, typically by tens of milliseconds.
• Guarantee the site is up. If the name resolves but the page will not load, DNS is not your problem. Check connectivity and the web server instead: ping, traceroute, response headers.

The DNS hierarchy: why one server is not enough

A single global database of every domain would be unmanageable. Instead there is a tree with an empty root on top, where each level only knows who the next level was delegated to:

           .  (root)
           |
       com / org / uk  (TLD — top-level domains)
           |
     example.com  (second-level domain)
           |
  www.example.com  (subdomain)

A fully qualified name always ends in a dot: www.example.com. — you rarely type it, but the resolver appends it anyway. That dot is the root.

The key principle: upper levels do not know website addresses. A root server does not know your domain's IP and never will — it only knows where to find the .com zone. The .com zone does not know your site's IP either — it knows which servers your domain was delegated to. Only the domain's own authoritative server returns the real address.

Root servers: 13 names, not 13 machines

The most persistent myth about DNS is that the whole internet rests on thirteen computers. It does not.

Thirteen is the number of names: a.root-servers.net through m.root-servers.net. Behind each name sits one IPv4 and one IPv6 address, and behind each address sits not a machine but a large number of sites worldwide announcing the same prefix over BGP. The technique is called anycast: your packet lands on whichever site is closest to you, and you never find out which one.

Thirteen means thirteen names and thirteen addresses, not thirteen servers. There are well over a thousand physical instances, and the count keeps growing. The current map is published at root-servers.org.

You can prove it from a terminal. Root servers answer a diagnostic query for the instance identifier (RFC 4892) — run it from different networks, or over mobile data, and compare:

# Identifier of the anycast instance that answered you
dig @j.root-servers.net id.server CHAOS TXT +short

# Older form of the same query, not supported by every operator
dig @j.root-servers.net hostname.bind CHAOS TXT +short

The same address 192.58.128.30 queried from London, Frankfurt and Sao Paulo returns different identifiers. Different machines.

Why thirteen, then

The limit is historical. Under RFC 1035 a DNS response over UDP could not exceed 512 bytes. On startup a resolver has to receive the full list of root servers at once — names plus their glue addresses. With name compression, thirteen entries were the most that fit in that packet.

The EDNS0 extension (RFC 6891) lifted the 512-byte ceiling long ago, but the thirteen-letter scheme stayed for compatibility: millions of configurations and embedded resolvers have it hard-coded. There is no reason to change it — scaling has moved to the number of anycast sites behind each letter.

Who runs them, and how often they are actually queried

IANA coordinates the root zone; the servers themselves are operated by twelve independent organisations — among them Verisign (which runs two of the thirteen letters), ICANN, RIPE NCC, Netnod, NASA, ISC, and several universities and research centres. None of them owns the root outright: the fragmentation is deliberate.

Aggregate load runs into tens of billions of queries per day; operators publish monthly statistics under the RSSAC-002 reporting standard. Yet for any given domain the root servers do almost no work: the delegation for .com is handed out with a TTL of 172800 seconds — two days — and for that entire window the resolver never needs the root. It only goes back on a cold start or after the cache expires.

# Ask a root server directly, no recursion.
# You get a referral to the .com servers, not an address
dig +norecurse @a.root-servers.net A example.com

# The root server list as your own resolver sees it
dig NS . +short

TLD servers: who runs .com, .org and .io

A TLD server handles one top-level domain and knows exactly one thing about it: which authoritative servers each second-level domain inside the zone was delegated to.

• gTLD — generic zones: .com, .net, .org, .info.
• ccTLD — country zones: .uk, .de, .jp. Registration rules are set by the zone administrator and vary widely — some require local presence or documents, some do not.
• new gTLD — the newer wave: .io, .app, .dev, .shop. Some carry technical constraints: .app and .dev are on the HSTS preload list as whole zones, so a site there simply cannot be served over plain HTTP.

A zone's registry and its DNS servers are different things. The registry holds the legal record of ownership — that is what WHOIS shows — while TLD servers serve the technical delegation. To inspect both:

# Which servers run the .com zone
dig NS com. +short

# Ask a .com server about a specific delegation.
# The answer arrives in the AUTHORITY section: NS records, not an address
dig +norecurse @a.gtld-servers.net NS example.com

# Same idea for any country zone: take a server from the NS list first
dig NS uk. +short
dig +norecurse @<server-from-that-list> NS example.co.uk

A TLD server does not hold your site's A record and cannot return it. If a domain "will not resolve" but dig +norecurse against the TLD shows correct NS records, the fault is further down — on the authoritative servers, not in the zone.

Authoritative DNS servers: the source of truth for a domain

The authoritative server is the only one that answers about a domain first-hand rather than repeating someone else's answer. When you set ns1.example-dns.com and ns2.example-dns.com at your registrar, those are the servers you are appointing.

An authoritative answer is distinguishable from a cached one by the aa flag in the header:

# Find the domain's authoritative servers
dig NS example.com +short

# Query one of them directly — the flags line will include aa
dig A example.com @ns1.example-dns.com | grep -E 'flags|ANSWER SECTION' -A2

# Query every authoritative server at once and compare SOA records.
# A serial mismatch means the zone has not reached all of them
dig +nssearch example.com

Primary, secondary and hidden primary

• Primary (master). Holds the master copy of the zone. Every edit happens here and only here.
• Secondary (slave). Replicates the zone from the primary via AXFR (full) or IXFR (incremental) transfer. The primary normally sends a NOTIFY message (RFC 1996), so the secondary pulls the new version within seconds instead of waiting for the refresh timer.
• Hidden primary. The primary is not listed in the NS records and is unreachable from outside; only secondaries answer queries. This shrinks the attack surface — every public server is read-only.

SOA: the zone's passport

Every zone has an SOA record, and it governs replication and negative caching:

dig SOA example.com +short
# ns1.example-dns.com. hostmaster.example.com. 2026081201 7200 3600 1209600 3600

Field	Example value	What it controls
MNAME	ns1.example-dns.com.	The zone's primary server; dynamic updates are sent here.
RNAME	hostmaster.example.com.	Administrator's mailbox. The first dot stands in for the at sign.
Serial	2026081201	Zone version. A secondary only transfers the zone if the serial increased.
Refresh	7200	How often a secondary re-checks the serial when no NOTIFY arrives.
Retry	3600	Wait before retrying after a failed check.
Expire	1209600	How long a secondary keeps answering after losing contact with the primary.
Minimum	3600	Negative answer TTL: how long NXDOMAIN is cached (RFC 2308).

That last field explains a common complaint: you add a subdomain and it stays invisible for another hour. The resolver cached not the record but its absence — for exactly minimum seconds.

Glue records

If a domain's name servers live inside the domain itself (ns1.example.com serving example.com), you get a loop: to learn the address of ns1.example.com you must ask example.com, which requires that address. Glue records break the loop — the name server addresses are published in the parent zone alongside the delegation. You set them at the registrar under a separate item, usually called "register name servers" or "child nameservers". Missing or stale glue is a classic reason a domain resolves nowhere despite correct NS records.

Keep your name servers with two independent operators on separate networks. Both servers at one provider is a single point of failure: an outage or DDoS there makes your domain invisible entirely, and no TTL saves you once the cache drains.

Recursive and caching DNS servers

The recursive resolver is the server whose address sits in your network settings. It stores none of your domain's records. Its job is to accept a query, walk root to TLD to authoritative, assemble the answer, cache it, and hand it back.

Where it comes from:

• ISP resolver. Handed out automatically over DHCP. Closest to you geographically, but the most likely to be overloaded or to filter.
• Public resolver. Cloudflare, Google, Quad9, AdGuard. Anycast and reliable — but they see every query you make.
• Corporate resolver. Resolves internal names that do not exist publicly; usually mandatory on VPN.
• Local. A service on the device itself, or dnsmasq on the router.

Cache and TTL: why changes are not instant

Every record arrives with a time to live. Until the TTL expires, the resolver answers from memory without troubling the authoritative server. You can watch the countdown with two queries:

# First query — TTL at its maximum
dig A example.com @1.1.1.1 +noall +answer
# example.com.  300  IN  A  93.184.215.14

# Same query 60 seconds later — TTL decremented, answer served from cache
dig A example.com @1.1.1.1 +noall +answer
# example.com.  240  IN  A  93.184.215.14

If the second answer shows the full TTL again, a different node of the anycast resolver served you and had no cached copy of its own. For anycast services that is normal, not a fault.

Planning a migration or an IP change? Lower the record's TTL to 300 seconds at least a day before you switch. TTL applies retroactively: resolvers that cached the record while it still said 86400 will hold it for a full day no matter what you change afterwards. Restore the old value a day after the move.

Negative answers are cached too. NXDOMAIN lives for as long as the SOA minimum field says — which is why a freshly created subdomain sometimes stays invisible longer than an edited one.

Forwarder and stub resolver: DNS inside your own network

A stub resolver is a library in the operating system. It does not walk the tree; it simply sends the query to the configured server and waits. On Linux its settings live in /etc/resolv.conf, on Windows in the adapter properties.

A forwarder does not recurse either — it passes queries to an upstream resolver and caches the answers. That is exactly what a home router does: devices see it as DNS server 192.168.1.1, while it quietly talks to the ISP. In companies a forwarder solves split-horizon DNS: internal names such as gitlab.corp.local it answers itself, everything else it forwards.

One Linux quirk: if systemd-resolved is running, /etc/resolv.conf will point at 127.0.0.53 — a local stub, not a real server. The real addresses have to be read elsewhere:

# The actual servers systemd-resolved is using
resolvectl status

# Addresses only, per interface
resolvectl dns

# Cache statistics: hits and misses
resolvectl statistics

Types of DNS servers: a comparison table

The roles differ on three axes: what data the server holds, whether it answers definitively, and whether it caches other people's data.

Server type	What it holds	Answers definitively	Caches	Operated by
Root	Delegation of top-level zones	No, referral to TLD only	No	12 organisations, coordinated by IANA
TLD	NS and glue for second-level domains in its zone	No, referral to the domain only	No	The zone's registry operator
Authoritative primary	The master zone: A, AAAA, MX, TXT, NS, CNAME	Yes, aa flag	No	Domain owner or their DNS host
Authoritative secondary	A copy of the zone pulled via AXFR or IXFR	Yes, aa flag	No	Same owner, often a different operator
Recursive resolver	Nothing of its own — only a cache of others' answers	No, never sets aa	Yes, per TTL	ISP, public operator, or company
Forwarder	A cache, sometimes a local zone	Only for its own local zone	Yes	Network administrator, router
Stub resolver	A small operating-system cache	No	Yes, briefly	The device's operating system

The practical takeaway: domains break at the authoritative and delegation layer, but they are usually "fixed" at the resolver and cache layer. Diagnose top-down — from the root toward the domain, not the other way round.

The full path of a DNS query

What happens between pressing Enter and the first byte of the page:

1. The browser checks its own DNS cache — Chrome and Firefox each keep one, separate from the system cache.
2. The operating system checks the hosts file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows). An entry there overrides every DNS server on earth — easy to forget when a test edit survives for months.
3. The stub resolver's own cache is consulted.
4. On a miss, the query goes to the recursive resolver configured for the network.
5. The resolver checks its cache. A hit ends the story right there — in practice that is how the vast majority of queries are answered.
6. On a miss it asks a root server: "where is the .com zone?" and gets a list of TLD servers.
7. It asks a TLD server: "who is example.com delegated to?" and gets NS records plus glue.
8. It asks the authoritative server: "give me the A record for www.example.com" and gets the address with the aa flag set.
9. It caches the answer for the TTL and returns it to the client.
10. The browser opens a TCP connection to that IP. DNS plays no further part.

Trace mode shows steps 6 to 8 in full — it bypasses your resolver and walks down from the root itself:

dig +trace www.example.com

Abbreviated output; your addresses and timings will differ:

.                    518400  IN  NS  a.root-servers.net.
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms

com.                 172800  IN  NS  a.gtld-servers.net.
;; Received 576 bytes from 192.5.6.30#53(a.gtld-servers.net) in 32 ms

example.com.         172800  IN  NS  a.iana-servers.net.
;; Received 576 bytes from 199.43.135.53#53(a.iana-servers.net) in 28 ms

www.example.com.     86400   IN  A   93.184.215.14
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net) in 28 ms

Read the "Received ... from" lines: they tell you which server answered at each hop. If the trace stops at the TLD, delegation is broken. If it reaches the authoritative servers but returns nothing, the fault is inside the zone.

Where a DNS server is located and how to find yours

Physically, your recursive resolver sits either in your ISP's network, or in a public operator's data centres, or right beside you in the router. Root and TLD servers live at hundreds of anycast sites and have no single location at all. The useful question is a different one: which address is my device using right now — and that takes one command.

Windows

:: Full adapter information; the field you want is "DNS Servers"
ipconfig /all

:: DNS addresses only, shorter and clearer
netsh interface ipv4 show dnsservers

:: What is currently in the cache
ipconfig /displaydns

:: Flush the DNS cache
ipconfig /flushdns

The same thing in PowerShell, where comments start with a hash:

# DNS server addresses across all interfaces
Get-DnsClientServerAddress -AddressFamily IPv4

# Contents of the client cache
Get-DnsClientCache

Faster still: run nslookup with no arguments — the first two lines, Default Server and Address, name the server in use.

macOS

# Every resolver the system knows about
scutil --dns | grep nameserver

# Addresses for one specific interface
networksetup -getdnsservers Wi-Fi

# List interfaces if yours is not called Wi-Fi
networksetup -listallnetworkservices

# Flush the cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux

# Modern systems running systemd-resolved
resolvectl status
resolvectl dns

# The classic file. Careful: with systemd-resolved this
# shows the 127.0.0.53 stub, not a real server
cat /etc/resolv.conf

# No systemd-resolved but NetworkManager present
nmcli dev show | grep DNS

# Flush the cache
resolvectl flush-caches

Router, phone, and a sanity check

If every device reports something like 192.168.0.1 or 192.168.1.1, that is your router acting as a forwarder — the real upstream resolver is configured in its web panel, under WAN or Internet. On Android the address is in the Wi-Fi network properties; on iOS it is under network settings, "Configure DNS".

One more trick: find out which resolver node actually served you. Google exposes its egress address through a special name:

# Which Google Public DNS node handled your query
dig @8.8.8.8 o-o.myaddr.l.google.com TXT +short

# Reverse lookup on a resolver address — the quickest way to tell whose it is
dig -x 8.8.8.8 +short
dig -x 1.1.1.1 +short

To see what your current resolver returns for a given domain and compare it against other operators, a browser check is easier: online DNS lookup.

How to change your DNS server

Switching resolvers takes a minute and is fully reversible. It is worth doing when your ISP's server is slow, serves stale records, or injects its own pages instead of errors. The step-by-step version for each platform is in a separate article: how to change your DNS server. The short version:

# Windows, PowerShell as administrator
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,9.9.9.9

# Revert to whatever the ISP hands out
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses

# macOS
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 9.9.9.9

# Revert
sudo networksetup -setdnsservers Wi-Fi empty

# Linux with NetworkManager. Get the connection name from nmcli con show
sudo nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
sudo nmcli con up "Wired connection 1"

The best place to change it is the router: the setting then applies to every device at once, including the TV and smart plugs that offer no DNS setting of their own.

These are the operators most people choose. Verify the addresses against current documentation — operators do add new ones:

Operator	Primary	Secondary	Notable trait
Cloudflare	1.1.1.1	1.0.0.1	Positioned around privacy and low latency. A 1.1.1.2 variant adds malware filtering.
Google Public DNS	8.8.8.8	8.8.4.4	The most widely used; handy as a reference point when diagnosing.
Quad9	9.9.9.9	149.112.112.112	Blocks domains on threat-intelligence lists, without commercial filtering.
AdGuard DNS	94.140.14.14	94.140.15.15	Strips ads and trackers at the DNS layer, apps included.
OpenDNS	208.67.222.222	208.67.220.220	Category filtering, configured in a web dashboard.

A comparison by speed, filtering and privacy is in the public DNS servers roundup.

Do not set both addresses from the same operator: 8.8.8.8 and 8.8.4.4 fail together. The point of a second address is surviving an outage at the first, so take it from a different company. And remember that your resolver sees the list of every domain you open — choosing an operator is choosing who gets that list. Under GDPR that list is personal data when it can be tied back to you, which is why resolver privacy policies and retention windows are worth reading.

DNS server not responding: how to fix it

Diagnosis rests on one move: compare the answers of two different resolvers. If the domain resolves through 1.1.1.1 but not through yours, the problem is your resolver or your network. If it resolves nowhere, the problem is the domain.

# The baseline pair every diagnosis starts with
dig A example.com            # through your current resolver
dig A example.com @1.1.1.1   # through a known-good public one

# Check the resolver is alive and reachable at all
dig @1.1.1.1 example.com +time=3 +tries=1

# If UDP stays silent, retry the same query over TCP
dig A example.com @1.1.1.1 +tcp

Symptom	Likely cause	Check	Fix
No site loads by name, but IP addresses work and ping succeeds	Resolver unreachable or overloaded	dig @1.1.1.1 example.com answers, dig example.com does not	Configure a different resolver; reboot the router
ERR_NAME_NOT_RESOLVED in the browser while the terminal works fine	Browser cache, or an extension running its own DNS	Open the site in a private window and a second browser	Clear the browser cache, disable extensions, check the browser's built-in DoH setting
SERVFAIL	DNSSEC validation failure, or the authoritative server erroring out	dig example.com +cd — if that returns an answer, DNSSEC is the cause	Owner: repair the signatures or remove the DS record at the registrar. User: temporarily use a non-validating resolver
REFUSED	The resolver does not serve your network; an ACL matched	Same query from another address or over mobile data	Use your ISP's resolver or a public one
NXDOMAIN for a domain that definitely exists	Negative cache, or the domain has lost its delegation	dig SOA example.com, whois example.com, check the expiry date	Wait out the SOA minimum; if registration lapsed, renew the domain
The domain resolves to an old IP address	TTL has not expired; the answer is cached	Compare answers across operators and read the TTL value	Wait for the TTL, flush the local cache, check propagation
Some users see the site, others do not	The zone did not reach every authoritative server	dig +nssearch example.com — compare the SOA serials	Re-publish the zone on the primary and wait for the transfer
Works via 8.8.8.8 but not via the ISP resolver	Filtering, an outage, or a stale cache at the ISP	Compare both answers and their TTLs	Switch resolvers; if the filtering is permanent, use encrypted DNS
Every query times out, public resolvers included	Port 53 blocked or filtered on the network	Repeat with +tcp; try from a different network	Configure DoH or DoT — they use ports 443 and 853
Windows: "server DNS address could not be found" right after changing settings	A stale entry in the system cache	ipconfig /displaydns — look for the domain in the output	ipconfig /flushdns; if it persists, restart the DNS Client service

Three cases that are most often misdiagnosed

A stale hosts entry. A line added a year ago for testing outlived both the migration and the hosting change. DNS has nothing to do with it — the hosts file is consulted before any resolver. Start there whenever "it works for everyone but me".

An expired domain. The registrar pulls the delegation and NXDOMAIN appears everywhere. No resolver change helps. One WHOIS lookup settles it — read the expiry date.

"The change did not apply." Usually it did — it simply has not spread yet, because the old TTL is still holding the record at some resolvers. To see the picture across operators and regions, use the DNS propagation check. A deeper walkthrough of non-resolving domains is in why a domain will not resolve and how to fix it.

DNS security: DNSSEC, DoH and DoT

DNS was designed without protection: answers travel in the clear and unsigned. Three technologies address different parts of that, and they get confused constantly.

• DNSSEC signs the data. The authoritative server signs records (RRSIG); the recursive resolver validates a chain of trust from the root key down through DS records in parent zones. It prevents forged answers. It encrypts nothing — the query is still visible.
• DoT, DNS over TLS (RFC 7858) encrypts the transport on dedicated port 853. Observers see that you are doing DNS, but not what you asked.
• DoH, DNS over HTTPS (RFC 8484) is the same encryption inside ordinary HTTPS on port 443, indistinguishable from web traffic. When enabled inside a browser it bypasses system settings entirely — a frequent reason for "I changed my DNS and nothing happened".

An important boundary: DoH and DoT hide queries from your ISP and from bystanders, but not from the resolver itself. The public DNS operator still sees everything. Privacy here is a question of which company you trust, not which protocol you run.

# Is the zone signed? Look for RRSIG records in the answer
dig example.com +dnssec

# Full chain-of-trust validation with the BIND utility
delv example.com

# Does the parent zone hold a DS record? Without it DNSSEC does nothing
dig DS example.com +short

Two more measures live on the domain owner's side. Response Rate Limiting stops an authoritative server being used as an amplifier in a DDoS attack, where a short query produces a long answer and the attacker forges the source address. Anycast plus name servers at two operators provide resilience under load. Resolvers, for their part, defend against forged answers by randomising the source port and the case of the queried name, and by sending only as much of the name as each level needs (QNAME minimisation, RFC 9156) — a root server has no business seeing the full hostname.

Before enabling DNSSEC, confirm that both your DNS host and your registrar support it: the signing happens at the host, while the DS record is published through the registrar. A mistake at either step produces SERVFAIL at every validating resolver — the domain does not degrade, it disappears.

How to check a DNS server online

A terminal is not always at hand, and comparing answers across networks from a single machine is impossible anyway. Browser-based checks cover that:

• DNS record lookup — A, AAAA, MX, TXT, NS, CNAME and SOA for any domain. The first place to look for any domain problem.
• DNS propagation check — the same domain queried against resolvers in different countries. Shows whether your change has spread and where the old cache still lingers.
• Domain WHOIS — owner, registrar, expiry date and current name servers. Answers "is this domain even still alive".
• MX lookup and email diagnostics — MX, SPF, DKIM and DMARC when mail stops arriving.
• Subdomain discovery — which names exist in the zone and where they point.
• Ping and traceroute — for when the name resolves but nothing connects: the problem has left DNS.
• Monitoring — continuous checks on your name servers and key records, with an alert when they change or stop answering. It closes the biggest risk of all: learning about a DNS failure from customers rather than from an alert.
• Operator outages — a quick answer to "is it just me".

Frequently asked questions

What is a DNS server in plain words?

It is the internet's directory service. You give it a domain name, it returns the IP address your browser needs. Without it you would have to open every site by number.

Where is a DNS server located?

The one you use is usually in your ISP's network or in a public operator's data centres such as Cloudflare or Google. On a home network the router often plays the role, forwarding queries upstream. Your domain's authoritative servers sit at whichever DNS host is named in your registrar account.

How do I find out which DNS server my computer uses?

Windows: ipconfig /all, the "DNS Servers" field. macOS: scutil --dns. Linux: resolvectl status. If you see 192.168.x.x, that is your router and the real upstream server is set in its panel. On Linux, 127.0.0.53 is the systemd-resolved stub, not a real server.

Why are there exactly 13 root servers?

Thirteen is the number of names and addresses, not machines. The limit came from RFC 1035: a UDP response could not exceed 512 bytes, and thirteen entries with their addresses were the most that fit. EDNS0 lifted the ceiling long ago, but the scheme was kept for compatibility. There are well over a thousand physical instances behind those addresses.

Does a recursive resolver store my domain's records?

No. It only caches answers it fetched from your authoritative servers, and holds them until the TTL expires. The master copy of the zone exists only on the authoritative servers.

Does changing DNS servers make websites faster?

Page load time — barely: once the browser has the address it talks to the site directly. Only the first lookup gets faster, typically by tens of milliseconds, and it is most visible on pages pulling from many third-party domains. The real reasons to switch are reliability, no answer tampering, and ad filtering.

What should I do if the DNS server is not responding?

Compare your resolver against a public one: dig A example.com versus dig A example.com @1.1.1.1. If the public one answers, configure a different resolver and flush your local cache. If nobody answers, the problem is the domain — check delegation, registration expiry and the authoritative servers.

Should name servers be at two different providers?

For anything whose downtime costs money, yes. Two servers at one operator fail together, and once caches drain the domain vanishes completely. Two independent operators on separate networks remove that single point of failure.

Checklist

• You know which resolver your device uses and can confirm it with one command.
• Your settings hold two addresses from different operators, not a pair from one.
• Your domain's name servers are hosted by two independent providers.
• Glue records at the registrar are current, if the name servers live inside the domain itself.
• TTL values are deliberate: 300 seconds ahead of a migration, normal values afterwards.
• The SOA serial matches across every authoritative server — verified with dig +nssearch.
• The hosts file holds no forgotten test entries.
• The domain's expiry date is known and renewal does not depend on a single mailbox.
• If DNSSEC is on, the DS record at the registrar matches the keys at the DNS host.
• Monitoring watches your name servers and key records, so a DNS failure reaches you as an alert, not as a customer complaint.