DNS — An Underrated Part of Your Digital Identity

Most users perceive DNS as a technical detail that runs somewhere in the background. The internet opens, websites load—that means everything is configured correctly. That's why many people set up Google Public DNS (8.8.8.8) or Cloudflare (1.1.1.1) once, or even leave the settings automatically received from their provider and never bother with it again. This approach is perfectly adequate for normal internet use. But when it comes to proxies, anti-detection browsers, automation, web scraping, or information security research, DNS ceases to be a secondary setting. It becomes part of your online identity.

It's worth remembering that DNS is one of the internet's oldest mechanisms. Its foundations were laid back in the early 1980s (the key RFCs 1034 and 1035 date back to 1987), when privacy and anti-fraud were unheard of. A classic DNS request is sent in cleartext over UDP to port 53—visible to both the ISP and any intermediate node along the way. This "legacy" gave rise to both modern problems and attempts to solve them, such as encrypted DNS. Understanding the context helps us see why choosing a resolver is more than just a cosmetic matter.

DNS is more than a phone book

DNS is often described as the internet's phone book: a domain name is converted to an IP address, after which the browser connects to the correct server. This explanation is correct, but overly simplified. Today, DNS is used in load balancing, selecting the closest CDN node, routing, ensuring fault tolerance, and building a statistical user profile. Geo-DNS and latency-based routing are good examples. The same domain can return different IP addresses depending on who is requesting and where from. A large website hosted on a CDN will return one edge server when requested through a German resolver, and another through an American one. Services like AWS Route 53 or Cloudflare Load Balancing do this out of the box: they set a very short TTL (sometimes 30–60 seconds) on records to quickly switch traffic and maintain fault tolerance. The same mechanism that makes a domain "resilient" turns DNS into a real-time signal about where the network believes the client is located.

EDNS Client Subnet (ECS, RFC 7871) is worth mentioning separately. This is an extension where the resolver passes a truncated portion of the client's subnet to the authoritative server so the CDN can find a closer node. It sounds purely technical, but the meaning is straightforward: your resolver can communicate the approximate geography of the connection to external servers even before the main connection is established. Different resolvers behave differently here—we'll return to this below.

That's why modern anti-fraud systems analyze not only IP addresses but also how name resolution was performed. The core idea of ​​modern protection is simple: the system almost never makes a decision based on a single indicator. It evaluates a combination of signals and generates a risk score. An unusual DNS record alone proves nothing. But when time zone mismatches are added (for example, the system reports Europe/Berlin, but the browser language is en-US), IP geography, device fingerprinting (Canvas, WebGL, font set), and network characteristics are added, the profile begins to look less natural. Each indicator alone is weak; their combination carries weight.

Why Public DNS Isn't Always the Best Choice

Google Public DNS and Cloudflare are excellent services. They're fast, stable, and support modern protocols: DNSSEC, DNS over HTTPS, and DNS over TLS. Cloudflare, for example, operates as an anycast network in hundreds of cities, and independent tests consistently rank its resolver among the fastest in the world. The problem isn't their quality, but the context of use.

A telling nuance is precisely the behavior with ECS. Google Public DNS sends a truncated client subnet to authoritative servers (by zeroing out the least significant bits of the address) to more accurately select a CDN node. Cloudflare, on 1.1.1.1, doesn't send ECS at all for privacy reasons. Neither is "good" or "bad" in a vacuum—but they're different stories. With Google, the authoritative server gets a hint about your approximate geography; with Cloudflare, they don't, but routing to the CDN may be less precise. The average user won't notice this. For someone building a consistent network profile, this is yet another parameter that either matches or contradicts the rest of the legend.

There's a simpler argument. Most home users don't change their DNS at all and work through their ISP's servers, which are assigned automatically via DHCP. Therefore, if the goal is to appear like a regular subscriber to a specific network, the ISP's DNS is often a more natural choice than a public resolver. Public 8.8.8.8 or 1.1.1.1 in this sense are a marker of deliberate configuration: they are chosen by enthusiasts, administrators, and corporate networks, but not by the average user of a mobile operator. This doesn't make a public DNS "bad." It just tells a slightly different story about your connection.

Consistency is more important than speed

