Hacker News Reader

Comment by eridius | Hacker News Reader

I find it somewhat amusing that in order to use DNS-over-HTTPS you must first resolve a domain using "normal" DNS (dns.google.com). You'd think they'd go ahead and publicly advertise a static IP for that so you can use it without relying on normal DNS.

View on HN

But that is a bit harder to spoof. Suppose someone hijacks your plain text DNS to take over "dns.google.com". Their fake site will not have the right SSL keys, so your DNS-over-HTTPS client will reject it.

The certificate has to match, so I don't think there would be a problem.

Assuming none of your CAs have been compromised.

Why would it accept any old CA for a property of Google?

Browsers do this by default, unfortunately.

Not Chrome, since 2011: https://www.imperialviolet.org/2011/05/04/pinning.html

Why do people keep linking to posts from 2011? That is wholly irrelevant... not only is key pinning not done that way now, we have a standard for this.

https://www.rfc-editor.org/rfc/rfc7469.txt

And it's implemented by most browser vendors... just not Microsoft, of course.

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

> Why do people keep linking to posts from 2011?

Because it was an accurate response to the question to point out that Chrome hasn't done it for five years?

Google's certificates are statically pinned in at least Chrome and Firefox.

https://www.imperialviolet.org/2011/05/04/pinning.html

https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...

Those links are incredibly outdated, in internet time.

https://tools.ietf.org/html/rfc7469

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

https://bugzilla.mozilla.org/show_bug.cgi?id=787133

https://developer.mozilla.org/en-US/docs/Web/Security/Public...

Independent of HPKP Chrome still does 2011-style static pinning AFAIK and just by looking at HTTP headers I don't think google.com even uses HPKP. Unlike HPKP which is trust-on-first-use, static pinning is enforced from the very start so if you have the ability to statically pin in the client (as you would if you're a browser vendor or distributing your own mobile app) you probably should.

And then there is this recent discussion: https://news.ycombinator.com/item?id=12434585

I don't use either of those as http clients in my idiotic hobby projects that lookup DNS over TLS/HTTP.

DNS-over-HTTPS resolvers aren't browsers, in any case.

No, but the service seems to be (at least partly) targeted at "web-based applications", so the https clients would be browsers. Which would in turn mean the resolver would be using the browser's pinned certificates.

If you're not trusting CAs, there's not much point to DNS over HTTPS, is there? Might as well be DNS over HTTP. Or just DNS.

To expand on this, there would be three advantages, but none have to do with CA trust: (1) Clients implementations may be slightly simpler, since they have to handle one less protocol. (2) The initial DNS would be removed altogether as a possible source of error, rather than a detectable possible source of error. (3) Some marginal additional privacy. But reverse DNS means not really.

I've been playing with some code running as a resolver on my Mac. I had to seed it with some of the google IP addresses to resolve https://dns.google.com to get it going.

Agreed, an anycast IP should be provided just like that of their resolvers.

yeah would make sense i guess if they used another ip address in their 8.8.8.8 like range and offer it directly on ip.

Reply on news.ycombinator.com