DNS helps your device find services by name. Choosing a reliable resolver and understanding where its settings apply can improve name-resolution behaviour, privacy and filtering. It is also a useful troubleshooting step, provided you separate DNS delays from problems with Wi-Fi, the internet connection or the destination itself.
How DNS resolution works
A domain such as www.example.com is easier to remember than an address. DNS returns records, including A records for IPv4 and AAAA records for IPv6. It supports other record types too; it does not simply translate every URL into one permanently fixed IP.
Your application or operating system may already have a cached answer. Otherwise, it contacts a configured resolver. A recursive resolver can use cached information or follow referrals through the DNS hierarchy: root, top-level domain and authoritative servers. Cached delegations and records mean every lookup does not need to repeat the whole sequence.
Records have a time to live, or TTL, which affects caching. A changed record may therefore appear at different times to clients using different caches. Clearing one computer’s cache does not force every upstream resolver to discard an unexpired answer.
What changing a resolver can improve
A responsive resolver may reduce the wait for a new name lookup, and reliable resolution can avoid some connection failures. It does not increase your ISP bandwidth or guarantee faster downloads, lower game-server latency or better wireless coverage. Once the needed address is known, the data transfer depends on the rest of the path.
Your ISP’s resolver is not automatically slow or unsuitable. Compare the existing service with alternatives at your location, considering availability, filtering, privacy and compatibility with local services. A quoted worldwide average does not establish which resolver is fastest on your connection.
Repeated tests can also hit caches, so compare like with like and use several relevant domains. A browser loading a page faster may reflect cached content, a different server or another change. Record the settings and test conditions before attributing the result to DNS.
Public resolver reference
These published addresses illustrate commonly used services. Each row’s addresses belong to the same service policy. Verify current provider instructions before configuring a device, especially when selecting an encrypted endpoint or a filtering variant.
| Service | IPv4 pair | IPv6 pair | DoT hostname | DoH endpoint |
|---|---|---|---|---|
| Cloudflare standard, no content filtering | 1.1.1.1 1.0.0.1 | 2606:4700:4700::1111 2606:4700:4700::1001 | one.one.one.one | https://cloudflare-dns.com/dns-query |
| Quad9 secure, threat blocking | 9.9.9.9 149.112.112.112 | 2620:fe::fe 2620:fe::9 | dns.quad9.net | https://dns.quad9.net/dns-query |
| Google Public DNS | 8.8.8.8 8.8.4.4 | 2001:4860:4860::8888 2001:4860:4860::8844 | dns.google | https://dns.google/dns-query |
| AdGuard default, ad/tracker filtering | 94.140.14.14 94.140.15.15 | 2a10:50c0::ad1:ff 2a10:50c0::ad2:ff | dns.adguard-dns.com | https://dns.adguard-dns.com/dns-query |
Cloudflare’s separate malware-filtering pair is 1.1.1.2 and 1.0.0.2; its malware-plus-adult-content pair is 1.1.1.3 and 1.0.0.3. They are different policies, not the primary and secondary addresses of one service. Use the corresponding complete IPv6 and encrypted configuration from its guide rather than mixing variants.
Other choices include OpenDNS and configurable services such as NextDNS. Yandex.DNS offers Basic, Safe and Family modes, while CleanBrowsing offers different filtering policies. Compare the actual mode, terms, logging choices and support requirements. Domain filtering can also block a legitimate service incorrectly, so keep a way to identify and resolve false positives.
Plain DNS, DoT, DoH and DNSSEC
Ordinary DNS commonly uses UDP or TCP port 53 without transport encryption. DNS over TLS, or DoT, establishes a TLS connection, normally on TCP port 853. It is not restricted to TLS 1.3: supported protocol versions depend on the implementation and current provider configuration.
DNS over HTTPS, or DoH, carries DNS queries through HTTPS, commonly on port 443. It can protect the client-to-resolver query from inspection along that path when properly configured. It is not universally indistinguishable from all web traffic or impossible for a network policy to restrict.
Neither transport makes you anonymous to the chosen resolver or hides every detail of internet activity. The service still handles the query, and other connection metadata may remain visible. Review its policy. Cloudflare, for example, describes limited transaction/debug logs retained for up to 25 hours and separate aggregated data, rather than a blanket absence of all logging.
DNSSEC addresses a different problem: authentication and integrity of DNS data through supported validation. It does not encrypt the query. A validating resolver and encrypted transport can therefore serve different, complementary roles. Neither is a complete substitute for checking the HTTPS identity of the service you ultimately visit.
Where settings apply
A router can forward DNS requests or advertise resolver information to clients. A device may also have manual settings, a VPN may supply its own resolver, and a browser may use an independent encrypted-DNS setting. IPv6 can advertise DNS separately. Changing only the router’s IPv4 upstream setting may therefore leave some devices or applications using another path.
Record the current configuration before changing it, and start with one device. Check both public websites and services named only inside your home or organisation. Public resolvers normally cannot answer private names held only by your local DNS server. An appropriate local resolver or conditional arrangement may be needed for those names.
Additional resolver addresses provide resilience, but selection and retry behaviour depend on the client. They are not a universal strict primary-then-secondary policy. Mixing a filtering resolver with an unfiltered alternative may undermine the intended policy; mixing a local resolver with a public one can also produce inconsistent private-name behaviour.
A small diagnostic check
Where nslookup is available, these commands compare a default lookup with a specified resolver and request an IPv6 record:
nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=AAAA example.com
They do not change your network settings. Note which resolver answers, whether the request times out and whether the result is a valid record, a negative answer or another error. A direct public-resolver query can be restricted on a managed network; a failure there does not necessarily mean the provider is down.
Microsoft notes that nslookup behaviour differs from its normal DNS client resolution process. It also does not prove which DoH path a browser uses. Check the relevant device/browser settings and provider verification tools when diagnosing encrypted resolution.
Flush a local cache when a specific stale-entry problem justifies it, using the operating system’s documented method. Routine flushing discards useful cached answers and is not a general performance optimisation. After a change, reconnect or renew configuration where needed, then repeat the original functional test.
Filtering and homelab policy
Pi-hole or AdGuard Home can provide local filtering, but DNS cannot selectively remove every advert served from the same domain as wanted content. A remaining advert is not proof that a particular television brand always hardcodes Google DNS. Establish the actual client and query path before adding firewall rules.
A carefully scoped port-53 redirect can affect ordinary DNS traffic on a supported firewall. It does not intercept DoH or DoT automatically, and rules must account for the local resolver’s own upstream queries, intended exceptions and IPv6. An indiscriminate redirect can create loops or disrupt legitimate services.
Use the firewall’s matching documentation, test on a controlled client and retain a rollback route. Decide explicitly whether unavailable filtering should fail closed or allow a fallback, because those choices trade policy enforcement against access. They should not be hidden behind an assumed universal “secondary DNS” setting.
Choosing a sensible configuration
The best DNS configuration is the one that resolves your required names reliably, follows the policy you intend and remains understandable when something fails. Test lookup behaviour, private names, encrypted transport and filtering separately. Keep the baseline settings so you can restore them if a trial causes problems.
A dependable resolver can improve an important part of the internet experience. Treat it as a targeted configuration choice supported by local evidence, rather than a promise of more bandwidth or complete privacy. Change one variable at a time and verify the result on the devices that matter.
