What Is a DNS Server? The Setting That Can Break Your Browsing
Understand recursive and authoritative DNS servers, inspect your device settings, and diagnose resolver failures before changing network configuration.
- domains
- guide
A DNS server answers questions about domain names and their records. The DNS server address in a device's network settings usually selects a resolver that obtains answers for applications. A domain's authoritative nameservers perform a different role: they serve the zone's authoritative data. Current DNS terminology distinguishes these roles.
The distinction matters during a failure. Changing a laptop's resolver does not edit a website's published address. Changing a domain's nameservers does not choose the resolver that every visitor uses. Identify the setting involved before changing either side.
A recursive resolver obtains answers for the client
A stub resolver depends on another resolver to undertake full resolution. A recursive resolver can answer from local information or query other servers to obtain the answer. RFC 9499 defines both roles and explains their relationship. The terminology describes the client-facing path.
The server address shown on a device may therefore belong to an organization, internet provider, router, or selected resolver service. A router can also forward DNS queries to another resolver. RFC 9499 describes forwarders as a separate part of the path. The forwarder definition explains that arrangement.
Do not assume the first displayed address identifies every server used behind the scenes. Record the setting as the device's configured destination. If a network administrator manages the path, ask which upstream service and internal zones the configuration requires.
The broader DNS explanation follows the lookup through the hierarchy. This guide concentrates on the server selection and the symptoms a visitor can observe.
Authoritative servers publish a different side of DNS
An authoritative server knows a zone's contents from local knowledge and can answer questions about that zone. Authoritative servers also provide referrals for delegated child zones. RFC 9499 defines that authority.
A domain owner edits records at the authoritative DNS provider. A visitor selects a resolver through device, router, browser, or managed-network configuration. Those actions can involve different accounts and different companies.
For example, an operator can publish a new website address while a visitor's resolver still has an older cached record. A resolver cache lifetime can explain that difference. The DNS standard defines TTL as the time a record can remain cached. RFC 1034 describes the cache boundary.
If the published record is wrong, changing a visitor's resolver is not the authoritative correction. If the selected resolver is unavailable, editing the website's address is not the client-side correction. Preserve the distinction in the incident report.
The current settings provide evidence before a change
On Windows, ipconfig /all displays detailed adapter configuration. Microsoft's command reference defines the option. The ipconfig documentation explains the configuration display.
ipconfig /all
On a Mac, Apple documents DNS settings under System Settings > Network > network service > Details > DNS. The page lists DNS servers and search domains. Apple documents the settings screen.
Check the active connection rather than an unrelated adapter. Save the current DNS configuration before making an approved change. Google explicitly recommends preserving existing settings before switching to Google Public DNS. Google documents that preparation.
For an organization device, keep the required VPN and resolver configuration. Split DNS can return different answers depending on the query source. RFC 9499 describes that arrangement. The split-DNS definition explains the boundary.
A public resolver may therefore produce a different result from an internal resolver without either result alone proving a configuration mistake. An internal name needs investigation within the intended network context.
A direct query helps separate lookup errors
With nslookup available, query the failing hostname first:
nslookup www.example.com.
The hostname uses a reserved documentation domain. Replace the hostname before testing. Microsoft documents the default server behavior and the optional server argument. The nslookup reference defines the query.
If the network permits an explicit public-resolver comparison, the following example selects Google Public DNS:
nslookup www.example.com. 8.8.8.8
Google documents 8.8.8.8 as a Public DNS address. The official configuration guide lists the address. The example does not change the device's saved resolver configuration.
Do not send private organization hostnames to a public resolver during an unrelated test. Use a resolver that the network administrator permits. Keep the hostname, requested record type, UTC time, and exact output when comparing results.
| Observation | What to investigate next |
|---|---|
| The selected server does not respond | Resolver reachability and the intended network path |
| The result reports a nonexistent domain | Exact spelling, the published name, and the selected resolver context |
| The result reports no records of the requested type | The queried record type and authoritative data |
| The result reports a server failure | Resolver diagnostics and authoritative-server behavior |
| The lookup succeeds but the browser still fails | Browser resolution settings, HTTPS, and the application response |
Microsoft documents these distinct nslookup error categories. The error descriptions support different next checks. Do not reduce every error to “change the DNS server.”
Use Namefi's DNS command generator to prepare a lookup for your operating system. Choose the system resolver or one of the listed public resolvers, then run the command on the affected device. Generating the command does not test the connection or change its settings.
A browser can select another DNS provider
Chrome supports a custom Secure DNS provider. The desktop setting lives under Settings > Privacy and security > Security. Google documents the provider selection.
A successful operating-system query therefore does not establish that Chrome used the same resolver. Inspect the actual browser setting when only Chrome fails. Keep the approved configuration for a managed device.
Changing the resolver is a service-selection decision. Review the provider's published policies, required internal-name support, and the network's rules. Do not promise that a resolver change will repair every connection or make every application faster.
If a stale local answer is the remaining hypothesis, use the platform-specific Windows flush guide or Mac flush guide. If the authoritative record is wrong, contact the domain operator. A useful correction targets the server role that actually failed.
Sources and further reading
The DNS terminology distinguishes server roles
IETF RFC 9499, section 6. Fetched 2026-10-30.
The DNS terminology explains forwarding
IETF RFC 9499, Forwarder definition. Fetched 2026-10-30.
The DNS terminology defines authoritative service
IETF RFC 9499, Authoritative server definition. Fetched 2026-10-30.
The DNS standard defines cache lifetimes
IETF RFC 1034, TTL definition. Fetched 2026-10-30.
Microsoft documents network configuration display
Microsoft, ipconfig /all. Fetched 2026-10-30.
Apple documents DNS server settings
Apple Mac User Guide, Change DNS settings. Fetched 2026-10-30.
Google documents Public DNS addresses and rollback preparation
Google Public DNS, Get started. Fetched 2026-10-30.
The DNS terminology describes split DNS
IETF RFC 9499, Split DNS definition. Fetched 2026-10-30.
The IETF reserves example domains
IETF RFC 2606, section 3. Fetched 2026-10-30.
Microsoft documents server selection and errors
Microsoft, nslookup remarks and errors. Fetched 2026-10-30.
Google documents desktop browser DNS selection
Google Chrome Help, desktop Secure DNS. Fetched 2026-10-30.
About the author(s)
Fenwei Bian is a software developer in her thirties who spends her working hours in pull requests and her weekends with her hands in soil or sawdust. Years of open source on GitHub taught her that names are interfaces: a good one is clear, honest about what it does, and kind to whoever has to use it next.
She gardens because it rewards patience and punishes wishful thinking, and she does woodwork because a joint either fits or it doesn't. Both habits show up in how she writes about naming — measure twice, check the source, and don't sand over a rough spot and hope no one notices.
For Namefi she writes about how domain markets actually move, the practical trade-offs of tokenizing and flipping names, and picking a domain you'll still be glad you own in twenty years.