The word "consistency" is increasingly being used in professional settings. It means that all elements of a network profile are consistent. If an IP address belongs to a German mobile operator, it's reasonable to expect a German time zone (Europe/Berlin), a German or English system locale, and DNS resolution through infrastructure sensibly connected to that network, rather than through an anycast node that physically routes the request to another continent.

Imagine a typical discrepancy: the IP address is that of a German mobile operator, the browser's time zone is Europe/Berlin, but DNS requests are sent to 8.8.8.8 and actually access the network through Google's American point of presence, and the interface language is set to en-US. None of these facts are in themselves alarming. But together, they create a picture that is difficult to explain by the normal behavior of a real subscriber. Each deviation individually isn't critical, but each new discrepancy increases the likelihood that the profile will appear unusual. Resolver speed is almost irrelevant in this logic: a gain of 10-20 milliseconds isn't worth the loss of consistency.

A practical approach

DNS selection shouldn't start with the question "which server is the fastest," but rather with the question "how should this system appear to the user?" The decision then usually breaks down by proxy type.

For mobile and residential (ISP) proxies, it's most natural for name resolution to occur through the respective provider's infrastructure—or at least through a resolver accessible on the other side of the tunnel, not from your actual machine. The key principle here is that DNS resolution should occur through the proxy, not around it. Then, both the request's geographic location and the ECS hint (if transmitted) will match the IP address of the primary traffic source.

For data center servers, internal consistency of the entire configuration is more important than attempting to mimic a home internet connection. It won't surprise anyone if a data center uses, say, Cloudflare or its own resolver—but if the entire fleet of nodes behaves uniformly, predictably, and without leaks, that's already a stable, or, in a good sense, "boring" picture. There's no universal solution here: the correct answer isn't determined by the speed rating, but by the legend the system must support.

DNS leaks and modern browsers

A DNS leak is typically understood to occur when DNS requests take a different path than the main traffic. For example, HTTP goes through a proxy, while DNS continues to be sent directly through the local ISP. This results in additional inconsistencies: the site "sees" one IP in the connection, while the authoritative DNS server along the way sees a completely different source of the request. A classic source of such leaks is the location of name resolution when working over SOCKS5. The difference is noticeable even at the curl level: the socks5:// scheme forces the client to resolve the domain locally (and the request bypasses the proxy), while socks5h:// passes the name to the proxy server, which resolves it on its side. The logic is the same in browsers: in Firefox, this is controlled by the network.proxy.socks_remote_dns parameter. If it is disabled, domains are resolved locally, resulting in a leak even with a formally configured proxy. This minor configuration detail completely changes where your DNS "leaks" from.

The situation is complicated by the fact that modern browsers are increasingly using DNS over HTTPS. Firefox became the first browser to enable DoH by default, in 2020 for US users; Chrome added Secure DNS mode the same year. Chrome is careful in this regard: it doesn't change your DNS provider, but only upgrades your existing resolver to an encrypted version if it supports DoH. However, this has a downside for those working through a proxy: if the browser automatically switches to Cloudflare's DoH endpoint over your real connection, DNS can leak bypassing the tunnel, even when HTTP is sent through the proxy. Finally, browsers aren't the only ones with their own name resolution mechanisms: Android 9 and later supports Private DNS (DNS over TLS), Windows 11 supports DoH at the system level, and individual apps implement resolution in their own ways. Therefore, today, it's not enough to check your operating system settings; it's important to understand how each app behaves individually. It's also important not to confuse DNS leaks with WebRTC leaks: the latter doesn't reveal names, but rather local and public IP addresses via STUN—a separate channel that should also be closed.

The main conclusion

Anti-fraud has changed significantly in recent years. Previously, the primary focus was on the IP address and its reputation. Today, the user's entire digital identity is analyzed: browser, device, language, time zone, routing, resolver behavior, DNS leaks, and dozens of other signals. Essentially, this is a probabilistic model that combines weak features into a single assessment—and introducing yet another discrepancy almost always costs more than the milliseconds gained by a fast resolver.

This eliminates the point of searching for the "perfect DNS." It's far more useful to think about the system as a whole. Moreover, a sterile, unrealistically cleaned-up configuration can sometimes look more suspicious than a standard one: real users aren't perfect. A good configuration doesn't have to be invisible—it should appear logical and natural, and its elements shouldn't contradict each other. This approach—consistency rather than chasing individual "best" parameters—usually proves the most sustainable in the long run: reputation builds over time, and a profile that remains coherent ages best.