[bluejekyll]

I am very conflicted about DNS-over-HTTPS vs. DNS-over-TLS.

Most of DNS-over-HTTPS' interesting use-cases start coming into play when you're using the same HTTPS session as the one being used to serve the site you're visiting. Otherwise, DNS-over-TLS is sufficient for the same level of privacy.

At that point though, DNS-over-HTTPS has a provenance issue that I don't fully grok how we're going to avoid. What I mean by that: if the site you're visiting supports DNS-over-HTTPS, where requests to that site for DNS records are requested, what happens when they decide to issue custom responses to DNS requests that ignore or supplement actual data in a zone? Won't that lead to a bifurcation of the DNS network, where web-sites can start issuing custom response to DNS queries?

Cloudflare, and Quad9, both offer DNS-over-TLS, this will be preferable for non-HTTP use-cases. Some of the points in the article imply that DNS when using DNS-over-HTTPS can't be used for tracking you, but really that just means you're passing that trust to Cloudflare, Quad9, or Google. I suppose the choice is open to you at that point.

[jchw]

I'm not sure I understand.

I was under the impression that DNS-over-HTTPS was nothing more than just an alternative DNS protocol just like DNS-over-TLS, where you perform an HTTPS request in order to query for a DNS name, and that DNS-over-TLS was just plain old DNS wrapped in TLS.

You seem to be implying that DNS-over-HTTPS would enable sites themselves to deliver DNS records. I don't see how that is possible, because connecting to HTTPS with a hostname requires resolving a DNS record. Am I misunderstanding?

[bluejekyll]

You are correct for the initial request. I've seen many arguing for taking this to another level of actually sending DNS requests over the same HTTPS session being used with a site the browser is currently connected to.

[jchw]

Is this standardized/drafted? I am curious how one might implement this.

[bluejekyll]

See this thread with one of the authors of the RFC: https://news.ycombinator.com/item?id=16728600

[patrickmcmanus]

Everybody is right in this thread :)

First, just to avoid confusion, the post linked to this HN article is just about the classic recursive resolver model. That's the scope of what is being experimented with actively.

Second, the notion of resolverless dns (where dns records are obtained from somewhere other than your recursive resolver) is indeed something DoH contemplates but does not yet allow. That's because issues around tracking, correctness, and attacks haven't been fully explored. So unsolicited DNS is interesting but its not something any browser would accept yet.

There are some other opinions on how HTTPS matches the needs of DNS here: https://bitsup.blogspot.com/2018/05/the-benefits-of-https-fo...

[Lennie]

Also notice how the plan is to push not only DNS entries but also TLS certificates:

"Right now, people are really keen to get HTTP/2 “out the door,” so a few more advanced (and experimental) features have been left out, such as pushing TLS certificates and DNS entries to the client — both to improve performance. HTTP/3 might include these, if experiments go well."

https://www.mnot.net/blog/2014/01/30/http2_expectations

Some of those things could be used for bootstrapping SNI encryption as well:

https://www.ietf.org/mail-archive/web/tls/current/msg17474.h...