"Google, this is bogus as hell," Paul Vixie ranted on Internet Engineering Task Force mail list this week. The IETF mail list is where the people who create the internet's technologies converse.
The post was noticed because Paul Vixie is an Internet Hall of Fame engineer known for his pioneering work on the modern Domain Name Service (DNS).
And it is how Google was using DNS in its Chromecast Ultra streaming device that ticked him off.
[...] [Vixie] bought a Google Chromecast. But when he went to set it up, he found it doing something no device in his network is allowed to do: It wouldn't use his own, private DNS server. It would only use Google's public server.
Related: Paul Vixie: New TLDs a Money Grab, and a Mistake
VLC 3.0.0 Released, With Better Hardware Decoding and Support for HDR, 360-Degree Video, Chromecast
Paul Vixie on the Benefits of Running DNS Services Locally
(Score: 3, Funny) by Runaway1956 on Sunday February 17 2019, @09:19AM (18 children)
How did he convince the device to use his own resolver? I suppose a HOSTS file entry would do it, if the HOSTS was located on his outgoing router/modem. I'll bet dollars to donuts that Vixie doesn't use a cheap-ass consumer router or modem.
(Score: 4, Informative) by driverless on Sunday February 17 2019, @09:28AM (6 children)
Chromecast: Google DNS, gimme the IP address for xyz.com
Something on Vixie's network: Hi Chromecast, this is, uhh, 8.8.8.8, yeah, that's it, I'm 8.8.8.8. Here's the DNS results you asked for.
At least the mostly-miss deployment of DNSSEC has one good thing going for it...
(Score: 0) by Anonymous Coward on Sunday February 17 2019, @10:11AM (5 children)
Maybe you just don't know what DNSSEC is suppose to do? Just throwing terms around doesn't really mean you know what they mean.
(Score: 5, Touché) by driverless on Sunday February 17 2019, @11:03AM (4 children)
Maybe you're talking to a DNSSEC RFC author.
Your move.
(Score: 0) by Anonymous Coward on Sunday February 17 2019, @11:19AM (3 children)
Which is quite sad that he doesn't know how it works? Your move.
Hint: MITM 8.8.8.8 DNS queries/replies has fuck-all to do with DNSSEC
(Score: 3, Insightful) by zocalo on Sunday February 17 2019, @01:22PM (2 children)
DNSSec has absolutely everything to do with whether or not you can easily MITM a given domain (or in-addr.arpa).
UNIX? They're not even circumcised! Savages!
(Score: 4, Informative) by Anonymous Coward on Sunday February 17 2019, @05:12PM (1 child)
So, you have also exactly 0 idea how DNSSEC works.... fucking hell... and they mod you insightful? Ok, let me explain.
DNSSEC signs *ZONES*. ie. DNS ZONES. You can MITM it all you want. And you can intercept and generate all replies you want. With DNSSEC I can 100% of the time MITM reply of a DNSSEC signed domain. What I cannot do is *change* that reply. But I can intercept and resolve these queries on my resolver and forward the signed domains (clearly, by the original signer of the zone) to the recipient. I can also drop packets and ignore them causing timeouts. But I cannot fake replies including I can't fake a negative reply.
If I query 8.8.8.8, it's an UDP or a TCP packet. It has *nothing* to do with DNSSEC. That's at a different level, not IP level.... :/
So, do you now understand how it actually works? DNSSEC brings *authenticity* of signed zones to the replies. It doesn't prevent eavesdropping, blocking, dropping, MITM dns servers. And for shit clients that rely on DNS servers for verification of signed domains, then DNSSEC is useless because I can just fake the AD bit in reply and a shit client would believe it without checking actual reply. HINT: The standard remote resolver's verification of signed zones is just a curtsy, not what should happen. Verification must happen on *client* side. But if you thing that's bad, for unsigned zones, it's a Wild West out there. Anyone can do whatever they want with the packets. Want to go to google.com? Here's a nice server in China waiting for you! (google.com is unsigned)
And if you want to prevent evesdropping between your client and the DNS resolver, then have to use something else in addition to DNS protocol. Like DNS-over-HTTPS, is an easy solution. I think PowerDNS recursor added support for that already.
PS. MITM is how internet routing works... each hop is a MITM by definition. But most are nice and just forward the packets along.
(Score: 3, Interesting) by darkfeline on Sunday February 17 2019, @10:04PM
Anonymous Coward saves the day. This is (one of the reasons) why DNS-over-HTTPS and DNS-over-TLS exists, TLS *does* prevent MITM, eavesdropping, etc.
Join the SDF Public Access UNIX System today!
(Score: 5, Interesting) by Anonymous Coward on Sunday February 17 2019, @09:37AM (5 children)
I do this at home.
My gateway is a linux router running iptables and what not with unbound as a resolver.
All you do is add 8.8.8.8 as an interface to the router and get unbound to respond on that address. I probably should add 8.8.4.4 as well.
Everything works fine.
I also hard block any device from using a DNS outside my network and turned on DNSSEC validation.
(Score: 0) by Anonymous Coward on Sunday February 17 2019, @12:02PM (2 children)
Just route all DNS queries to your own resolver. DNSSEC validation does nothing to protect you from DNS queries MITM. It only protects signed domains from being spoofed.
But now browsers are turning on DNS over HTTPS is a standard as RFC 8484, which kind of fucks up the decentralized nature of DNS.
(Score: 2) by opinionated_science on Sunday February 17 2019, @03:20PM (1 child)
I'm curious - with bandwidth a "better" thing (I finally got 1000Mbps theoretical...), how easy would it be to have all the DNS updated like a package?
What is the delta/month/day/hour?
Just wondered if someone has run the numbers...?
(Score: 0) by Anonymous Coward on Sunday February 17 2019, @05:03PM
Even if the bandwidth is available, and the compressed text files aren't obscenely large, I'd point out that zone transfers to untrusted hosts have (hopefully) been totally disabled globally by now.
It was quite a common thing to go fishing through a domain's dns files looking for 'interesting' looking names to go play with...I know that's how a miscreant found one of our Sun servers back in the early '90s (we had no control over network, there were no firewalls..As TPTB wouldn't implement one, I cobbled together the hardware at my own expense to get a copy of Texas A&M's Drawbridge up and running to protect my machines..)
Seems like only yesterday when you could dump the dns records for .mil sites, the whole of the .uk, etc. etc. (fsck me, where have the years gone?)
(Score: 2) by zocalo on Sunday February 17 2019, @02:44PM (1 child)
Maybe the Chromecast isn't fully validating everything, or maybe that since 8.8.8.8 and 8.8.4.4 are just resolvers (Google.com's four authoratative DNS servers are on the IPs 216.239.3[2468].10) they've failed to properly and fully validate the chain of trust and/or Vixie worked around that too (local copy of anchor keys?).
UNIX? They're not even circumcised! Savages!
(Score: 0) by Anonymous Coward on Sunday February 17 2019, @03:02PM
As who says that DNS traffic is actaully getting to 8.8.8.8, why not DNS-over-https? SourceFire is pushing that... weaponize http coding to bypass us, that hate tracking.
(Score: 1, Interesting) by Anonymous Coward on Sunday February 17 2019, @01:23PM (4 children)
Maybe the same way I do it, transparently redirect *all* DNS requests at my boundary firewall to my own server running dnsmasq for the cache, .internal domain name resolution, filtering/blacklisting and it then passes external name queries to (currently) djbdns running on another virtual interface to handle.
It would surprise you the number of times I've come across hard coded IP numbers being used, futzing around with hosts file entries just doesn't cut it anymore, the momsers are getting tricksy....
(Score: 1) by Tokolosh on Sunday February 17 2019, @03:14PM (3 children)
I'm not a network guru, so please explain how your boundary firewall knows what is a DNS request, and what is not? What if they are encrypted? Can DNS use only port 53? If so, why and how? What if you have IPv6 only? In summary, are there ways that DNS could circumvent your firewall and server? TIA
(Score: 2) by Whoever on Sunday February 17 2019, @05:41PM (2 children)
DNS exclusively uses port 53.
Mostly, it uses UDP, but bigger queries will use TCP.
(Score: 2, Interesting) by Tokolosh on Monday February 18 2019, @03:35AM (1 child)
What's to stop Google setting up a resolver to answer queries on port 54, and hard-coding that into a Chromecast?
(Score: 2) by Whoever on Monday February 18 2019, @04:12AM
A restrictive firewall may not allow the outgoing queries on port 54.
They might have more success with port 443 -- and there is already a standard for this: RFC 8484 [ietf.org]