What Is My DNS

What is DNS, really?

DNS (Domain Name System) is the phone book the internet uses to translate human-readable hostnames like example.com into IP addresses software can connect to. It was defined in RFC 1034 and RFC 1035 in 1987 and the core protocol is essentially unchanged, though the ecosystem around it has grown enormously.

The lookup chain has three actors. An authoritative name server holds the actual zone data for a domain, set by whoever controls the domain. A recursive resolver (also called a full-service resolver) does the work of asking authoritative servers on your behalf, caches the answers, and hands results back to clients. A stub resolver is the tiny DNS client inside your operating system; it forwards queries to a recursive resolver and does nothing else. When you type a URL, your stub resolver asks your configured recursive resolver, which either has the answer cached or walks the DNS tree starting from the root servers until it finds the authoritative server for that domain.

The most common record types you will encounter:

• A maps a name to an IPv4 address. Most websites publish at least one.
• AAAA maps a name to an IPv6 address. Published alongside A records on dual-stack sites.
• CNAME is an alias pointing one name at another. It cannot coexist with other records at the zone apex (the bare domain like example.com), which is why CDNs use proprietary ALIAS or ANAME extensions for root domains.
• MX specifies the mail servers responsible for a domain, with priority values to control failover order.
• TXT holds arbitrary text, most commonly SPF records for email authentication, DKIM public keys, and domain ownership proofs for services like Google Search Console.

Every record has a TTL (Time To Live) in seconds. Recursive resolvers cache the answer for that duration before fetching a fresh copy. A TTL of 300 means resolvers refresh every 5 minutes; a TTL of 86400 means once per day. This is why "DNS propagation" takes time after a change: every resolver on the internet that cached the old record must wait for its TTL to expire before it sees the new one. Lowering your TTL to 300 before a planned migration and raising it back afterward is standard practice.

How this page detects your DNS resolver

This tool does not detect your configured resolver directly. Instead, it sends a DNS query from your browser to Cloudflare's DoH API at cloudflare-dns.com/dns-query using the application/dns-json format and displays whatever A and AAAA records Cloudflare returns for the hostname you type. The result tells you what Cloudflare's 1.1.1.1 resolver sees, which is usually the authoritative answer with no local filtering applied.

The four major public resolvers each have a distinct network footprint and policy. I use Cloudflare here because it is consistently among the fastest in independent latency benchmarks and publishes a clear privacy policy. The others:

• Google 8.8.8.8 / 8.8.4.4 is the largest public resolver by query volume. Google logs queries and anonymizes them after 24 to 48 hours. No malware filtering by default.
• Quad9 9.9.9.9 / 149.112.112.112 blocks domains associated with malware and phishing using threat intelligence from 20+ partners. It logs no personally identifiable information and is operated by a Swiss nonprofit.
• OpenDNS 208.67.222.222 / 208.67.220.220 (now Cisco) offers configurable filtering categories. It logs queries; family and enterprise plans add block-page redirects.

If the result from this tool differs from what dig or nslookup returns on your machine, the most common cause is that your OS resolver is caching an older answer or is returning a split-horizon result (a private IP for internal hostnames).

Finding your DNS from the command line

To see which resolver your operating system is actually configured to use, not what a web page can infer, you need a terminal. These commands work on all three major platforms without installing anything extra.

Windows (PowerShell)

# Show DNS servers per network adapter
Get-DnsClientServerAddress

# Query a specific resolver to test it
nslookup example.com 1.1.1.1

# Flush the local DNS cache
ipconfig /flushdns

Get-DnsClientServerAddress lists the DNS servers assigned to each network interface, including both the primary and secondary. If your VPN is active, you will often see the corporate DNS server on the VPN adapter and your ISP or router on the Wi-Fi adapter. Which one Windows uses first depends on the interface metric.

macOS (Terminal)

# Show all resolver configurations (including mDNS and VPN)
scutil --dns

# Query and show answer + timing
dig example.com +stats

# Query a specific resolver
dig @9.9.9.9 example.com

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

scutil --dns shows the full resolver list macOS is using, including per-domain overrides set by VPN profiles. It often reveals multiple resolver entries that plain dig output hides. The +stats flag on dig prints query time in milliseconds, which is useful for benchmarking resolvers.

