3 ms·

>My Chromecast went through massive amount of trouble to use Google's DNS servers No it didn't, it just queried 8.8.8.8 instead of whatever DNS server your DHC

>My Chromecast went through massive amount of trouble to use Google's DNS servers No it didn't, it just queried 8.8.8.8 instead of whatever DNS server your DHCP configuration told it to use. Putting "nameserver 8.8.8.8" in /etc/resolv.conf and marking it read-only would have the same effect. Doesn't look like much trouble does it?

adsadadsad 8y ago
Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS. You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
- pexaizix 8y ago
  Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times. A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf
  - adsadadsad 8y ago
    Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)
- josteink 8y ago
  > bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS. This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works. In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness. Good luck trying to block their attempts to spy and report on you now! DNS over HTTPS is going to cause a shitload more problems than it solves.
  - adsadadsad 8y ago
    I'm not sure Im following why is HTTPS going to cause a shitload more problems?
    - josteink 8y ago
      Not HTTPS. DNS over HTTPS. If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.
      - joshstrange 8y ago
        If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.
        josteink 8y ago
        By network operator I mean me, the person controlling my own local network. Also: ISPs behave nice almost everywhere in the world where there is proper regulation. What you have in the US is not a technical problem. It’s a regulatory one.
adsadadsad 8y ago
Oh and in the chromecast (non-ultra anyway), chromecast attempts to ignore any DNS servers supplied by your DHCP - hence why the watch-TV VPN's smartdns fails. Good luck rooting your Chromecast and chattr +i it's /etc/resolv.conf
- SmellyGeekBoy 8y ago
  How does a device "attempt to ignore" DNS servers supplied by DHCP? Like all devices connected to a network it must either use DHCP to get your DNS server or use a hardcoded value, it's not some kind of conspiracy.
  - adsadadsad 8y ago
    "Attempt to ignore" Great question. So it uses hardcoded values of 8.8.8.8/8.8.4.4, unless it can't contact them by testing to resolve connectivity-test.google.com (or something like that), if it can't then it falls back to the DNS servers provided by your DHCP server/router. So to use smartdns with chromecast you have to both set your router to provide the SmartDNS servers and also blackhole 8.8.8.8/8.8.4.4 on your shitty ISP router (iirc static routes) - conspiracy? - i'll leave that to you? (the smartdns route is necessary since chromecast don't have their own VPN facility)
apostacy 8y ago
Is it reasonable to fail if you can't access a specific DNS server? This is unexpected behavior. And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem! Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671 https://news.ycombinator.com/item?id=19170671
- kurtisc 8y ago
  If it's a hot-fix for ISP troubles then I can imagine it being overlooked. Nobody working at Google would ever fail to connect to 8.8.8.8 while developing it.

adsadadsad 8y ago

Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS. You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?

pexaizix 8y ago
Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times. A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf
- adsadadsad 8y ago
  Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)
josteink 8y ago
> bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS. This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works. In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness. Good luck trying to block their attempts to spy and report on you now! DNS over HTTPS is going to cause a shitload more problems than it solves.
- adsadadsad 8y ago
  I'm not sure Im following why is HTTPS going to cause a shitload more problems?
  - josteink 8y ago
    Not HTTPS. DNS over HTTPS. If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.
    - joshstrange 8y ago
      If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.
      - josteink 8y ago
        By network operator I mean me, the person controlling my own local network. Also: ISPs behave nice almost everywhere in the world where there is proper regulation. What you have in the US is not a technical problem. It’s a regulatory one.

adsadadsad 8y ago

Oh and in the chromecast (non-ultra anyway), chromecast attempts to ignore any DNS servers supplied by your DHCP - hence why the watch-TV VPN's smartdns fails. Good luck rooting your Chromecast and chattr +i it's /etc/resolv.conf

SmellyGeekBoy 8y ago
How does a device "attempt to ignore" DNS servers supplied by DHCP? Like all devices connected to a network it must either use DHCP to get your DNS server or use a hardcoded value, it's not some kind of conspiracy.
- adsadadsad 8y ago
  "Attempt to ignore" Great question. So it uses hardcoded values of 8.8.8.8/8.8.4.4, unless it can't contact them by testing to resolve connectivity-test.google.com (or something like that), if it can't then it falls back to the DNS servers provided by your DHCP server/router. So to use smartdns with chromecast you have to both set your router to provide the SmartDNS servers and also blackhole 8.8.8.8/8.8.4.4 on your shitty ISP router (iirc static routes) - conspiracy? - i'll leave that to you? (the smartdns route is necessary since chromecast don't have their own VPN facility)

apostacy 8y ago

Is it reasonable to fail if you can't access a specific DNS server? This is unexpected behavior. And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem! Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671 https://news.ycombinator.com/item?id=19170671

kurtisc 8y ago
If it's a hot-fix for ISP troubles then I can imagine it being overlooked. Nobody working at Google would ever fail to connect to 8.8.8.8 while developing it.