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.
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
22.214.171.124 is used as a resolver.
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
.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
126.96.36.199 directly in their logs, not to mention the query for
A might be asked from a different authoritative server than
If the first authoritative name server logs the requests, it might see:
188.8.131.52#19489 (example.com): query: example.com IN AAAA -EDC (184.108.40.206)
While the other request may finally go to the second authoritative name server, which may log:
220.127.116.11#35024 (example.com): query: example.com IN A -EDC (18.104.22.168)
22.214.171.124 is the IP address of the recursive server from
126.96.36.199 is another IP address from the same netblock belonging to Cloudflare, Inc.
188.8.131.52 are just the IP address for the authoritative server self i.e.
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.