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

Related Stories

Paul Vixie: New TLDs a Money Grab, and a Mistake 28 comments

Speaking at the Ruxcon information security conference in Melbourne on Sunday, Vixie, a pioneer of the Internet's DNS system, said that creating the new TLDs goes against ICANN's purpose:

"ICANN is a 501(c)(3) non-profit public charity [under the California Non-profit Public Benefit Corporation Law], and their job is to serve the public, not to serve the companies... I think that until they can come up with an actual public benefit reason they should be creating more of these, they've got no cause to act," Vixie said.

"There should be no price at which you can buy '.microsoft', but there is, and that's a mistake. That indicates corruption, as far as I'm concerned."

Vixie also indicated the WHOIS privacy industry wouldn't exist were it not for criminals:

"There are plenty of folks [who] would like to say [that] for civil society purposes we need the ability for dissidents to register a domain name and complain about their own government, and not have to worry about getting their doors kicked in. Frankly, that is not a realistic scenario, and that is not the way that WHOIS privacy gets used," he said.

Vixie encouraged conference attendees to implement technologies that improve the integrity of DNS (like DNSSEC) and called for replacement of the X.509 Certificate Authority system.


Original Submission

VLC 3.0.0 Released, With Better Hardware Decoding and Support for HDR, 360-Degree Video, Chromecast 39 comments

VideoLAN has released version 3.0.0 of the VLC media player for Windows, Linux, BSD, Android, and macOS. The new version is billed as enabling hardware decoded playback of 4K, 8K, and 360-degree video (in a demonstration video, VLC 3.0.0 is shown playing 8K 48fps 360-degree video on a Samsung Galaxy S8).

3.0.0 adds support for (not exhaustive):

Linux/BSD default video output is now OpenGL, instead of Xvideo.

The 3.0.x branch of VLC will be maintained as long-term support versions and will be the last releases on Windows XP (with significant limitations), Vista, macOS 10.7, 10.8 & 10.9, iOS 7 & 8, Android 2.x, 3.x, 4.0.x & 4.1.x, and the last to run on compilers before gcc 5.0 and clang 3.4, or equivalent.

From VLC Android developer Geoffrey Métais's blog post about the release, which discusses why Chromecast support took so long to add, as well as other missing features that have now been added to the Android version:

Chromecast support is everywhere and VLC took years to get it, right, but there are plenty of good reasons for it:

First of all, VideoLAN is a nonprofit organization and not a company. There are few developers paid for making VLC, most of them do it in their free time. That's how you get VLC for free and without any ads!

Also, VLC is 100% Open Source and Chromecast SDK isn't: We had to develop our very own Chromecast stack by ourselves. This is also why there is no voice actions for VLC (except with Android Auto), [and] we cannot use Google Play Services.

Furthermore, Chromecast is not designed to play local video files: When you watch a Youtube video, your phone is just a remote controller, nothing more. Chromecast streams the video from youtube.com. That's where it becomes complicated, Chromecast only supports very few codecs number, let's say h264. Google ensures that your video is encoded in h264 format on youtube.com, so streaming is simple. With VLC, you have media of any format. So VLC has to be a http server like youtube.com, and provide the video in a Chromecast compatible format. And of course in real time, which is challenging on Android because phones are less powerful than computers.

At last, VLC was not designed to display a video on another screen. It took time to properly redesign VLC to nicely support it. The good news is we did not make a Chromecast specific support, it is generic renderers: in the next months we can add UPnP support for example, to cast on any UPnP box or TV!

Also at The Verge and Tom's Hardware.

Related: Stable Release of VLC 1.0 for Android
VLC 2.0 for Android Released
EU Offers Cash Bounties to Improve the Security of VLC Media Player
Google Won't Take Down Pirate VLC With 5M Downloads (Update: They Have Taken it Down)


Original Submission

Paul Vixie on the Benefits of Running DNS Services Locally 15 comments

Paul Vixie has written a two-page article about the benefits of running DNS locally. He goes into a brief summary of DNS' history, a description of the current situation, ennumerates four areas of loss resulting from outsourcing DNS resolution, and points the direction out of the trap of outsourcing.

