1

Whenever I query example.com, one of the TLD root servers for .com will be queried for example.com. This query includes my IP address, and in theory could be used to identify my browser session.

Given that jurisdictional domains (such as .us, .me, .gov) likely have privacy policies that support the viewpoints of the various local governments, or sponsoring institution, there is bound to be an inconsistency.

Is there any spreadsheet (similar to the VPN spreadsheet) that lists the various DNS providers by TLD, and the privacy policy?

My primary concern is that most top tier providers charge "per query", which means that every query is logged in some form. The second question is who audits this implementation to ensure compliance, but I don't think that is something that anyone is doing these days.

Improve this question
3
  • 2
    "This query includes my IP address..." this would be done by the recursive resolver, usually run by your ISP or organization, rather then from your host.
    – Torin
    Feb 19, 2019 at 20:06
  • I don't know who you consider 'top tier providers' but I've never heard of any DNS server anywhere, authoritative or recursive, charging for queries in any way. The only thing they might possibly do is throttle a requester who imposes excessive load, and they prefer not even to do that. And at least for older TLDs, the 'policy' has always been that all DNS is completely public -- privacy was never a goal or even a consideration until recently.
    – dave_thompson_085
    Feb 21, 2019 at 5:07
  • @dave_thompson_085 UltraDNS, Dynect, and others do charge per query (in the range of 10s of thousands queries for $50, or something like that)
    – TLDR
    Feb 21, 2019 at 13:10

1 Answer 1

Reset to default
2

IF the local government or the ISP of the site wants to log your IP address while you visit example.com, they would rather read it from the TLS Client Hello handshake's (plain) Server Name Indication (SNI) extension.

Wireshark reveals SNI

Therefore, the DNS is not the first thing to be worried about in this situation, but let's explain why they would not choose the DNS queries for this kind of monitoring as it doesn't reveal your IP address to to them.

Whenever you query example.com, you send exactly one UDP packet for IPv4 A and other for IPv6 AAAA to your DNS resolver and get responses directly from it. Here, Cloudflare's 1.1.1.1 is used as a resolver.

Wireshark capture for <code>nslookup example.com.</code>

The resolver a.k.a. recursive name server either 1) already has the response cached, 2) asks for it exactly the same way from its forwarders or 3) starts resolving it for you starting from the root servers. If the any of the authoritative name servers for ., .com or .example.com logs these queries, it only sees the IP address of the final recursive resolver.

In our example, the authoritative name servers doesn't even see the 1.1.1.1 directly in their logs, not to mention the query for A might be asked from a different authoritative server than AAAA.

If the first authoritative name server logs the requests, it might see:

162.158.237.161#19489 (example.com): query: example.com IN AAAA -EDC (199.43.135.53)

While the other request may finally go to the second authoritative name server, which may log:

162.158.237.107#35024 (example.com): query: example.com IN A -EDC (199.43.133.53)
  • 162.158.237.161 is the IP address of the recursive server from CLOUDFLARENET 162.158.0.0/15.
  • 162.158.237.107 is another IP address from the same netblock belonging to Cloudflare, Inc.
  • 199.43.135.53 and 199.43.133.53 are just the IP address for the authoritative server self i.e. a.iana-servers.net. and b.iana-servers.net. and doesn't reveal anything: it's just the BIND named log format.

Now, only Cloudflare (or your ISP or company etc. whose resolver you are using) and everyone who was able to sniff the UDP packets between you and the resolver knows that you were looking for example.com. This risk is another story, but to mitigate it you may:

  • Use a resolver you trust and is near you, but also has plenty of users.
  • Encrypt your communication with a trustworthy resolver using DNS over HTTPS or DNS over TLS.
Improve this answer
4
  • For a full overwiew I think you need to take into account QNAME Minimization (not sending the full name to each nameserver, still not widely used), and also the EDNS Subnet client option that allows a recursive to send part of the IP (some IP block) to the authoritative so that it can return a result based on the client IP (specifically needed for CDN and GeoDNS as the recursive nameserver and the client behint it can be very apart network-wise).
    – Patrick Mevzek
    Feb 25, 2019 at 16:35
  • Also, no need to emphasize so much on UDP, it does not change much of the explanation, and may give the impression (that is still widely shared, even if wrong) that the DNS (even its pure classical version) works only over UDP, which it does not as it uses TCP as well.
    – Patrick Mevzek
    Feb 25, 2019 at 16:36
  • I think currently around 10% of all DNS queries are made over TCP, but changing the transport protocol doesn't add anything essential. I hope TCP won't call The Ombudsman for Equality for being discriminated in my answer. :)
    – Esa Jokinen
    Feb 25, 2019 at 16:55
  • "I think currently around 10% of all DNS queries are made" any source for that? Changing the transport protocol does not add anything essential, which is exactly the reason why there is no need to emphasize the transport at all.
    – Patrick Mevzek
    Feb 25, 2019 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .