Choose the DNS
that fits your work.

01 / Compare the choices

What do you want it to do?

The services below offer public options without a direct charge; some restrict the intended use or have separate organizational plans. The addresses are IPv4 examples. Use each provider’s documented primary and secondary addresses for the same service and policy. Availability, terms, logging, and supported features can change.

On a small screen, scroll across the table to see all columns.

Some providers also publish IPv6 resolver addresses. Configure and test IPv4 and IPv6 together if your network uses both. A filtered IPv4 resolver alongside an unfiltered IPv6 resolver can produce inconsistent policy enforcement.

02 / Performance

Measure from where people work.

DNS lookup time depends on the path to the resolver and whether its answer is already cached. A cached answer and an uncached answer can take very different amounts of time. A resolver can also return a different content-delivery endpoint depending on its location and DNS features, affecting the subsequent connection.

Explore our public DNS measurements for a view from Stealth’s New York City network. Compare ping round-trip time and a separate DNS lookup over UDP port 53.

1. 01

   Pick a representative starting point

   Use the office, school, or remote connection you want to assess. Record the device, network, date, address family, resolver, and whether the test uses ordinary DNS or an encrypted client.

2. 02

   Use the same small set of public names

   Test common public services relevant to your work, using the same record types for each resolver. Do not send internal hostnames to public resolvers. Space queries out and respect provider rate limits.

3. 03

   Repeat and compare

   Collect samples across busy and quiet periods, ideally over a day. Record failures and timeouts as well as timing. Compare the median and, with enough samples, a high percentile such as the 95th; a single fastest result does not describe consistency.

4. 04

   Test the application too

   Check actual web or application performance and reliability. DNS timing alone does not measure the path to the service, application latency, or available bandwidth.

For a quick manual comparison on a system with dig, run the same public lookup against each candidate. These commands normally send unencrypted DNS over UDP port 53; they do not test DNS-over-HTTPS or DNS-over-TLS.

dig @1.1.1.1 example.com A +time=2 +tries=1

dig @8.8.8.8 example.com A +time=2 +tries=1

Look at the response status, answers, and Query time. These are examples, not a benchmark: changing the order or repeating a name can change cache conditions. A fast response with the wrong policy, a timeout, or a different answer still needs investigation. On Windows, nslookup example.com 1.1.1.1 is useful to check an answer, but it does not provide the same timing report.

03 / Security & filtering

Know what a filter can—and cannot—do.

A security resolver can refuse or redirect lookups for domains on its threat lists. Coverage, update timing, false positives, and the way blocked requests are reported differ among services. It will not catch every malicious destination, stop all phishing, or replace device protection, firewalls, and user training. DNSSEC validation helps detect forged DNS data where signed records are available; it does not certify that a website or its content is safe.

Family filters and ad blockers operate on the names they can identify. They may block useful resources, miss unwanted material, or be bypassed by another resolver, a browser’s encrypted DNS, a VPN, or another network path. A school or business should decide which controls are appropriate, communicate the policy, and test needed applications. SafeSearch behavior also depends on the search or video service and its configuration.

Changing resolvers also does not guarantee access to a blocked service. Restrictions or failures can occur elsewhere in the network or at the destination, and local rules and organizational policies still apply.

04 / Privacy & protocols

Understand who can see a lookup.

Traditional DNS requests are commonly sent without encryption. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the connection from a compatible client to the resolver. This can protect DNS queries from observers on that path; the resolver still receives the requests, and the sites or applications you connect to can still learn about those connections. Encryption does not make browsing anonymous.

Read the provider’s policy for IP addresses, query logs, retention, analytics, security exceptions, and legal obligations. Some resolvers use EDNS Client Subnet to send a portion of a client’s network address to authoritative DNS systems to help select a nearby service endpoint. Providers handle that feature differently; check its current documentation and your privacy requirements.

For example, Google says its temporary logs contain IP addresses and query details and are normally deleted within 24–48 hours, with longer retention possible for security and abuse investigations; sampled data without the original IP can be retained for analysis. Cloudflare says its resolver logs are deleted within 25 hours, with specified sampling exceptions for troubleshooting and research. Quad9 says it generally does not write client IPs to disk or transmit them outside the receiving location, with limited exceptions for abuse mitigation. These summaries are starting points, not substitutes for the providers’ current policies.

Oblivious DNS is a separate protocol design involving a compatible client, proxy, and target resolver. Its privacy properties depend on the parties and configuration; simply setting a resolver’s IP address does not enable it.

05 / Business & school networks

Keep internal names working.

Many organizations rely on internal DNS for private applications, directory services, printers, and VPN resources. Replacing a managed resolver on a device or firewall with a public resolver can break private names or send sensitive internal queries to a third party. Your IT team may instead use approved internal resolvers with carefully configured forwarding or split DNS.

Check device management, DHCP, IPv4 and IPv6 settings, firewall rules, VPN software, and browser-level encrypted DNS. A browser or VPN may use a different resolver from the one displayed in the operating system. Decide which layer controls policy and test from a representative managed device.

Public services vary in their terms, availability, support, logging, reporting, and suitability for commercial or educational networks. A free consumer service is not automatically an appropriate organizational service. For critical operations, consider service commitments, redundancy, change control, and how to investigate a filtering mistake.

06 / Configure & verify

Change carefully, then test.

1. 01

   Record the current settings

   Before making a change, document the existing IPv4 and IPv6 resolvers, encrypted DNS settings, management policy, and how to restore them. Coordinate with the network or security team.

2. 02

   Choose a matching pair

   Enter the provider’s primary and secondary addresses for the same policy. For DoH or DoT, use its documented endpoint and a client that supports the protocol; an IP address alone does not turn on encryption.

3. 03

   Verify from a representative device

   Test public names, approved internal names, VPN access, and important applications. Check the actual resolver used by the operating system and browser; a direct query to a public address only proves that the address answered that test.

4. 04

   Confirm the policy

   Use the provider’s published test procedures for encryption or filtering where available. Review results with IT, test both address families where used, and keep a documented rollback path.

Encrypted DNS support is client- and configuration-specific. Follow the provider’s current setup guide for the operating system, browser, router, or managed network. See the business DNS guide for additional nslookup examples.

07 / Decision checklist

Questions to ask before choosing.

• Is the priority lookup speed, malicious-domain blocking, privacy, content controls, or a combination?
• What do measurements from our actual networks show for median, slower responses, and failures?
• Are the IPv4 and IPv6 addresses from the same service and filtering policy?
• Will internal DNS, VPN access, applications, and managed devices continue to work?
• What data does the resolver retain or share, and how long?
• Does the plan permit our use, and what support or service commitment is provided?
• How can we investigate a block, request a correction, and roll back a change?