I too have written code that asks 8.8.8.8 and 8.8.4.4, because the DNS server I get from DHCP frequently is so brain-damaged. (SRV records, what's that?) I asked both in parallel.

On one hand it feels wrong to not ask in parallel.

On the other, $%#@%#$%!$@# the %$#%#$%^$#@%#$! packet filters that block DNS packets to everyone except the local brain-damaged resolver. Or even redirect. If Google will fight that fight I'll happily enjoy the benefits.

As someone who has had to block and redirect DNS traffic, there are reasons we do this and if you have a problem with it then you should contact the admins about it. If you're unwilling to do that, maybe you shouldn't be doing what you're trying to do at work.

Do you happen to be the admin at the meeting venue that discarded my SRV and DNSSEC lookups? What were the reasons you did this, if so?

Use the guest WiFi, that's what it's there for.

Does that have a sensibly working resolver?

In my haphazard experience, the networks that block access to UDP port 53 are more than likely to have gelded broken name servers that e.g. serve empty NXERROR results for anything but A/TXT, and receptionists that say, "uh, let me check" and then check that their browser can open the google home page. (Insert invectives here.)

I've seen be fixed. Once. One meeting I attended started with a quite broken network, but it was an IETF meeting, and the IETF tools team reconfigured the AP channel layout, the DHCP server and the caching name server at that hotel and after that it was fine.

> If Google will fight that fight I'll happily enjoy the benefits.

Evidently, they are:

https://en.wikipedia.org/wiki/DNS_over_HTTPS

https://developers.google.com/speed/public-dns/docs/dns-over...

And that's how we are going to get mandatory https proxies in networks... The arms race will continue, making the lives of everyone more difficult.

A HTTPS proxy can't rewrite the contents of your stream. If it redirects to the wrong host, the cert doesn't match.

That's fine, it is not about rewriting stream, but about not allowing to connect certain hosts.

I will never install that cert, so it stops there for me. IT security theater be damned.

> On the other, $%#@%#$%!$@# the %$#%#$%^$#@%#$! packet filters that block DNS packets to everyone except the local brain-damaged resolver.

Curse it all you want, but forcing all DNS lookups to be resolved by a particular server is often an important security measure.

Lolwut? Seriously, what serious exploit would be stopped by this.

To me its a reasonable trade off, the probability the google DNS server goes down is low and the amount of people who purposely block google dns is also low.

Sure, but don't we reserve the right to run our own split-horizon DNS servers and point fqdn's our devices want to resolve to anything we desire?

Don't like it? Use TLS and verify certificates.

I wonder why they aren't just using TLS and pinning certificates? I suppose they probably do, but furthermore want to ensure that they control the resolution of other services (e.g. Netflix) for the device.

Sure, if the product doesn't fit your need then either build your own chromecast or use different product. I personally do not want to build my own so I'm perfectly okay with the trade off.

My company blocks google dns.