DNS Resolvers Are a Path, Not an Identity

Intro

A browser does not pick the recursive resolver the way it picks a TLS library. The operating system, the LAN, the VPN client, or a human who typed 1.1.1.1 into adapter settings does. The collector therefore sees a different layer than JavaScript does.

That is useful. It is also easy to misuse. A public resolver is not a crime. Two resolver addresses are often IPv4 and IPv6 on the same box. The interesting case is when the resolver, the SYN, and the JS timezone tell three different stories about where the session lives.

Fraudnode reads the DNS block on the same collect as TCP and JS. The point is consistency of path, not a nickname for Cloudflare.

Who actually got asked

The stub resolver on the machine sends the query. What the HTML page later fetches over HTTPS is a different conversation. Anti-fraud that only looks at the HTTP Host header never sees this hop.

An ISP resolver usually sits near the access network. A public resolver sits in someone else's anycast. A VPN often pushes its own tunnel DNS so the real LAN resolver never speaks. All three are legitimate engineering. They become a question when the rest of the session still claims to be a home desktop in one city.

Dual-stack is not a rotation

Seeing two resolver addresses in one session is common. One can be IPv4, one IPv6. One can be the ISP, one a backup. Treating "more than one" as infrastructure hopping will punish ordinary laptops.

What is rarer, and worth a look, is resolvers that do not share an organization or a country with each other, or with the TCP source. That is a path change. It is still not a verdict. Carrier-grade NAT, privacy relays, and corporate split-DNS produce similar splits without a retail VPN.

Public resolvers

1.1.1.1, 8.8.8.8, and their peers are popular because they work. Plenty of clean sessions use them. The signal is not "public DNS equals masked." The signal is "this session's DNS country and its TCP country and its JS timezone do not sit in the same story."

EDNS Client Subnet can send a truncated view of the client net toward the authoritative name server. Many resolvers send it. Many do not. Missing ECS is not stealth. Present ECS is a hint about the network the stub lives on, which may disagree with the TCP source if a tunnel opened after the stub was configured.

How to read it without lying to yourself

Use DNS as a consistency check.

If language, timezone, and resolver all sit on the same access network as the SYN, the path is at least plausible. If the SYN comes from a hosting ASN while JS still writes a residential timezone and DNS still talks to the home ISP, you have a question. If DNS never arrived, you have a missing block. Fraudnode does not invent a resolver and wave the client through.

Never promote a single resolver count into a product decision. Counts rot when a phone adds IPv6, when an OS ships encrypted DNS, when a browser starts resolving inside the app. The honest output is: the resolver set does or does not match the rest of the session.

What to look at next

TCP MSS and window scale describe the pipe. TLS ClientHello and HTTP/2 SETTINGS describe the library. DNS describes who was asked to find the name. You want all three. You do not want to confuse a public resolver with a fake browser.