1

Context

Operating systems (Windows, MacOS, Linux, iOS, Android), but also browsers (Firefox, Brave, Edge, etc.) have ways to use DOH.

DNS-over-HTTPS works by the system talking to an endpoint like 'https://cloudflare-dns.com/dns-query'.

Let's say the client is in a network that restricts DNS traffic over port 53 udp. Also the router does not serve as a DNS-resolver for the client. (The network enforces using DOH (or DOT).)

Catch22?

How will the client resolve the first hostname 'cloudflare-dns.com' to set-up the DOH-DNS-querying connection?

It seems that out of the box, DOH communication always requires at least one DNS query over UDP port 53. That is if you use the traditional hostname-based endpoints.

Or is this statement incorrect, are DOH provider endpoint IPs pre-loaded in Windows 11? I can see their hostname is preloaded, but does it actually know where to connect to if it cannot query this hostname itself before DOH?

For Cloudflare I could remember its IP-based endpoint 'https://1.1.1.1/dns-query' and perhaps for Quad9 as well, but for NextDNS and other providers the IPs are not always so easy to remember and I would need internet to lookup their IPs to make those providers work.

Questions

Q1: Is DNS-over-HTTPS(DOH) depended on at least one regular DNS query via UDP port 53 to function? To be able to resolve the DOH server's hostname itself to connect to it?

Q2: If so, in restricted networks with no port 53 fallback or other local DNS-resolver, is using IP-included DOH-endpoint-address(es) (like https://1.1.1.1/dns-query) always required for connectivity to work all the time to avoid the catch22? (Like with hostname-included form (https://cloudflare-dns.com/dns-query)?)

Q3: HTTPS relies on PKI infrastructure and certificates that have a common name (or SAN) like 'cloudflare-dns.com'. Am I breaking a validation step in the chain by using IP-included endpoints instead of hostname-included endpoints?

Q4: This table could be a follow-up question if operating systems have different behaviours.

Client Sensitive to DOH-Catch22 Comment (why not?)
MacOS (cloudflared) ?
Windows native ?
Firefox on MacOS ?
Edge on MacOS ?
Firefox on Windows ?
Edge on Windows ?
iOS mobileconfig ?
Android native ?
Linux-based via Cloudflared ?
Linux-based via Stubby ?
A71
  • 560

1 Answers1

1

Q1: Is DNS-over-HTTPS(DOH) dependent on at least one regular DNS query via UDP port 53 to function?

This is true for hostname-based endpoints, but not when using an IP-based endpoint like cloudflare's 1.1.1.1 (or a local resolver like a hosts file).

Q2: in restricted networks with no port 53 fallback or other local DNS-resolver, is using IP-included DOH-endpoint-address(es) always required for connectivity?

Yes, the client needs to resolve an endpoint name like one.one.one.one to an IP somehow. It can be cached or hard-coded in the DoH client, but unusual.

Q3: Am I breaking a validation step in the chain by using IP-included endpoints instead of hostname-included endpoints?

Not necessarily. Certificates can use an IP address as a valid SAN - see the Cloudflare certificate at https://1.1.1.1/ for example. However, if the DoH client also does CRL/OCSP checking, then that info should be distributed to IP-based hosts as well (Cloudflare does not). If that's not allowed, this can cause a deadlock.

Q4: The general behavior is the same for any DoH service. Take a look through some default providers in different applications here: https://en.wikipedia.org/wiki/DNS_over_HTTPS

Cpt.Whale
  • 10,914