I have reason to believe that my isp is intercepting all traffic on 53/udp and sending it to their servers, regardless of which one I choose.
I don’t need a solution, I already have DoH configured.
I am looking for a way to detect this (without dnssec, I am user-side this time). I hope this is somewhat related to the new multiperspective validation, and you have something to share on it.
My main worry it that when I do
dig @some_authoritative_nameserver example.com
what I get is not a proper answer but just rubbish.
I was going to say that conceptually there is no way to detect this except by seeing whether or not the replies are different from the truth as seen from elsewhere on the Internet (e.g. via DoH).
But then I remembered other cases of network interference and how we identified them, and I realized that there is a way:
Get a VPS server somewhere out on the Internet and install some kind of DNS server there (like BIND). Then connect to it from your ISP (sending it a DNS query) and see whether the VPS server actually receives your connection or not.
There are various ways to check that and various levels on which you could experiment. For example, you could make BIND or similar log queries and then see if your lookups generate a log entry or not (if you think the ISP might be outright blocking the connection and not attempting to proxy it). Or you could create a weird made-up zone that the server thinks it’s authoritative for and then query it directly for that zone, and see if you get the same records back. Or you could just have some other service listening on port 53 and see if the ISP allows you to connect to it (in the very simplest case, sudo nc -l 53 and nc myvps 53 and see if you can type back and forth between the two machines!).
There are some authoritative DNS services that will return information about the resolver used to contact them. They can help prove interception. (But they can’t prove a negative with complete certainty, since an improbably clever interceptor could lie!)
They can return:
The resolver’s IP address.
The optional EDNS Client Subnet extension sent by some resolvers to some authoritative servers, which normally identifies the subnet the resolver received the query from.
Note that large resolvers will use different IP addresses to contact authoritative servers, not the resolver’s public IP address. (They can also use a different IP version.) For example, 1.1.1.1 will use IPs assigned to Cloudflare. 8.8.8.8 lists the ranges they use in their FAQ. 9.9.9.9 will usually, but not always, use IP addresses assigned to PCH.
If you run, say, dig whoami.ds.akahelp.net txt @8.8.8.8" and it reports that it got the query from somewhere outside Google’s published ranges, or without an ECS extension, it was likely intercepted.
% whois 151.5.216.254
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '151.5.216.0 - 151.5.216.255'
% Abuse contact for '151.5.216.0 - 151.5.216.255' is 'abuse@wind.it'
inetnum: 151.5.216.0 - 151.5.216.255
netname: WIND
descr: Rete di servizio per il DNS di WIND
status: LEGACY
remarks: NEW DNS IPV4 ADDRESSES
[snip]
There are some devices and networks that unwisely intercepted 1.1.1.1 dating to before it was in use. It’s possible they’re still doing that inadvertently instead of intentionally intercepting all (major) DNS resolvers.