
Transparent DNS proxies - minxomat
https://www.dnsleaktest.com/what-is-transparent-dns-proxy.html
======
CalChris
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.

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

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

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

Perhaps I'll check some other domains too.

~~~
giovannibajo1
[https://tools.ietf.org/html/rfc7871](https://tools.ietf.org/html/rfc7871)

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

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

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

~~~
ChoGGi
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_...](https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs)

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-...](https://www.smartydns.com/support/isp-doing-transparent-dns-proxy/)

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

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

------
jedisct1
That's exactly why I created dnscrypt:
[https://dnscrypt.org](https://dnscrypt.org) \-- Verify that responses you get
actually come from the resolver you chose. If not, they are ignored.

~~~
kylepdm
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?

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

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

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

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

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

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

[https://github.com/wrouesnel/dns-over-https-
proxy](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

~~~
parent5446
Is there an advantage this provides over just using DNSCrypt?

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

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

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

Only if your handshake negotiates to use SNI.

~~~
hsivonen
SNI is sent even if the server ignores it.

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

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

~~~
feld
Only in an imaginary world where everyone signed their zones

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

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

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

~~~
chmars
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?

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

~~~
sliken
Care to share?

~~~
vbezhenar
I'm using list from [http://pgl.yoyo.org/as](http://pgl.yoyo.org/as)

------
bogomipz
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?

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

------
Jonnax
Why are they doing this?

~~~
djsumdog
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...](https://en.wikipedia.org/wiki/Verisign#2003:_Site_Finder_legal_case)

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

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

------
danieljp
[https://developers.google.com/speed/public-dns/docs/dns-
over...](https://developers.google.com/speed/public-dns/docs/dns-over-https)

------
leshow
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?

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

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

~~~
jedisct1
Or one that actually works:

    
    
      dig resolver.dnscrypt.org
    

or

    
    
      dig txt resolver.dnscrypt.org

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

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

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

------
sroussey
AT&T definitely does this

~~~
nathanaldensr
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?

------
jtl999
No proxying with Telus Vancouver with pfSense running unbound.

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

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

~~~
eikenberry
+1

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.

