Transparent DNS proxies | Hacker News Reader

Transparent DNS proxies

dnsleaktest.com

170 pointsminxomat89 comments

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.

This isn't an issue on net neutral ISPs like Init7, but it is here in Germany. Even on a business Fibre line.

There's also jet neutral ISPs in Germany. But they're usually local only. TNG/ennit, for example.

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.

"There's also jet neutral ISPs in Germany. But they're usually local only. TNG/ennit, for example."

Actually, init7 itself is in Germany, right ? I know they have POPs there, as in France and .nl, etc.

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.

May I ask which ISP this is?

Google itself will return an edge node for google.com (or google.$TLD) if you're on an ISP with an edge node.

What ISP is this?

what ISP are you with?

I'm with BT and they don't appear to do this.

Are you sure that's what happening?

I suspect you maybe seeing resolution to Google's edge network. This isn't modification - it is how DNS is designed to work.

What feature of DNS allows this? I'm probably wrong if that's the case.

Perhaps I'll check some other domains too.

https://tools.ietf.org/html/rfc7871

That's an extension to let you use Google's DNS servers and still have CDNs work.

Without it the functionality described above will just work - it's only when you are using an unusual DNS setup that the extension is needed.

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.

You could switch to using GoogleDNS or OpenDNS.

If you prefer something more privacy oriented, but possibly not as fast:

  https://servers.opennicproject.org/
  84.200.69.80      # dns.watch
  84.200.70.40      # dns.watch
  37.235.1.174      # freedns.zone
  37.235.1.177      # freedns.zone
  213.73.91.35      # dnscache.berlin.ccc.de
  194.150.168.168   # dns.as250.net; Berlin/Frankfurt
  85.214.20.141     # FoeBud (digitalcourage.de)
  77.109.148.136    # privacyfoundation.ch
  77.109.148.137    # privacyfoundation.ch
  91.239.100.100    # anycast.censurfridns.dk
  89.233.43.71      # ns1.censurfridns.dk
  204.152.184.76    # f.6to4-servers.net, ISC, USA

Edit: I know this won't do anything for ISPs using transparent proxies (from the article: "Some ISP's").

This is just for people with shitty, but not as shitty ISPs. Such as ones that hijack NXDOMAIN: https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...

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).

[0] https://www.smartydns.com/support/isp-doing-transparent-dns-...

You should read the article

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.

... which doesn't do anything if DNS is transparently intercepted, as discussed in the article.

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!

apt-get install unbound && echo nameserver 127.0.0.1 > /etc/resolv.conf

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.

Wouldn't unbound's requests out to the net get caught by this proxying?

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.

This is something I'm personally very interested in. I'm planning to add one or both of DNS over TLS (https://github.com/bluejekyll/trust-dns/issues/38) or DNSCrypt (https://github.com/bluejekyll/trust-dns/issues/4).

Currently I'm planning to do just DNS over TLS. I'd love feedback on this if people are interested. Both of these address this issue pretty well.

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.

In this case, would the user just not resolve any DNS queries at all then if their ISP is intercepting all of them? Or am I missing something?

For the security conscious, failing closed is better than failing open.

DNS interception usually takes place by redirecting traffic destined to port 53, like so:

  iptables -t mangle -A PREROUTING -p {udp,tcp} --dport 53 -j TPROXY --on-ip mitm-ip --on-port 53

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.

Yep.

How do we sponsor an iOS browser extension of this like you mention on your site?

T-Mobile US used to do this, but stopped (coincidentally or not) after I complained. http://esd.io/blog/t-mobile-dns-hijack.html

Perhaps they just disabled it for you. They still do this for me.

The example URL in your article redirected me to porn.

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.

Another way of stopping this is DNS-over-HTTPS:

https://github.com/wrouesnel/dns-over-https-proxy

I wouldn't use this all the time, but I've been stuck behind a DNS-filtering ISP before which had a broken proxy. Nice to have a fallback ready

Is there an advantage this provides over just using DNSCrypt?

Almost certainly none. The real use case of DNS over HTTPS isn't resolution from the desktop but from the browser (in JS), this is just a useful hack.

Using DNSCrypt would help. Sadly if your after privacy, domain names are exposed in plain-text within the HTTPS request itself.

Huh?

https://github.com/jedisct1/dnscrypt-proxy/blob/master/DNSCR...

Oh! Sorry! I misread your comment. Yes: HTTPS can leak hostnmes.

[..] domain names are exposed in plain-text within the https request.

Only if your handshake negotiates to use SNI.

SNI is sent even if the server ignores it.

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.

> 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.

DNSCrypt still leaks your DNS queries to the legitimate resolvers.

DNSCrypt over Tor helps (unless all your traffic is sent only over Tor) but I'm not seeing tools to do this around.

Local DNSSEC validation allows your software to reject modified responses (provided the domain is DNSSEC signed).

In the future, DNS over TLS, will also prevent this kind of tampering, and additionally prevent snooping on your DNS-to-resolver traffic.

Only in an imaginary world where everyone signed their zones

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.

A correctly configured VPN solves this problem (testing that config is what the site does). Your VPN provider also becomes your DNS service.

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?

A DNS leak. The site we're posting about is a good resource.

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 …

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.

Care to share?

I'm using list from http://pgl.yoyo.org/as

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?

FYI, AT&T "uverse" internet service does this at the router level. There is no way to change the upstream DNS servers on their hardware either.

Why are they doing this?

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?

https://en.wikipedia.org/wiki/Verisign#2003:_Site_Finder_leg...

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.

rate limiting from 8.8.8.8 to a specific ISP perhaps?

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.

There are people who don't use vpns?

A critical piece of securing ones Internet, and a small price to pay to buy a good one. PIA passed the test for me, on mobile and desktop.

https://developers.google.com/speed/public-dns/docs/dns-over...

I'm somewhat confused about this. when i visit the main page it shows the ip of the vpn i'm on. i have block-outside-dns in my .ovpn file.

however when i click on the extended test i still get some IPs from my ISP. what can I do to fix that?

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.

If you prefer to test from the terminal you can run:

  host whoami.akamai.net

This will return the IP address of the DNS server you are using.

Outgoing IP of the DNS server to be correct $ host whoami.akamai.net whoami.akamai.net has address 74.125.72.138

My DNS is 8.8.8.8

74.125.72.138 is a Google DNS server in Iowa:

https://developers.google.com/speed/public-dns/faq#support

Or one that actually works:

  dig resolver.dnscrypt.org

  dig txt resolver.dnscrypt.org

whoami.akamai.net and resolver.dnscrypt.org give me the same result. Can you expand on the "actually works" part of your comment?

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.

Does running your own recursive resolver (that queries the root servers directly) get around this?

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.

AT&T definitely does this

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?

No proxying with Telus Vancouver with pfSense running unbound.

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.

Some ISP's also hijack NXDOMAIN requests to serve ads, see for example https://hackercodex.com/guide/how-to-stop-isp-dns-server-hij....

Have you ever been in a country with DNS censorship? (that includes for example Belgium and Denmark)

Can you provide evidence that Belgium and Denmark have "DNS censorship"?

I didn't think so.

He may be referring to the rather elementary form of DNS filtering that both countries currently employ:

* http://greatfirewallofbelgium.be/

* https://en.wikipedia.org/wiki/Censorship_in_Denmark#Internet...

Reply on news.ycombinator.com