Linux

# systemd-resolved systems (Ubuntu 18.04+, Fedora, Arch)
resolvectl status

# Fallback for non-systemd or minimal systems
cat /etc/resolv.conf

# Query with timing
dig example.com +stats

# Flush cache on systemd-resolved
sudo resolvectl flush-caches

On systems using systemd-resolved, /etc/resolv.conf often points to the local stub at 127.0.0.53 rather than the real upstream resolver. resolvectl status shows the actual upstream servers per interface. On older systems or containers, /etc/resolv.conf is the authoritative source.

When your browser ignores your OS resolver

Since around 2019, both Firefox and Chrome have started bypassing your operating system's configured DNS resolver and sending queries directly to a DoH server of their choosing. This is not a bug; it is an intentional privacy feature. But it causes real problems in certain environments.

Firefox has the most aggressive defaults. In the US, it enables DoH via Cloudflare by default unless it detects a corporate or parental-control signal. The setting lives atabout:config under network.trr.mode:

• 0 — off (use OS resolver)
• 2 — DoH with OS fallback (Firefox default in many regions)
• 3 — DoH only, no OS fallback
• 5 — DoH disabled entirely

I ran into this directly during an internal tooling setup. The security team had configured a split-horizon corporate DNS server via the VPN adapter so that internal hostnames like jenkins.internal resolved correctly. Everything worked in Chrome and Safari. Firefox, however, was using DoH via Cloudflare, so jenkins.internal returned NXDOMAIN in Firefox while resolving fine in every other app on the same machine. The fix was setting network.trr.mode = 5 in about:config for affected users, but most people would never have diagnosed it without knowing DoH was active.

Chrome enables DoH automatically if your configured DNS server supports it, a feature called "Automatic HTTPS for DNS." It upgrades to DoH using the same server IP. If your router points to 8.8.8.8, Chrome uses Google's DoH endpoint transparently. This is defined in RFC 8484.

iOS Private Relay (iCloud+) and Android Private DNS use DNS over TLS (DoT, RFC 7858) to encrypt queries at the OS level, below the browser. When either is active, every app on the device sends encrypted DNS to Apple's or your chosen resolver, regardless of what the router advertised.

Why the resolver you use actually matters

DNS resolver choice has real consequences across privacy, speed, filtering, and security.

• Privacy. A DNS query on port 53 is plaintext. Your ISP, anyone on the same network, and any on-path router can read every hostname you look up. Switching to a DoH or DoT resolver encrypts those queries. Your resolver still sees them, so you are trading ISP visibility for resolver-provider visibility.
• Speed.DNS latency adds to every new connection your browser makes. A resolver that is 50ms slower than average will noticeably affect page load times on sites with many hostnames. Cloudflare's anycast network puts 1.1.1.1 within single-digit milliseconds of most users; ISP resolvers are geographically close but often slower due to underpowered infrastructure.
• Censorship. Some ISPs block domains by returning incorrect DNS answers for flagged hostnames. Switching to a public resolver that does not apply those filters bypasses DNS-level blocks. Note that ISPs and governments have other blocking mechanisms (BGP blackholing, SNI filtering) that DNS changes do not affect.
• VPN DNS leaks.A VPN that routes traffic through a tunnel but leaves DNS queries going to your ISP's resolver is said to be leaking DNS. Your ISP still sees every hostname you look up even though your IP appears to be elsewhere. The VPN leak tool checks for this specifically.
• Filtering. Quad9 blocks malware and phishing domains. OpenDNS offers configurable category filtering. Both are legitimate uses: Quad9 for security without configuration, OpenDNS for household or school filtering.

Common DNS problems and how to diagnose them

Site loads on mobile but not on laptop

Almost always a stale cached record. Your laptop resolved the hostname before a DNS change and cached the old IP for the full TTL duration. Mobile data typically uses a different resolver with a separate cache, so it sees the new record immediately. Fix: flush the DNS cache (commands above) and reload.

DNS resolves in dig but not in the browser

