6 ms·

Unless you want your own dns server used at all times.

shawnz 8y ago
But why would you care about that? You're already connecting to Google's service, YouTube, so what does it change to use Google's DNS to resolve it? What is the circumstance where you'd care about not using Google's DNS but then connect to a Google service anyway? If Chromecasts allowed arbitrary web browsing, I would maybe see your point -- but they don't.
- sofaofthedamned 8y ago
  Not just Google - when you cast you handoff a URL to the CC to stream from - this could be from Netflix, or anywhere really. 8.8.8.8 as a brute-force backup I can understand, but by default it should be taking the network DHCP settings.
  - fixermark 8y ago
    That default, sadly, would basically guarantee the thing doesn't work for all too many users. And as a consumer electronics product (especially in the sub-$50 price-range), the market-smart thing to do is configure the defaults to work in the saddle-point of worst-case and common scenario (i.e. badly-configured local router talking to a standards-hostile ISP's DHCP configurations).
    - pdkl95 8y ago
      The proper thing to do is to use the DNS settings the DHCP server provided and testing those settings by providing a server the device can lookup and connect to (with TLS). If the server proved it's authenticity, the DNS settings work. (some devices might cache this result, others might do this during startup) If an error occurs or a reasonably short timeout expires, the device can: if it has UI the user will see, it can report the problem to the user and ask if it's ok to try a common fix (which can be explained in detail in an optional "[technical details]" popup). If the user approves, then retry with the hardcoded DNS server (or any other workaround). If the device doesn't have a UI that could realistically ask this type of question, automatically trying the fix when the DNS test fails might be appropriate. TL;DR - don't make assumptions about the user's situation, even if you think it is "market-smart". Test for the required behavior and fail-safely by enabling the common workarounds.
      - fixermark 8y ago
        > it can report the problem to the user How? And what should the user do with that information? This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.
        pdkl95 8y ago
        > This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care. The only technical data I suggested showing the user was an optional "technical details" popup, for the rare cases when someone (perhaps you) actually was interested in that information. > How? Iff there is a useful UI, the same way they show anything to the user. I suggested automatically failing over to the hardcoded DNS server (or similar workarounds) automatically. (If the device is literally a lightbulb and the only "UI" is if the lightbulb is on or off, user interaction doesn't make sense; just failover. > And what should the user do with that information? At a minimum, the are informed that something about their network required using a workaround. However, you seem to be missing the point: the minimal amount of user interaction I'm suggesting isn't (primarily) about informing the user. It's about asking permission to use their network contrary to how their network asked to be used. You are a guest on their network.. (if the DHCP server didn't provide a DNS serer, then there is no problem; just use a known server) More importantly, I'm mostly talking about testing and failing over to a the builtin DNS server, instead of simply assuming it's needed in "some" cases and turning it on for everyone. This shouldn't be difficult. The DHCP already happened, do the DNS lookup and check a special URL over TLS. If it fails or times out change the DNS to Cloudflare or Google's service and retry.
        fixermark 8y ago
        That seems to add a lot of logic and interaction complexity to work around a problem that is only a problem for people who already have the technical skill to remap 8.8.8.8 to their preferred DNS server anyway.
      - shawnz 8y ago
        > don't make assumptions about the user's situation Using 8.8.8.8 is exactly the opposite of an assumption. It always works in any config, that's the point. EDIT: Besides, obviously, the OP's extremely unusual config, where he is effectively just blocking the service with his firewall. Why isn't he outraged about having to unblock all of YouTube's other IPs? What's special about 8.8.8.8?
    - josteink 8y ago
      > That default, sadly, would basically guarantee the thing doesn't work for all too many users. Bold claim. Citation needed.
- syn0byte 8y ago
  CDN and routing optimization ala 'ECS'. Also ISPs that inject or screw with DNS queries. Its easier and more importantly cheaper to get all the same metrics and data from other sources rather than DNS. (And you already consented for those other data sources.) I don't trust they aren't evil, they are. I trust they are also smart.
- driverdan 8y ago
  > But why would you care about that? The reason doesn't matter. We should be in control of our own networks. Google shouldn't be deciding for us.
  - shawnz 8y ago
    Would you say that Google is "controlling your network" if they just hard-coded the IP for YouTube? This is effectively the same but with one layer of indirection in between. What's the difference?
  - fixermark 8y ago
    You are in control of your own network. Map 8.8.8.8 to the machine of your choosing.
    - dingaling 8y ago
      What if my network is IPv6 only?
      - shawnz 8y ago
        The fact that the device requires IPv4 is a much different complaint than anything to do with the use of the DNS protocol. What if YouTube were just IPv4 only? Then you'd be in the same situation no matter what DNS server you are using.
      - kllrnohj 8y ago
        Then DHCP isn't even used/required and this is all moot as clients are fully allowed (and even expected) to self-configure, including DNS if they want. Heck, DNS advertisement via IPv6-RA is still only even a proposed standard: https://tools.ietf.org/html/rfc6106 https://tools.ietf.org/html/rfc6106 it hasn't been ratified yet, and support isn't widespread.
    - pixl97 8y ago
      And when the next update uses DNS over TLS with cert pinning?
- tfehring 8y ago
  One reason to care is that https://pi-hole.net https://pi-hole.net is DNS-based.
  - alias_neo 8y ago
    This was how I found out actually, see my other comment for more detail, but yes, this is one very good reason we would want control over our DNS.
- Bartweiss 8y ago
  Perhaps you live in Turkey and Google Public DNS is blocked? I agree that on a privacy level, hiding DNS requests from Google when your Google Chromecast is calling Youtube seems like closing the stable door after the horse is gone. But there are reasons other than privacy that relying on Google's DNS might go wrong; it can be blocked (or trigger suspicion) by a government, ISPs have occasionally broken their routing to 8.8.8.8 specifically, and Google DNS itself has even had (very rare) outages. None of those issues are enormously common, except perhaps Turkey's censorship, but they're all totally avoidable. Using 8.8.8.8 as a default and failing over to the user's DNS if necessary seems to be strictly better than this approach from a consumer viewpoint.
  - shawnz 8y ago
    These are good points, agreed. Thank you
  - sowbug 8y ago
    Chromecast isn't sold in Turkey. That fact doesn't invalidate your general point. But pragmatism easily wins when balancing all the real-world craziness of captive portals, ISP DNS hacks, and creative name-resolution optimizations against "but it could be grey-marketed in Turkey." This is especially true for a narrow-purpose consumer-entertainment appliance that already depends on other services provided by its manufacturer. https://support.google.com/store/answer/2462844 https://support.google.com/store/answer/2462844
fixermark 8y ago
If you're savvy enough to configure your own DNS server, you're probably savvy enough to modify ip table resolution.

But why would you care about that? You're already connecting to Google's service, YouTube, so what does it change to use Google's DNS to resolve it? What is the circumstance where you'd care about not using Google's DNS but then connect to a Google service anyway? If Chromecasts allowed arbitrary web browsing, I would maybe see your point -- but they don't.

sofaofthedamned 8y ago
Not just Google - when you cast you handoff a URL to the CC to stream from - this could be from Netflix, or anywhere really. 8.8.8.8 as a brute-force backup I can understand, but by default it should be taking the network DHCP settings.
- fixermark 8y ago
  That default, sadly, would basically guarantee the thing doesn't work for all too many users. And as a consumer electronics product (especially in the sub-$50 price-range), the market-smart thing to do is configure the defaults to work in the saddle-point of worst-case and common scenario (i.e. badly-configured local router talking to a standards-hostile ISP's DHCP configurations).
  - pdkl95 8y ago
    The proper thing to do is to use the DNS settings the DHCP server provided and testing those settings by providing a server the device can lookup and connect to (with TLS). If the server proved it's authenticity, the DNS settings work. (some devices might cache this result, others might do this during startup) If an error occurs or a reasonably short timeout expires, the device can: if it has UI the user will see, it can report the problem to the user and ask if it's ok to try a common fix (which can be explained in detail in an optional "[technical details]" popup). If the user approves, then retry with the hardcoded DNS server (or any other workaround). If the device doesn't have a UI that could realistically ask this type of question, automatically trying the fix when the DNS test fails might be appropriate. TL;DR - don't make assumptions about the user's situation, even if you think it is "market-smart". Test for the required behavior and fail-safely by enabling the common workarounds.
    - fixermark 8y ago
      > it can report the problem to the user How? And what should the user do with that information? This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.
      - pdkl95 8y ago
        > This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care. The only technical data I suggested showing the user was an optional "technical details" popup, for the rare cases when someone (perhaps you) actually was interested in that information. > How? Iff there is a useful UI, the same way they show anything to the user. I suggested automatically failing over to the hardcoded DNS server (or similar workarounds) automatically. (If the device is literally a lightbulb and the only "UI" is if the lightbulb is on or off, user interaction doesn't make sense; just failover. > And what should the user do with that information? At a minimum, the are informed that something about their network required using a workaround. However, you seem to be missing the point: the minimal amount of user interaction I'm suggesting isn't (primarily) about informing the user. It's about asking permission to use their network contrary to how their network asked to be used. You are a guest on their network.. (if the DHCP server didn't provide a DNS serer, then there is no problem; just use a known server) More importantly, I'm mostly talking about testing and failing over to a the builtin DNS server, instead of simply assuming it's needed in "some" cases and turning it on for everyone. This shouldn't be difficult. The DHCP already happened, do the DNS lookup and check a special URL over TLS. If it fails or times out change the DNS to Cloudflare or Google's service and retry.
        fixermark 8y ago
        That seems to add a lot of logic and interaction complexity to work around a problem that is only a problem for people who already have the technical skill to remap 8.8.8.8 to their preferred DNS server anyway.
    - shawnz 8y ago
      > don't make assumptions about the user's situation Using 8.8.8.8 is exactly the opposite of an assumption. It always works in any config, that's the point. EDIT: Besides, obviously, the OP's extremely unusual config, where he is effectively just blocking the service with his firewall. Why isn't he outraged about having to unblock all of YouTube's other IPs? What's special about 8.8.8.8?
  - josteink 8y ago
    > That default, sadly, would basically guarantee the thing doesn't work for all too many users. Bold claim. Citation needed.
syn0byte 8y ago
CDN and routing optimization ala 'ECS'. Also ISPs that inject or screw with DNS queries. Its easier and more importantly cheaper to get all the same metrics and data from other sources rather than DNS. (And you already consented for those other data sources.) I don't trust they aren't evil, they are. I trust they are also smart.
driverdan 8y ago
> But why would you care about that? The reason doesn't matter. We should be in control of our own networks. Google shouldn't be deciding for us.
- shawnz 8y ago
  Would you say that Google is "controlling your network" if they just hard-coded the IP for YouTube? This is effectively the same but with one layer of indirection in between. What's the difference?
- fixermark 8y ago
  You are in control of your own network. Map 8.8.8.8 to the machine of your choosing.
  - dingaling 8y ago
    What if my network is IPv6 only?
    - shawnz 8y ago
      The fact that the device requires IPv4 is a much different complaint than anything to do with the use of the DNS protocol. What if YouTube were just IPv4 only? Then you'd be in the same situation no matter what DNS server you are using.
    - kllrnohj 8y ago
      Then DHCP isn't even used/required and this is all moot as clients are fully allowed (and even expected) to self-configure, including DNS if they want. Heck, DNS advertisement via IPv6-RA is still only even a proposed standard: https://tools.ietf.org/html/rfc6106 https://tools.ietf.org/html/rfc6106 it hasn't been ratified yet, and support isn't widespread.
  - pixl97 8y ago
    And when the next update uses DNS over TLS with cert pinning?
tfehring 8y ago
One reason to care is that https://pi-hole.net https://pi-hole.net is DNS-based.
- alias_neo 8y ago
  This was how I found out actually, see my other comment for more detail, but yes, this is one very good reason we would want control over our DNS.
Bartweiss 8y ago
Perhaps you live in Turkey and Google Public DNS is blocked? I agree that on a privacy level, hiding DNS requests from Google when your Google Chromecast is calling Youtube seems like closing the stable door after the horse is gone. But there are reasons other than privacy that relying on Google's DNS might go wrong; it can be blocked (or trigger suspicion) by a government, ISPs have occasionally broken their routing to 8.8.8.8 specifically, and Google DNS itself has even had (very rare) outages. None of those issues are enormously common, except perhaps Turkey's censorship, but they're all totally avoidable. Using 8.8.8.8 as a default and failing over to the user's DNS if necessary seems to be strictly better than this approach from a consumer viewpoint.
- shawnz 8y ago
  These are good points, agreed. Thank you
- sowbug 8y ago
  Chromecast isn't sold in Turkey. That fact doesn't invalidate your general point. But pragmatism easily wins when balancing all the real-world craziness of captive portals, ISP DNS hacks, and creative name-resolution optimizations against "but it could be grey-marketed in Turkey." This is especially true for a narrow-purpose consumer-entertainment appliance that already depends on other services provided by its manufacturer. https://support.google.com/store/answer/2462844 https://support.google.com/store/answer/2462844

fixermark 8y ago

If you're savvy enough to configure your own DNS server, you're probably savvy enough to modify ip table resolution.