Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday February 17 2019, @09:12AM   Printer-friendly
from the pegging-the-bogosity-meter dept.

'Google, this is bogus as hell' — one of the fathers of the internet blasts Google for how Chromecast behaves on his home network

"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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Funny) by Runaway1956 on Sunday February 17 2019, @09:19AM (18 children)

    by Runaway1956 (2926) Subscriber Badge on Sunday February 17 2019, @09:19AM (#802435) Journal

    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.

    Starting Score:    1  point
    Moderation   +1  
       Funny=1, Total=1
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 4, Informative) by driverless on Sunday February 17 2019, @09:28AM (6 children)

    by driverless (4770) on Sunday February 17 2019, @09:28AM (#802439)

    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)

      by Anonymous Coward on Sunday February 17 2019, @10:11AM (#802451)

      At least the mostly-miss deployment of DNSSEC has one good thing going for it...

      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)

        by driverless (4770) on Sunday February 17 2019, @11:03AM (#802460)

        At least the mostly-miss deployment of DNSSEC has one good thing going for it...

        Maybe you just don't know what DNSSEC is suppose to do?

        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)

          by Anonymous Coward on Sunday February 17 2019, @11:19AM (#802466)

          Maybe you're talking to a DNSSEC RFC author.

          Your move.

          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)

            by zocalo (302) on Sunday February 17 2019, @01:22PM (#802483)
            You're still missing the point. If DNSSec were fully deployed and enforced from root down to every last resolver then it definitely wouldn't be possible to MITM DNS, at least not without a lot of additional hackery to fix the certs. OP's sarcastic comment was about the poor adoption levels of DNSSec being a good thing in this instance because (presumably) it allowed Vixie to MITM DNS without too many problems.

            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)

              by Anonymous Coward on Sunday February 17 2019, @05:12PM (#802541)

              You're still missing the point. If DNSSec were fully deployed and enforced from root down to every last resolver then it definitely wouldn't be possible to MITM DNS, at least not without a lot of additional hackery to fix the certs. OP's sarcastic comment was about the poor adoption levels of DNSSec being a good thing in this instance because (presumably) it allowed Vixie to MITM DNS without too many problems.

              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

                by darkfeline (1030) on Sunday February 17 2019, @10:04PM (#802628) Homepage

                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)

    by Anonymous Coward on Sunday February 17 2019, @09:37AM (#802440)

    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)

      by Anonymous Coward on Sunday February 17 2019, @12:02PM (#802470)

      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)

        by opinionated_science (4031) on Sunday February 17 2019, @03:20PM (#802519)

        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

          by Anonymous Coward on Sunday February 17 2019, @05:03PM (#802539)

          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)

      by zocalo (302) on Sunday February 17 2019, @02:44PM (#802502)
      That's what I'm not quite getting on this. This (theoretically) isn't just swapping resolvers as you suggest, which would be fine, e.g. if RandomVendor's product requested a resolution of RandomVendor's domain, then there's absolutely no difference between whether that gets resolved by Google's DNS resolver or A.N.Other DNS resolver - the DNSSec validation would be passed down the chain and all would be well. Here though, we're dealing with a Google product, querying (presumably) a Google domain/in-addr.arpa, and (presumably) expecting to use a Google DNS server to do it. At some point in that process Google's implementation of DNSSec is failing to ensure the validity of the query and response, e.g. it's at least partly broken, which makes me wonder if you might not be able to spoof replies to the Chromecast as well. Probably not, since DNSSec would still validate the queries regardless, but the devil would be in the details of the Chromecast's implemenation.

      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

        by Anonymous Coward on Sunday February 17 2019, @03:02PM (#802507)

        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)

    by Anonymous Coward on Sunday February 17 2019, @01:23PM (#802484)

    How did he convince the device to use his own resolver? I suppose a HOSTS file entry would do

    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)

      by Tokolosh (585) on Sunday February 17 2019, @03:14PM (#802513)

      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)

        by Whoever (4524) on Sunday February 17 2019, @05:41PM (#802550) Journal

        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)

          by Tokolosh (585) on Monday February 18 2019, @03:35AM (#802749)

          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

            by Whoever (4524) on Monday February 18 2019, @04:12AM (#802761) Journal

            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]