# How to detect MITM on DNS? **URL:** \ **Category:** Help\ **Created:** [March 6, 2020, 3:18pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657 "2020-03-06T15:18:22Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [March 6, 2020, 3:18pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/1 "2020-03-06T15:18:22Z")
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 ```nohighlight dig @some_authoritative_nameserver example.com ``` what I get is not a proper answer but just rubbish. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [March 6, 2020, 5:58pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/3 "2020-03-06T17:58:19Z")
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!). ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [March 6, 2020, 6:02pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/4 "2020-03-06T18:02:36Z")
This should be interesting. I’ll try. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [March 7, 2020, 3:43pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/5 "2020-03-07T15:43:45Z")
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](https://developers.google.com/speed/public-dns/faq#locations). 9.9.9.9 will _usually_, but not always, use IP addresses assigned to PCH. For example, [Akamai runs this](https://developer.akamai.com/blog/2018/05/10/introducing-new-whoami-tool-dns-resolver-information): `$ dig whoami.ds.akahelp.net txt` 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. Google runs `o-o.myaddr.l.google.com`. [PowerDNS runs several things](https://powerdns.org/useful-names/). I run `whoami-ecs.lua.mattnordhoff.net`. You can also sometimes detect more subtle differences between different implementations. (Mostly obviously whether DNSSEC is used or not.) Edit: You can also try to query the authoritative servers for those zones directly. ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [March 7, 2020, 3:48pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/6 "2020-03-07T15:48:12Z")
> [@mnordhoff](#): > > 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. Great. ```plaintext % dig whoami.ds.akahelp.net txt @1.1.1.1 +short "ns" "151.5.216.254" ``` yeah, not good: ```plaintext % 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] ``` ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [March 7, 2020, 3:51pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/7 "2020-03-07T15:51:23Z")
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. ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [March 7, 2020, 3:53pm UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/8 "2020-03-07T15:53:55Z")
I’d say that’s not the case, it’s a very big isp with tens of millions of users, and: ```nohighlight % dig @8.8.8.8 o-o.myaddr.l.google.com. txt +short "151.5.216.254" ``` and their reason… is probably this: ```nohighlight % dig @8.8.8.8 thepiratebay.org +short 127.0.0.1 ``` ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [March 21, 2020, 9:33am UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/9 "2020-03-21T09:33:36Z")
Funny thing about my network operator: they only interfere with 53/udp – 53/tcp works fine: ```nohighlight % dig +tcp +short @8.8.8.8 whoami.ds.akahelp.net txt "ip" "151.29.19.44" "ecs" "151.29.19.0/24/24" "ns" "2a00:1450:4025::104" % dig +tcp +short @8.8.8.8 thepiratebay.org 104.24.190.20 104.24.191.20 ``` ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [April 20, 2020, 9:33am UTC](https://community.letsencrypt.org/t/how-to-detect-mitm-on-dns/115657/10 "2020-04-20T09:33:42Z")
Closed on April 20, 2020, 9:33am UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.