Seems almost like a Man In The Middle attack. If I send my DNS request to 8.8.8.8, I kinda expect it to go 8.8.8.8 and not get replaced by something of the ISP's choice.
Isn't this one of the points of Net Neutrality? My ISP (Comcast) doesn't do this currently. I suppose I'll have to check again on January 21.
My ISP in the UK actually modifies the result of any lookup of google.com/google.co.uk regardless of if I am using their DNS or not.
I don't think this specific example is malicious (it's part of Google's Edge Network I guess? I wouldn't know), but it does show that they're already capable of modifying the DNS lookups ran by their customers.
I'm currently switching to a MLVPN bonded connection using a dedicated HLKomm and T-Online Fibre connection. Egress is also Germany, but a neutral backbone in a data centre. I just noticed that TO still uses their old DNS caches.
DNS has always been one of the weakest links in security in my personal experience. From transparent DNS proxing, to DNS hijacking in local network attacks, to complete and quite transparent, often very permanent and undetectable hijacks of consumer-level network equipment, such as routers, through trivial UPNP hacks.
The worst side effect of how my ISP implements this is the failure mode for DNS queries. Instead of returning an error code, they actually return a marketing page. That page contains a fake search engine, with results. If you look at the "results", they are all ads for the ISP I'm already on...
In a just America, people who do this would be jailed. To add insult, the majority of my DNS lookups are not for hosts I'll contact via port 80 or 443, so even in some twisted universe where I wanted their ads, their lying doesn't help me.
I'm sure you have 500 kB free RAM for a proper resolver that works in the real world, and validates DNSSEC for free. I think most resolving should be done locally nowadays. Latency is mostly a last mile problem.
I'd guess not since unbound does its own recursion. DNSSEC doesn't play well with nxdomain trickery so customers gets unhappy and that's something even shady ISPs avoid.
Edit2: I couldn't get the test from dnsleaktest.com to work on my computer, but starting at step 3 from [0] seems to work fine (I do already use DNSCrypt with Unbound).
You can't switch your DNS with transparent proxies. That's the whole point of this post. Even if you change your DNS server, your queries to that server are intercepted by your ISP.
You can pay for a VPN service that does not transparently proxy DNS and tunnel either DNS requests or DNS requests + other data through it to the DNS servers you are actually intending to use.
I used to wonder where those marketing pages came from, I had assumed it was a rogue browser extension. Now that I think about it... it must've been DNS!
That's exactly why I created dnscrypt: https://dnscrypt.org -- Verify that responses you get actually come from the resolver you chose. If not, they are ignored.
Doing this isn't inherently malicious. Most of the time it's done for performance reasons. Bad idea, if you ask me, but whatever.
Since dnscrypt transmits DNS requests over port 443, which is also used by HTTPS, ISPs can't redirect the packets without performing more costly fingerprinting, or else websites would break.
dnscrypt packets are also encrypted and authenticated, so the worst probable thing an ISP could do is, like you said, drop the requests.
I run unbound on my laptop. My ISP poisons DNS with random crap like state sponsored censorship. Sometimes I'm in places where DNS requests are blocked/filtered/messed with, in which case I simply tunnel all my traffic.
I wish people would stop fucking with DNS. It's bad enough as it is. To quite Kris Buytaert: everything is a freaking DNS problem.
>My ISP poisons DNS with random crap like state sponsored censorship
Silly question - if you're in this kind of environment, is it safe to do something like messing with DNS requests? This would make you "stand out" from a traffic analysis point of view.
> domain names are exposed in plain-text within the https request
Which exposes nothing more than the previous solution of having one ip per https domain, which made it just as obvious what domain you were connecting to. Putting the domain in the request allowed people running the servers to host any number of sites from the same ip. A convenience for the operators that exposed nothing new for the consumers.
And even if your client software doesn't use SNI... the server has to send you the cert before an authenticated encrypted channel can be established, so the cert's snoopable - and has the domain name in it.
You always have to do something to make things secure. TLS certificates don't show up out of thin air. So, yes systems that don't bother to use security mechanisms will be insecure. That's normal.
Which increases your security more: using DNSSEC, or using OpenDNS which automatically blocks malware domains / botnet C&C, etc?
Right now there are real, tangible benefits to just using OpenDNS. There are very few benefits to setting up your own resolver with DNSSEC due to the limited amount of zones signing with it.
I know these protect you from two different types of attacks, but for the average user the OpenDNS solution is more likely to protect them from harm (malware, ransomware, etc) than DNSSEC stopping a state actor doing a MITM (between end user and OpenDNS) which wouldn't be possible if you used OpenDNS via dnscrypt anyway; the state actor would have to successfully and undetectably poison OpenDNS's cache.
tl;dr: To the average user DNSSEC has a miniscule security impact in their everyday internet usage.
I've just tested the VPNs I use: The DNS server doesn't change, i.e., it's the same DNS server as when I go online without a VPN connection. What could be the reason for this result?
Probably it depends on VPN settings. I'm using OpenVPN server running on a VPS in another country. I'm running unbound there, so I'm sure that my DNS responses are legitimate.
Another plus is that I've tweaked unbound config to return NXDOMAIN to some ad networks, so I can browse internet with less ads without adblock.
I can set another DNS server and it is actually used – but it remains the same for VPN connections. Probably a local configuration issue, I will look into it …
I changed /etc/resolv.conf to use 8.8.8.8, The test shows my ISPs name servers which would indicate they are using a transparent proxy however "dig +trace google.com" does not show these same ISP servers anywhere. I wish this page had more info on it, are these ISP's transparent proxy's rewriting the TCP headers?
Speed/traffic. Also some ISPs hijack domains that don't resolve to custom ad pages. Does anyone remember when Verisign did this for root servers in 2003 for .com/.net and it BROKE EVERYTHING?
My ISP still serves ads for all DNS failures. Also, their cache times are absolutely ridiculous. It makes remote web development completely impossible. Let's say I change the DNS on a new domain (which takes only a few seconds to propagate with InternetBS+CloudFlare). Yet, if I queried the domain one time where it wasn't live yet, that error is cached for almost a day, with no chance of purging it. So others can see/use my service, but I can't.
Unclear.Someone mentioned to try to sell domain names that don't resolve but the "buy this domain name" for domains that don't resolve is real bottom of the barrel type tactics. I would be really surprised if there is much money in this and it's just horrible and unprofessional.
If you're using Linux you can use iptables to block any outbound packets that's destination IP isn't your VPN IP once OVPN is up; obviously on all interfaces except loopback and your OVPN interface. And remove it again once your drop your OVPN connection. You should also make sure that your routing table has an entry for your VPN IP (via your LAN interface / old default gateway), one singular default route that uses your OVPN interface and VPN internal remote address, and lastly that all cached routes are dropped on VPN connection.
Not all OVPN configurations will do this correctly, it depends on your distro / configuration.
This wouldn't show when your ISP is using a transparent proxy. The 'transparent' part that it intercepts the request and responds as if it were coming from who you wanted (eg. 8.8.8.8) when in fact it is coming from your ISP.
No. The ISP is doing, effectively, an MiTM attack. Your recursive resolver's queries will just get redirected too. You'll have to run them over some kind of tunnel to obscure them.
I have AT&T U-verse and have my network adapter set to use 8.8.8.8 and 8.8.4.4 (since the U-verse modem doesn't allow custom DNS servers). The site reported that my DNS requests came from Google. Perhaps it's different for different service levels?
Unless one is for some reason unsatisfied with one's ISP DNS service, why would one use another one? I mean, after you get your response from server X, it is your ISP that will deliver the webpage so privacy-wise it doesn't make any difference (not even if you're using DNSCrypt or whatever). If your concern is response time then use dnsmasq. If you're using a VPN your ISP can't see your DNS requests (nor if you're using TOR and have properly configured it). Yes this is basically a MITM and it's bad, I'm just wondering why would anyone use something other than their ISPs DNS service in the first place.
It matters if the local ISP DNS relay uses unreasonable cache times that you can't purge. This interfered more than one time with my development process on remote servers. I had to tunnel through another of my servers to circumvent this.
If you work on DNS at all you need control over the cache so you can purge it as needed. This is why I run my own local unbound server as well. Plus it makes it easy to add forwarders for specific domains when you use a limited routing VPN.
Isn't this one of the points of Net Neutrality? My ISP (Comcast) doesn't do this currently. I suppose I'll have to check again on January 21.