Your browser is using DoH via a different resolver than your OS. If you are on a corporate network with split-horizon DNS (internal hostnames that only resolve on the corporate resolver), the browser's DoH resolver will return NXDOMAIN for those names while dig, which uses the OS resolver, succeeds. Disable DoH in the browser for the affected environment.

Pages load slowly despite a fast connection

High resolver latency can be the culprit. Run dig example.com +statsand look at the "Query time" line at the bottom. Anything over 100ms is significantly slower than a well-positioned public resolver. Switch your OS or router DNS to 1.1.1.1 or 8.8.8.8 and compare. On a fresh browser session where nothing is cached yet, resolver latency directly adds to time-to-first-byte on every new domain.

Internal hostnames fail only in Firefox

Firefox DoH is active and overriding the corporate or VPN resolver. Open about:config, search for network.trr.mode, and set it to 5 to disable DoH. Alternatively, your IT team can deploy the canary domain signal (returning a specific record for use-application-dns.net) to tell Firefox to disable DoH automatically on managed networks.

Public DNS resolvers compared

Choosing a resolver is a trade-off between privacy policy, filtering behavior, speed, and operator trust.

Latency figures are approximate global averages from DNSPerf. Your actual latency depends heavily on your region and ISP peering.

Frequently asked questions

What is my DNS server?

There are usually three layers to this answer. Your router has a DNS server configured (often your ISP's resolver). It advertises that server to your devices via DHCP. Your OS stores it as the configured resolver and your stub resolver forwards queries to it. Your browser may then override all of this with DoH to a public resolver. To see what your OS is actually using, run Get-DnsClientServerAddress on Windows, scutil --dns on macOS, or resolvectl status on Linux.

Why is my DNS different from what my router shows?

Your router broadcasts a DNS server via DHCP, but your device can override it. A VPN client commonly pushes a different DNS server when the tunnel connects. A browser with DoH enabled ignores the OS resolver entirely for its own queries. Corporate MDM profiles on managed devices often set a specific resolver that overrides the router setting. Any of these layers can produce a different resolver than what your router advertised.

Is changing my DNS to 1.1.1.1 safer?

For privacy from your ISP, yes. Cloudflare's resolver does not sell query logs and purges them within 25 hours. Your ISP's resolver is plaintext on port 53 and visible to anyone on your network. Switching to 1.1.1.1 over DoH means your ISP cannot read your DNS queries. For malware protection, 1.1.1.1 does not filter by default; use 1.1.1.2 instead. Switching DNS does not hide your IP address or encrypt your connections beyond the DNS query itself.

Can my ISP see which websites I visit if I use 1.1.1.1?

Not via DNS, if you use DoH or DoT. But DNS is only one signal. Your ISP can still see the destination IP addresses of your connections and the Server Name Indication (SNI) field in the TLS handshake, which reveals the hostname you are connecting to on HTTPS sites. Encrypted Client Hello (ECH) encrypts the SNI but is not universally deployed. Using 1.1.1.1 with DoH closes the DNS window; it does not close the IP or SNI window.

How do I know if my DNS is leaking?

A DNS leak means your device is sending DNS queries outside the VPN tunnel to your ISP's resolver, even though the VPN is connected. Your VPN exit IP is visible on the IP tool, but your DNS queries are still visible to your ISP. The VPN leak tool checks this by comparing your public IP, your WebRTC IP, and the resolver answering your DNS queries. If all three point to the VPN provider, you are clean.

Related tools

DNS translates names to IPs, but the IP itself tells you which network you are on. See What Is My IP for the address your connections originate from. The organization behind that IP is in What Is My ISP. If you suspect your VPN is routing DNS outside the tunnel, the VPN leak tool tests your public IP, WebRTC IP, and DNS resolver in one view. For connection speed and latency, see Internet Speed Test.

Sources cited above

• RFC 1034: Domain names — concepts and facilities (1987)
• RFC 1035: Domain names — implementation and specification (1987)
• RFC 7858: DNS over TLS (DoT, 2016)
• RFC 8484: DNS over HTTPS (DoH, 2018)
• DNSPerf: public resolver latency benchmarks
• Cloudflare 1.1.1.1 privacy policy

Common questions