Operating one's own local DNS resolution servers is one of the simplest and lowest-cost things an IT administrator can do to monitor and protect their applications, services, and users from potential risks. These risks — including surveillance capitalism, unmanageable external dependencies, attacks carried via DNS, and attacks that could be detected via DNS — have a much higher potential cost than the mitigation strategy outlined here. Additionally, the DNS resolution service is so central to every other IT-related activity that any and all IT administrators who take the time to investigate and master this technology will amplify their effectiveness and the value they bring to their enterprise.

Do the all-too-common Microsoft shops these days even have DNS these days? Decommoditizing protocols has been one of their tactics for decades against FOSS and everyone else in general.


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.
(1)
  • (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.

    • (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]

  • (Score: 3, Informative) by DavePolaschek on Sunday February 17 2019, @12:29PM (1 child)

    by DavePolaschek (6129) on Sunday February 17 2019, @12:29PM (#802473) Homepage Journal

    TFA has an ad-blocker-blocker which obscures the article. Turn off JavaScript before visiting to avoid frustration.

    • (Score: 0) by Anonymous Coward on Monday February 18 2019, @09:10AM

      by Anonymous Coward on Monday February 18 2019, @09:10AM (#802854)

      That is absolutely hilarious.
      I have gotten quite adept at killing screen blockers and overlays manually.
      There must be a way to hide ad blocking from them.

  • (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."

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

  • (Score: -1, Troll) by Anonymous Coward on Sunday February 17 2019, @03:56PM (2 children)

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

    Paul Vixie is a brown-nosing cock-sucker who sucks up to those in power and deserts his friends.

    I hear Paul Vixie was real tight with Bjorn Satdeva - suspected of burgling the USENIX HQ back in the 1990s, if I recall correctly.

    I hear Paul Vixie was real tight with Barry Shein, too - a known child molester who is forbidden by the courts to be alone with young men.

    Elephants never forget ...

    • (Score: 0) by Anonymous Coward on Sunday February 17 2019, @04:30PM

      by Anonymous Coward on Sunday February 17 2019, @04:30PM (#802532)

      I found the google intern.

    • (Score: 1, Insightful) by Anonymous Coward on Sunday February 17 2019, @06:39PM

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

      Care to provide any background on these events, or are you just throwing names out here?

  • (Score: 0) by Anonymous Coward on Sunday February 17 2019, @05:11PM (4 children)

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

    Google is turning evil, right before our eyes.

    Why would they hardcode their DNS server address? So that they can yet further monitor your activities in order to target you with advertising.

    They have sold out to the advertisers, and once that happens there is no going back.

    • (Score: 2) by Whoever on Sunday February 17 2019, @05:45PM

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

      Why would they hardcode their DNS server address?

      Because ISPs are even more evil and Google is attempting to bypass some of the ISPs' evil.

    • (Score: 2) by Rosco P. Coltrane on Sunday February 17 2019, @06:08PM

      by Rosco P. Coltrane (4757) on Sunday February 17 2019, @06:08PM (#802564)

      Dude, Google has turned evil the day they realized there's money to be made by exploiting people's personal data - that is, from day one. Their "dont do evil" motto was just sarcasm. They removed it when it was starting to be a little too obvious.

    • (Score: 2) by ilsa on Monday February 18 2019, @02:06PM

      by ilsa (6082) Subscriber Badge on Monday February 18 2019, @02:06PM (#802945)

      What do you mean "is turning"? This happened a long time ago.

    • (Score: 0) by Anonymous Coward on Monday February 18 2019, @08:01PM

      by Anonymous Coward on Monday February 18 2019, @08:01PM (#803141)

      a windows user, no doubt...

  • (Score: 2, Disagree) by exaeta on Sunday February 17 2019, @06:20PM (4 children)

    by exaeta (6957) on Sunday February 17 2019, @06:20PM (#802572) Homepage Journal
    I don't see any obligation on part of pcrogrammers to use a local dns resolver. It's kind of a bad design, tbh. I don't blame google for wanting to avoid T-Mobile, AT&T et al. intercepting dns requests and returning bogus crap.
    --
    The Government is a Bird
    • (Score: 1, Insightful) by Anonymous Coward on Sunday February 17 2019, @06:42PM

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

      ... I don't blame google for wanting to avoid T-Mobile, AT&T et al. intercepting dns requests and returning bogus crap.

      Err, they still can...the phone companies can still play silly fsckers with the traffic on their networks bound to the google servers, though I think most of them, by now, probably have agreements in place not to do such kind of things with google traffic.

    • (Score: 2) by exaeta on Sunday February 17 2019, @06:58PM

      by exaeta (6957) on Sunday February 17 2019, @06:58PM (#802586) Homepage Journal
      *programmers. I wish we could edit comments. :(
      --
      The Government is a Bird
    • (Score: 2) by zocalo on Sunday February 17 2019, @11:10PM (1 child)

      by zocalo (302) on Sunday February 17 2019, @11:10PM (#802648)
      How about if you ignore what you are told via DHCP your device might not work? Vixie seems to be only allowing outgoing DNS unless originated by his own resolver and is presumably dropping the rest on the floor via firewall egress filtering. By assuming that DNS requests to 8.8.4.4 and 8.8.8.8 would be allowed to freely traverse the firewall, regardless of what they were told by DHCP and in contravention of BCPs regarding egress filtering, it's hardly surprising that the Chromecast did not work.

      A Chromecast allowing a user to choose between his own DNS (regardless of how that is configured on the device) or letting the Chromecast use a preconfigured default of Google's DNS is one thing. Ignoring a user's request to do one thing using your own choices anyway is something else, and that is broken by design.
      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 2) by exaeta on Monday February 18 2019, @01:07AM

        by exaeta (6957) on Monday February 18 2019, @01:07AM (#802704) Homepage Journal
        Network firewalls and blocking ports are bad practice. They shouldn't be utilized, and it's your fault if you break a device by blocking traffic.
        --
        The Government is a Bird
  • (Score: 3, Interesting) by Revek on Sunday February 17 2019, @07:35PM (4 children)

    by Revek (5022) on Sunday February 17 2019, @07:35PM (#802595)

    if you use iptables redirect all port 53 to your dns. Its what I do on two park wifi systems I manage.

    --
    This page was generated by a Swarm of Roaming Elephants
    • (Score: 2) by Revek on Sunday February 17 2019, @07:37PM

      by Revek (5022) on Sunday February 17 2019, @07:37PM (#802596)

      I forgot to paste in the iptables statement but hey if you can't google it, its not my fault :P

      --
      This page was generated by a Swarm of Roaming Elephants
    • (Score: 1) by Tokolosh on Monday February 18 2019, @03:47AM (1 child)

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

      My router running FreshTomato has an option to intecept DNS port and send it to the resolver address you specify.

      • (Score: 2) by Revek on Monday February 18 2019, @08:12PM

        by Revek (5022) on Monday February 18 2019, @08:12PM (#803146)

        I didn't know they put that in there. One of the routers I use in the parks has fresh tomato on it. I just added the firewall statement and moved on.

        --
        This page was generated by a Swarm of Roaming Elephants
    • (Score: 0) by Anonymous Coward on Monday February 18 2019, @09:15AM

      by Anonymous Coward on Monday February 18 2019, @09:15AM (#802856)

      Well it Bork when a non Google answer is returned?

  • (Score: 2) by NateMich on Monday February 18 2019, @12:11AM (1 child)

    by NateMich (6662) on Monday February 18 2019, @12:11AM (#802675)

    Don't use their hardware devices. Nobody needs a Chromecast.
    Don't use their browser. Nobody needs Chrome (unless you're at work and you have shitty apps written just for Chrome).
    Or, you can ignore me and find yourself stuck with whatever Google wants.
    Have it your way.

    • (Score: 0) by Anonymous Coward on Monday February 18 2019, @08:04PM

      by Anonymous Coward on Monday February 18 2019, @08:04PM (#803144)

      exactly. you fund the enemies of humanity and then whine that they screw you too? don't be such a dumb ass whore.

(1)