Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What's the best way to tell if they're intercepting queries to other dns servers and replying themselves?

Say I manually set my dns to 1.1.1.1, is there a way to tell if the replies are really from 1.1.1.1?



> What's the best way to tell if they're intercepting queries

Setup a simple DNS resolver in an external VM (use a service like DO where you can pay by the hour, and the test will cost you at most tens of pennies), configure it with a DNS zone that the rest of the Internet does not know about (thisdoesnotreallyexist.net). Then if you try query for that domain from that server but get an NXDOMAIN response your query was probably intercepted (of course test from other locations too, to make sure the problem isn't a mistake in the new resolver's config).

Or you could configure the test resolver to give different answers for an existing domain, of course, and check for which addresses you get back instead of checking for address or error - that would essentially be the same test.

Or, he says, thinking of the obvious after explaining the more long winded, if you have a DNS server in your control, simply turn on the relevant logging options and run a query against it and see if your query turns up in its logs.

This assumes they are intercepting and NATing all standard DNS requests (usually on UDP & TCP port 53), rather then just DNS traffic going to a list of known alternative DNS services. If they are doing the latter then there are tests you can do that rely on timing and TTL settings (get their server to cache a result, change the name->address mapping, then ask 8.8.8.8 or similar and see what answer you get).


With no changes to your setup it is actually impossible. DNS as it currently exist is a plain text protocol.

If you run your own dns server at your local machine you can enable DNSSEC, which will protect against manipulations for domains that has that enabled. A recursive dns server is pretty easy to setup and it a step towards running your own authoritative server in the future for private domains.

If you want to resolve using googles DNS servers and be sure it is really them then the only method that I know that is also supported by google would be DoH. The other encryption method they support, DoT, do not provide authentication and draft-bortzmeyer-dprive-resolver-to-auth-00 is to my knowledge not implemented by google.

If you want a bit more privacy and have a mix of the two above then go with a VPN or build one yourself. Just note that without DoH you won't be authenticating between the VPN and google, so I would just use a resolver at the VPN.


If you run your own DNS server at your local machine, you'll be exposing all your queries to your ISP, which will log and monetize them. You'll gain support for a DNSSEC protocol that virtually nobody on the Internet uses --- DNSSEC only functions on signed zones, and in 25 years almost nobody has signed a zone --- and so your ISP will almost always be able to manipulate your queries anyways.


If you use google servers under plain text you will be exposing all your queries to your ISP and to google, which will log and monetize them. DNS under plain text is so easily captured that all entities. ISP that spans the traffic to google, google itself, and ISP that spans from google to the resolver can capture, log and monetize the information. Monetizing can occur by logging who queried, what was queried, and in either as a combination or in isolation. A lot of companies consider the later to not be private information or covered by GDPR.

The effectiveness of DNSSEC depend on where you are. If you live in Netherlands or Sweden and visits mostly Swedish or Dutch sites then a larger portion will be signed.


I noticed they were doing this when I saw that in-band DNS updates were failing. Eventually I realied that my router (or something upstream of it) was returning an error to the client rather than passing through the GSS-TSIG-signed nsupdate packet.

So far I have been unsuccessful in my attempts to get through to a technician who knows anything other than "try turning it on and off again". I suspect this policy is deliberate.


of course: dnsleaktest.com


If it is not "encrypted" (with some form of end-to-end encryption, like HTTPS or SSH), you dont.


An NSLOOKUP will tell you the DNS server that your query went to.


Unfortunately that will not help: if the requests to other servers are NATed when they hit the router it will look like your request went elsewhere when in fact to went to Sky. nslookup is reporting what it tried to connect to for an answer, not what actually answered.


ISPs can man-in-the-middle spoof that too, right?


Even if you intercept and nat traffic going to UDP/53?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: