1.1.1.1 (and all of its associated hostnames) only partially supports DNS-over-HTTP/3 because it does not provide the Alt-Svc h3 header which is required for fully compliant clients (like dnscrypt-proxy) to use it. Certainly, one could modify the code to ignore the header, but that would not be standards compliant.
Google DNS does support the Alt-Svc header therefore it works fine with standards compliant DNS clients.
As a fix was promised 7 months ago in the original thread above, can we please have an update as to when this will be fixed for 1.1.1.1 ? (and 1.1.1.2 / 1.1.1.3 as well).
Thanks!
You can reproduce this issue with the commands in the following post:
But it may be some kind of A/B testing, because I’ve seen it show up and disappear periodically over the past couple months. My latest dnscrypt-proxy does not appear to be using HTTP3 with Cloudflare-dns[.]com, even though I can see Alt-Svc offered when I visit it. Not entirely sure what’s going on there, maybe they’re only offering to specific User-Agents? The above was captured using “Go-http-client/1.1” UA.
I believe you need to make the actual DNS query otherwise it’s just a standard web request (which has always returned Alt-Svc since they implemented it).
Default (the Alt-Svc cache never populates): curl -v -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=cloudflare.com" --alt-svc altcache.txt
Forcing HTTP/3 (works, with a suitable build of curl): curl -v -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=cloudflare.com" --http3
For comparison, swap 1.1.1.1/dns-query for dns.google/resolve and you’ll see the Alt-Svc headers returned and cached.
Hello,
As per our documentation, we currently only support HTTP and HTTP/2:
Our Engineering and Product team are working on adding the support for HTTP/3.
That being said, here are some more details from our Engineering team:
Per Section 3 of RFC 9114, servers MAY listen on any UDP port for HTTP/3. The use of Alt-Svc to advertise the availability of HTTP/3 at a server is common but it is not a strict requirement. Other mechanisms of discovery are also permitted, such as the HTTPS DNS resource record type alpn parameter, or the ALTSVC frame. RFC 9114 also permits clients to attempt QUIC and HTTP/3 connections directly without any form of advertisement. This is also common, with tools providing options or configuration to attempt HTTP/3 directly - the trade off being that the attempt might fail and a fallback is required. This is a latency tradeoff for clients to decide upon.
Alt-Svc is commonly used and these endpoints should support sending it. However, in the long term Alt-Svc has problems that have been acknowledged by the IETF HTTP WG and it is designing a new solution. The best option for discovery today is most likely to be the HTTPS DNS resource record type, which minimises latency and reduces the chance of stale information caching.
Actually, DNS-over-HTTP/3 is already supported in 1.1.1.1 as stated 7 months ago by Cloudflare staff and Google, and it works with https-dns-proxy (with new curl builds) and also dnscrypt-proxy with a small modification in the code to force HTTP/3 or remove the Alt-Svc check, but as mentioned it’s more preferable to have a fallback. And HTTP/3 is even mentioned in your own 1.1.1.1 API documentation.
So the missing part is the Alt-Svc. I understand that the mechanisms of discovery are not fully established, but until they are, Alt-Svc in 1.1.1.1 is a good option for now.
The HTTPS SVCB DNS record method is certainly better but even Google DNS doesn’t currently serve these records, yet they still support HTTP/3 and Alt-Svc. And even Cloudflare’s own family.cloudflare-dns.com and security.cloudflare-dns.com don’t serve these records either so they cannot use this “best option for discovery today”.
Hi, like you mentioned before, DoH does currently support HTTP/3, but the alt-svc is not yet present on the response. We have an internal ticket for adding the alt-svc header to the responses but no timeline for when that will be.
