How's that encryption coming, buddy? DNS requests routinely spied on, boffins claim Most people's DNS queries – by which browsers and other software resolve domain names into IP addresses – remain unprotected while flowing over the internet. And that's because, you may not be surprised to know, the proposed standards to safeguard DNS traffic – such as DNSSEC and DNS-over-HTTPS – have yet to be fully baked and …
When I follow that link, all I get is a page with the site name as title and a "Loading..." marquee. So, website fail.
And I note that all this hoopla is around DNS interception that is apparently put in place by ISPs. And the ones who do it for "profit" are in . . <drumroll> . . China, obviously. To me, if my ISP is intercepting my DNS requests, well I don't see that I can do anything about it and I fail to see why I should care, as long as I get to the web page I'm expecting to get to.
And don't bother me with MitM on this issue : if ISPs were widely redirecting people to other pages, we would know and we would sue.
So call me when Joe Hacker is intercepting my DNS requests. I'll pay attention at that point.
> Because someone is stealing most of the packets you sent...Duh
traceroute to whatismydnsresolver.com (139.59.216.17), 30 hops max, 60 byte packets
1 firewall.lan (192.168.1.1) 0.500 ms 0.408 ms 0.397 ms
2 10.106.80.1 (10.106.80.1) 8.364 ms 13.526 ms 14.292 ms
3 ten-0-5-1-6.orld14-ser1.bhn.net (72.31.216.182) 14.278 ms 14.848 ms 14.835 ms
4 ten0-11-0-4.orld71-car1.bhn.net (97.69.193.188) 17.721 ms 17.911 ms 17.893 ms
5 72-31-220-226.res.bhn.net (72.31.220.226) 15.676 ms 16.401 ms 16.388 ms
6 bu-ether44.tustca4200w-bcr00.tbone.rr.com (66.109.6.128) 16.581 ms 16.010 ms 20.713 ms
7 0.ae1.pr0.mia00.tbone.rr.com (66.109.1.87) 24.625 ms 20.405 ms 19.757 ms
8 ix-ae-23-0.tcore1.mln-miami.as6453.net (63.243.152.105) 25.569 ms 25.283 ms 24.998 ms
9 if-ae-1-2.tcore2.mln-miami.as6453.net (63.243.152.62) 250.751 ms 251.369 ms 249.845 ms
10 if-ae-3-2.tcore2.dt8-dallas.as6453.net (66.110.72.6) 251.330 ms 250.886 ms 251.073 ms
11 if-ae-34-2.tcore1.lvw-los-angeles.as6453.net (66.110.57.21) 249.765 ms 249.741 ms 250.536 ms
12 if-ae-2-2.tcore2.lvw-los-angeles.as6453.net (66.110.59.2) 252.348 ms 251.887 ms 250.691 ms
13 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 246.532 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 247.869 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 247.178 ms
14 if-ae-2-2.tcore1.svw-singapore.as6453.net (180.87.12.1) 245.922 ms 247.742 ms 246.338 ms
15 if-ae-11-2.thar1.svq-singapore.as6453.net (180.87.98.37) 247.035 ms 247.249 ms 246.797 ms
16 120.29.214.50 (120.29.214.50) 247.502 ms 249.688 ms 250.440 ms
17 * * *
Nice.
Performing a traceroute doesn't prove anything when it comes to DNS.
The path used by packets to perform information exchange with a particular web site, isn't the same path taken by DNS to resolve queries. Two very different protocols, for two very different services.
C'mon. You should know this.
SSL/TLS is dependent on DNS being authoritative. Otherwise they can easily pretend to be any domain name and present valid certificates for it.
Now, HSTS and pinning are combatting that but nowhere near everyone has deployed them, and without support for them from the individual websites you visit you would never know. Basically, insecure DNS breaks secure websites. Now do you care?
It also allows code injection - redirect google.com to a page which attacks your browser and then proxies in the content from the *real* google.com. You would never know.
So it's not quite as small an issue as you think it is.
And there is something you can do about it. It's called DNSSEC. Or even VPN to a trusted DNS server. Your computers don't have to support DNSSEC in order to benefit from it - just a trusted resolver using it to verify responses from the root nameservers down, and then passing the information to your machine securely.
DNS, and SMTP, together are the biggest security holes you have in your computer today.
"VPN to a trusted DNS resolver is my current approach for my systems."
It should be quite easy to set up a DNSSEC -> DNS resolving proxy. Usually such things are nothing more than a standard local caching DNS with DNSSEC verification enabled, such as DNSMasq or Unbound:
https://blog.josefsson.org/tag/dnssec/
(I think DNSMasq now works fine on its own, personally, that post is quite old but presents a second option for you).
"Basically, insecure DNS breaks secure websites. Now do you care?"
Thank you for the explanation. I get the theoretical problem. Practically though, given that it is only ISPs doing that, no, I don't care. Not now. I will if Joe Hacker starts doing it - which I know he can, but he's not. So it's not an actual issue, it's a theoretical one.
Basically the government's routinely ask the ISP to intercept traffic to your servers / vpn / websites
(the USA GB DE and CN are all at it)
They routinely present certificates that are valid although obviously have been generated on fly for whatever resource your accessing and because most trust Certificate Authorities (some of which are compromised... all it takes is some...)
The answer to this is to trust whoever signs the root i.e. norwegians trust the .no root and british trust the .uk root
this reduces the ability of for example the UK gov to intercept CN websites and vice versa...
also it would alert you if you do not trust any of them and they are trying to fake your resources...
To me, if my ISP is intercepting my DNS requests, well I don't see that I can do anything about it and I fail to see why I should care, as long as I get to the web page I'm expecting to get to.
Because logging DNS is yet another trove of information on your interests. It's quite feasible to build up a profile of your interests from that alone.
Naturally, until the FQDN is no longer sent in the TLS handshake SNI field in the clear, it's all a bit pointless as they're going to capture that too. Unless you use a decent VPN, of course.
On the subject of the little detection page, Stubby seems to kill it dead. Just sits there, looking confused :-)
Naturally, until the FQDN is no longer sent in the TLS handshake SNI field in the clear, it's all a bit pointless as they're going to capture that too. Unless you use a decent VPN, of course.
This is the main issue. Encrypting DNS doesn't offer you any privacy whatsoever because a MITM can simply snoop on the SNI field for the domain name.
DNSSEC for authentication on the other hand is extremely important, and I guess if we're doing that, we might as well develop encrypted DNS as well in readiness for when some boffins figure out how to do TLS without sending the domain/SNI field in plaintext. Arguably though, even the authentication is of diminishing importance with more sites adopting HTTPS which makes it difficult (though not impossible if they have the keys to a trusted CA) to MITM a redirects. They can look but they can't touch without it being very obvious.
But by that stage we could very well be seeing the mainstream adoption of multiple IP6 addresses on shared-hosting servers (doing away with SNI altogether), meaning a snooper can determine which domain you're accessing simply from the IP address.
Without using a VPN to disassociate your source and destination, no amount of encryption will actually hide your browsing history at a domain level.
Don't you just love the ignorant when they post something on a security site?
Pascal's response to this article actually gave me a chuckle. I didn't think anyone who is so ignorant on DNS would post something so silly.
I guess the filter most of us have for being quiet when something doesn't make sense to us wasn't provided Pascal.
Pascal, you aren't the center of the universe. Just because something didn't work for you.. doesn't mean it doesn't work. It just means you're too ignorant to figure it out. Perhaps you should research the problem on YOUR END a bit more. :)
Thank you for your enlightening response. Here's my point of view : I click a URL, nothing happens. I leave.
I am willing to discover, I am not willing to become an engineer. I have enough to do in my area of expertise.
That said, I am glad that there experts such as you who are well aware of the issues and obviously concerned by them. That is reassuring to know.
So I'll just leave you to it then.
Your DNS belongs to your ISP, they can just as well sniff all your traffic.
The only danger would be for users for remote DNS resolvers like 1.1.1.1, 4.4.4.4 or 8.8.8.8 or that Cloudflare DNS over JSON over HTTP over TLS thingy. Those are likely to be logged by both the provider itself or by third parties.
Tampering with DNS works for censorship, however bending sites to different servers is made hard/impossible by TLS.
In any case nobody will go through the trouble of sniffing DNS. If you want to get data on your users start a web service or some web framework hosted on your servers and use the logs.
Christian,
The ISPs can't monitor your Internet packets if they are encrypted, and many times, the route taken by the packets for all the web sites you view (from your computer to any particular web site) doesn't pass through the ISP.
However, if you use their DNS servers (and most people do), they can track where you have been on the Internet.
"However, if you use their DNS servers (and most people do), they can track where you have been on the Internet."
Well but they can see the destination address of the packets going to their routers. And obviously those packets have to pass through them as that's their business model. I hand them over IP-packets for them to send to the Internet and get packets from the Internet to me back.
All packets of data will go through and be routed by your ISP and there is no way around this, although there are ways to make it hard to work out what is going on datawise.
While the body of an packet may be encrypted (to whatever level of security this gives) the header provides all the information needed to track the packet of data, for example source and destination address and ports. This allows your ISP to record communications between your system and another system based on the IP address of each. In basic terms this allows your ISP to record the amount of data sent and received from your connection to any given server on the Internet.
Because DNS is not encrypted, and can be tampered with, your computer will send a request for a domain name to IP address translation and combining this with the packet monitoring allows the ISP to very easily tie together the DNS request for "gerbilsindresses.com" with the IP address of the server and to then profile your interaction with this site through the amount of data that you send and receive from it.
If the connection that you are using to the server is not using https then the contents of the packets will also be visible, but that's a different subject entirely.
and many times, the route taken by the packets for all the web sites you view (from your computer to any particular web site) doesn't pass through the ISP.
They literally do. How else does your computer communicate with any particular web site than through your ISP?
...at least some of the slow uptake of encrypted DNS queries is down to governments wishing to snoop on people's "metadata". If DNS lookups where end-to-end encrypted, they would only be able to know when a DNS lookup was being made, and not the DNS name being sought.
If nothing else, encryption would prevent them from being able to order ISPs to block or redirect DNS queries to 'forbidden' sites (e.g. the Pirate Bay). Arguably, ISPs could still block access to such sites after a DNS lookup has been made to resolve them, but this could be a bit of a whack-a-mole game if IP addresses change.
Joking aside, it's entirely plausible that DNS servers in the UK, particularly those operated by major ISPs would be relaying the DNS requests of at least some people-of-interest to GCHQ (by court order, one would hope, making it entirely legitimate). Outside the UK, in the wider EU, I can't see this being the case without the explicit consent of foreign governments. I can't imagine any EU nations would allow this. After all, the UK wouldn't consent to its own citizens being monitored by the French or German security services, much less those of ex-Soviet Eastern European nations with whom diplomatic ties are looser.
Once I turn off No Script at http://whatismydnsresolver.com/ my DNS resolver shows up as a BT address even though I'm behind a VPN. Looking at /etc/resolv.conf shows:
nameserver xxx.xx.xx.xxx
nameserver xxx.xx.xx.xxx
nameserver 192.168.1.254
If I # out the local address then whatismydnsresolver.com/ correctly shows the VPN DNS address request. Todays lesson: don't trust your local network as a DNS fallback unless you know what your evil router is up to. I can't change the homehub's default DNS so I guess I need a new router. Any suggestions for something compatible with BT?
No need for a new Router.
Switch off (or just don't use) DHCP and whilst assigning the gateway and a unique IP for each device, configure DNS manually on each pc.
If using W10 it would be prudent to occasionally check that it hasn't silently put you back to DHCP, so best to login to the Router and turn it off there.
Edit: Apparently on some HomeHub's if you login and disable the broadband, an option appears where you can set manual DNS.
On older HomeHubs (anything that isn't a Smart Hub) you can indeed disable the connection, change the DNS settings and restart the service.
On the current SmartHub you only have the option to disable the DHCP service entirely, which is what I did. I then have a piHole running DHCP and DNS services.
The most blocked domains tend to be telemetry holes belonging to Microsoft...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
