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: 1, Interesting) by Anonymous Coward on Sunday February 17 2019, @01:47PM (8 children)

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

    Did anyone else look at the IETF mailing list thread and see the toolish response he received from Jared Mauch whoever that loser is.

    VIXIE: "they know exactly what they're doing, and it's not an accident.
    reporting it to their support team will waste their time and mine."

    MAUCH: "And ours as well."

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Overrated=1, Touché=1, Total=3
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 5, Interesting) by zocalo on Sunday February 17 2019, @03:07PM (7 children)

    by zocalo (302) on Sunday February 17 2019, @03:07PM (#802509)
    Mauch is another long-standing member of the IETF community, (co-)author of a couple of BGP related RFCs, and works with M3AAWG, Network Operator Groups (esp. NANOG), and RIRs like ARIN and RIPE, amongst several other places I've seen him post. I think he's currently employeed by Akamai. Definitely not a loser.

    Still, I am a bit uncertain as to why he feels Vixie's outing of Google's broken implementation (they're presumably ignoring the DNS servers pushed out when the Chromecast requests IP details via DHCP) might waste "our time". It's an RFC violation by Google (ignoring DHCP), so I don't see it as being out of place to point that out on the IEFT list, so not a waste of the list member's time. It would be a support ticket between Google and Vixie, so again, hard to see any impact on the time of any list members (unless they work for Google). Or maybe he just meant that raising it as ticket would somehow devolve into a fruitless "discussion" between Google and the IETF, which probably would be a waste of the list's time compared to just airing it and seeing what (if anything) Google do about it?
    --
    UNIX? They're not even circumcised! Savages!
    • (Score: 5, Informative) by Hyperturtle on Sunday February 17 2019, @03:54PM (2 children)

      by Hyperturtle (2824) on Sunday February 17 2019, @03:54PM (#802529)

      This ignoring DNS set in DHCP has been a problem in Android since at least 4.1 (which was my first experience with Android outside of an emulator prior to the release of any phones that ran it).

      I was infuriated that my nexus was trying to query 8.8.8.8 and 8.8.4.4 despite my having an elaborate local caching and domain blocking setup that has worked well for years. The nexus accepted the DNS assignment--and ignored it. Looking at the interface info from a rooted command prompt, it showed my DNS servers as assigned.

      Packet captures showed that google went to 8.8.8.8 and 8.8.4.4 anyway. It would *fail back* to my DNS servers only if something couldn't be resolved--like, oh, anything on my home network. The tablet by default pretty much dutifully reported the hostnames I tried to access locally, to google, despite my having tried to configure the tablet to... never query an external DNS service.

      I ended up blocking 8.8.8.8 and 8.8.4.4 on my firewall; I just drop the packets from entering the firewall on the inside interface, and if for some reason a response is coming in from externally, I have a seperate rule to drop anything from those IPs externally on my outside interface.

      I further ended up having to simply block ALL domain/dns requests from going externally.

      As it turns out, there are a lot of clever software packages that will simply ignore your DNS settings and use the application to query dns servers hosted on amazon, azure, etc. This allows such applications to pull advertisements and updates via successful name resolution from domains I may have otherwise blocked or created as empty domains or with loopbacks as the server ips.

      I ended up permitting only my DNS servers to make queries outbound; I manually, granularly, defined my server IPs as being allowed to do dns queries outbound and receive replies. I also have a couple of workstations where I do network monitoring and stuff (which either have static IPs or dhcp reservations) that I allow a few alternative DNS servers to be reached -- like 4.2.2.1, or a local ISP DNS server--in case I have problems with mine, like if I am too aggressive with domain blocking or if I am working on the servers and the lack of DNS services is causing inconveniences for people in my home... hey sometimes I have guests that have strange requirements, like my mom's AOL habits.

      Anyway, the nexus andoid os 4.x dns thing was a real shocker to me, because the #! rule in operational security when doing wifi security testing is to not reveal yourself any more than necessary--google's determination to undermine administrative preferences to send unencrypted dns queries to their servers was not pleasing. Ultimately what I ended up doing to stop that entirely was to... set a static IP on the tablet, and not include a gateway. 8.8.8.8 and 8.8.4.4 were never part of a local subnet the tablet was on, and as such, all DNS requests were prevented--in fact, any traffic off-subnet was prevented. The tablet made no efforts to talk when there was no gateway to pass it through; I have to wonder if Google will someday try to use 'common gateway IPs (on private networks) based on the subnet it detects. There's a whole lot of 192.168.0.1s and 1.1s out there acting as gateways.

      Anyway, removal of the gateway via a static config (or DHCP reservation that lacks a gateway) doesn't do jack for enforcement of proper behavior since google is doing what they want anyway, but it stopped such leakage of info to google when using the tablet as a security tool. They can't access what they can't reach. I am sure they didnt make any money off my purchase so I really have no right to complain--their hardware generally has been subsidized by the data collection, which is why a lot of it is so cheap...and tempting to play with, despite the inherent headaches like what Vixie has found.

      (I have no idea when this use google dns as a default despite dhcp and static settings started, but if its suddenly news, it must be because someone with authority behind his name was inconvenienced by it... I'd love to hear what Vixie says when he finds out what his phone and tablet are doing behind his back despite his expectations! It's a good way to feel violated when everything you set up to protect yourself is just passed through effortlessly due to google's deliberate efforts to ignore your preferences.)

      • (Score: 2, Interesting) by Anonymous Coward on Sunday February 17 2019, @06:26PM (1 child)

        by Anonymous Coward on Sunday February 17 2019, @06:26PM (#802575)

        What would prevent an android phone or tablet from multipathing traffic to the mothership over cellular instead, if you are blocking it on your wifi?

        • (Score: 2) by Hyperturtle on Monday February 18 2019, @04:20PM

          by Hyperturtle (2824) on Monday February 18 2019, @04:20PM (#803021)

          Not much; I was using a nexus 7 tablet that had the celluar option, but I had never bothered to get a SIM chip for it (not even T-Mobile's "free" 200MB per month offer they had for a while).

          As a result, it's been WLAN connected only--well, I also have USB wired ethernet connection for it, but that is sort of clunky to connect a tablet like that via a wire. It's what I'd use when scanning wirelessly and transmitting other data over the wire, though, so as to not pollute any wifi traffic or captures of traffic.

          But you bring up a good point...for any cellular/LTE device, chances are very good you're not the admin of the device nor able to influence that connection much--unless you use evil hacker tools in violation of various terms of services. You'd need to use a software firewall, or perhaps create a VPN tunnel that has filtering within it to block the google DNS connections. That is assuming the dns lookups go through the tunnel; I couldn't guess if the android OS would try to do an end-run around the VPN or not.

          you could try to install iptables or something (or if its already there, modify it) to direct specific IPs through a preferred interface, but I am not sure how it'll behave in the long term. it might give a false sense of security if an update silently reverts the behavior or just defaults it back to how google expects it.

    • (Score: 3, Interesting) by darkfeline on Sunday February 17 2019, @10:14PM (3 children)

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

      Point me to the RFC that says this is a violation. Here's my source:

      https://www.ietf.org/rfc/rfc2131.txt [ietf.org]

            DHCP allows but does not require the configuration of client
            parameters not directly related to the IP protocol. DHCP also does
            not address registration of newly configured clients with the Domain
            Name System (DNS) [12, 13].

      Let's get a few things straight: a machine is not required to use the DNS server advertised by DHCP. Hell, an application is not required to use the DNS server provided by the OS. DNS exists at the application level of the network stack. Applications are free to use whichever name resolution they want, including possibly not implementing name resolution. The OS providing name resolution functions is a library and configuration convenience.

      > Still, I am a bit uncertain as to why he feels Vixie's outing of Google's broken implementation (they're presumably ignoring the DNS servers pushed out when the Chromecast requests IP details via DHCP) might waste "our time".

      Because this is a mailing list for DNS OP discussions, not a forum for Google customer support. This is like if Linus starts ranting on the Linux dev mailing lists about how his Android phone always crashes.

      --
      Join the SDF Public Access UNIX System today!
      • (Score: 3, Insightful) by zocalo on Sunday February 17 2019, @10:53PM (2 children)

        by zocalo (302) on Sunday February 17 2019, @10:53PM (#802640)
        You're reading that wrong. It's saying that DHCP does not *have* to push out a full set of IP configuration parameters (e.g. you could omit DNS and/or default gateway), supports additional options (such as those used for configuring additional parameter on some VoIP devices), and does not automatically update DNS zones with the new hostname/IP it's just sent to the client. It is absolutely expected that when a device is told to use a given DNS and/or gateway it will use it though because there's a very good chance that it simply won't work if it doesn't if the network adminstrators have egress filtering in place. Which is exactly what happened to Vixie's Chromecast until he faked out the 8.8.8.8 and 8.8.4.4 DNS resolvers.

        You can override that locally if you want (e.g. configure a static DNS and use DHCP for the IP), but any device that gets told to use a given DNS/gateway/whatever by DHCP and ignores of its own volition is broken.
        --
        UNIX? They're not even circumcised! Savages!
        • (Score: 2) by darkfeline on Sunday February 17 2019, @11:38PM

          by darkfeline (1030) on Sunday February 17 2019, @11:38PM (#802664) Homepage

          > It is absolutely expected that when a device is told to use a given DNS and/or gateway it will use it

          Funny, I don't read the RFC as saying "The client MUST respect any non-IP related configuration pushed via DHCP". All RFCs are carefully worded, and any requirements are explicitly stated with MUST. Just because you or anyone else personally expect it to happen does not mean the standard requires it.

          Also and again, you don't seem to understand. The gateway is a part of IP configuration. DNS is not. DNS is at the application level. This is equivalent to DHCP pushing a configuration saying whether clients should use a light or dark UI theme and the OS and individual applications deciding whether or not to respect that.

          Also and again, you failed to cite the exact RFC passage that states the client MUST use any DNS advertised via DHCP.

          Also and again, you're ignoring the fact that an application is not required to use the OS name resolution. Even if we assume incorrectly that the Chromecast OS MUST use the DNS server provided via DHCP, the Chromecast service running on that device is under no obligation to use the name resolution provided by the OS.

          --
          Join the SDF Public Access UNIX System today!
        • (Score: 2) by Whoever on Monday February 18 2019, @04:25AM

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

          I think you will find that Windows has *never* fully used the DNS data that is in a DHCP reply. Windows only uses two resolvers, irrespective of how many the DHCP server to the client. I think there is other information in a dhcp reply that Windows ignores.