The DNS server you choose might not be the one your devices actually use

Published Nov 14, 2026, 8:00 AM EST His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. Changing your DNS server is one of the simplest tweaks you can make to a home network, and for many people, it's the first thing they do after initial setup. Some will point their router at Cloudflare or Google because they want a faster resolver than what their ISP offers, and others set up Pi-hole or AdGuard Home to block ads for their whole house. No matter what you set it to, it's assumed that once you set it at the router level, it takes hold for every device, but that's not always true. Without any indication, some devices can skip past the DNS you set, and sometimes there's no getting around that. How your devices are supposed to find their DNS server DNS 101 When a device connects to your home network, DHCP is responsible for handing it an IP address and a DNS server, and that's usually the router itself, which then forwards lookups to whatever upstream DNS is configured. By default, this is usually your ISP's DNS server, but if you have something configured in your router's admin panel, it'll use that instead. Apps will ask the operating system, and the operating system asks that resolver, and the answer will come back down the chain. However, there are scenarios that break this chain, and it can happen at different parts of the link. Your browser might be performing its own lookups DNS over HTTPS causes this Modern web browsers are able to resolve domain names themselves using a technology called DNS over HTTPS, or DoH. This method of resolving skips the operating system's resolver entirely. Firefox is the best example of this in action, because it was one of the most popular browsers that happened to enable DoH before the others. It did so for US users in 2020, and those lookups travel over port 443 inside normal HTTPS traffic. Not only does that skip the OS, but it skips past your router and any potential sinkhole, including Pi-hole, rendering blocklists useless. Chrome, Edge, and other Chromium browsers work a bit differently to Firefox. Chrome’s automatic mode only upgrades to DoH when the resolver your system already uses is on a list of known providers, and it'll stay with that same provider. This only kicks in if your device is handed 1.1.1.1 directly: Chrome will then switch to Cloudflare’s encrypted endpoint, the same provider over a different protocol. If your router hands out its own address and forwards lookups upstream, Chrome sees the router and leaves DNS alone. Firefox will also tweak its behavior if DoH is left at defaults. It'll check a canary domain and disable DoH if the network signals that it should, and in the event of parental controls, enterprise policies or VPNs being enabled, it'll leave your DNS resolving alone. These checks only happen if you don't turn on DoH yourself, so keep that in mind. Some devices never ask for a DNS in the first place More common than you might think A lot of streaming devices like streaming sticks and smart TVs ship with DNS servers baked into their firmware. IoT gadgets also fall into this category, with many of them being unchangeable by regular means. Google's Chromecast is one of the best examples: Pi-hole and pfSense users have reported it sending queries straight to 8.8.8.8 regardless of what DHCP provides, and some owners found their devices stopped working entirely when that address was blocked. This isn't the default behavior across all devices like this though, and sometimes it's simply a fallback measure that's hardcoded. Some devices will ignore the DHCP-provided resolver no matter what you do, but others will use it until something goes wrong with a request, and then it'll fall back to the hardcoded one. This is why a lot of ad-blocking DNS sinkholes simply don't work on these devices—a failed lookup for an ad server is seen as a failure, so it'll just fall back to a DNS server that lets it serve those ads. The upside is that a lot of this traffic happens over plain DNS on port 53, so it's not totally invisible to you at least. IPv6 is its own beast It can hand out its own resolver If you run a dual-stack network and you haven't accounted for both resolvers, that can cause the same sort of problems. IPv4 devices get their settings from standard DHCP, but if IPv6 is in play, DHCPv6 or router adverts can allow for traffic to hit resolvers that you haven't set yourself. Plenty of routers advertise their own IPv6 address or the ISP’s IPv6 resolvers by default, and the DNS field in the admin panel often only changes the IPv4 side. Your ISP can also answer on someone else's behalf A little more annoying to try and fix Even if you set your resolver properly and ensure that your device is sending the request to your desired address, it can still get intercepted along the way by your ISP. Some ISPs run transparent DNS proxies that catch port 53 traffic and answer from their own resolver, while the reply appears to come from the server you asked, at least on the surface. Researchers out of UC San Diego have proven that this behavior happens, and they found that a significant share of the interception is happening among ISP-supplied gateways. It's not extremely common yet, but it does have implications for security and privacy. You can check if this is happening to you by performing a DNS leak test, and dnsleaktest.com is the best website I've found explaining what it is and how to fix it. ISPs do this for a variety of reasons, but one of the biggest motivations for them is monetary. A lookup for a name that doesn’t exist, usually a typo, gets answered with a search or ad page instead of an error. ISPs often partner with third-party monetization companies that supply the redirect pages and ad servers. If you were to divert DNS traffic to 1.1.1.1 or a DNS sinkhole, the ISP would lose that revenue unless they intercept that port 53 traffic. Just because you set the provider doesn't mean it takes hold for all of your devices The DNS field you set on your router isn't a guarantee, and it's worth checking where your traffic is actually going. Your browser, device, IPv6, and your ISP all get a say regardless of what you set, and while it's not always nefarious, don't assume every device is covered by the one setting at the source.