Score:1

HTTPS resource record doesn't work for CNAME

cn flag

My domain is registered with Cloudflare and uses their DNS infrastructure. I'm trying to set up an HTTPS DNS record to signal browsers that my sites can be directly accessed via HTTP/3 and HTTP/2, as described in Cloudflares blog post.

Since I host multiple services, I use a wildcard CNAME for all subdomains. I don't really want to list them all, since the server doesn't have a static IP and I would need to update A/AAAA records for about 10 subdomains. Doable, but also cumbersome and error prone.

My current configuration looks like this:

nxdomain.info.      600          IN  A          XXX.XXX.XXX.XXX
nxdomain.info.      600          IN  AAAA       XXX:XXX:XXX:XXX
*.nxdomain.info.    600          IN  CNAME      nxdomain.info.
nxdomain.info.      86400        IN  HTTPS      1 . alpn="h3,h2"

The HTTPS record works perfectly fine for the root domain:

https://dns.google/query?name=nxdomain.info&rr_type=HTTPS

But it fails for subdomains:

https://dns.google/query?name=subdomain.nxdomain.info&rr_type=HTTPS

Shouldn't a CNAME cause all kinds of records to be resolved against the canonical name?

Note: i don't use any kind of proxy feature provided by Cloudflare. All entries are listed as "DNS-only".

fr flag
Can't you do `*.nxdomain.info. 600 IN HTTPS 1 . alpn="h3,h2"` instead of CNAME?
bt90 avatar
cn flag
This would only work with software which supports HTTPS records, breaking a lot of apps and probably a few browsers too
fr flag
I don't see how it is different with your CNAME approach. Assuming it works, it would break them in the same way...
bt90 avatar
cn flag
How so? The CNAME points to the root domain which has valid A/AAAA records. HTTPS records need to be explicitly queried which guarantees that clients don't break if they don't support it.
fr flag
What's stopping you from adding appropriate A/AAAA wildcards? The only thing which could be problematic (you'll have to check) is if cloudflare supports that, especially for proxied services.
fr flag
Yeah, you cannot have proxied wildcard if that's what you are after. And it doesn't seem to work anyway.
bt90 avatar
cn flag
Did you even read my initial question? The HTTPS records don't work. IP resolution works perfectly fine
fr flag
Yes, I did. I am saying that having wildcard HTTPS record along with wildcard A record on cloudflare does not work as well. So it is not a viable workaround.
Score:0
jp flag

This is what you get with a non-standard DNS resource records.

I get the same result with dig @8.8.8.8 subdomain.nxdomain.info type65 but with dig subdomain.nxdomain.info type65 I get expected results:

subdomain.nxdomain.info. 2803   IN  CNAME   nxdomain.info.
nxdomain.info.      2746    IN  TYPE65  \# 45 0001086E78646F6D61696E04696E666F00000100180268330568332D 32390568332D32380568332D3237026832
bt90 avatar
cn flag
that was also my initial theory but it seems to be Cloudflare problem: dig subdomain.nxdomain.info type65 @carl.ns.cloudflare.com
jp flag
carl.ns.cloudflare.com doesn't allow recursive queries.
bt90 avatar
cn flag
It doesn't work with Cloudflares 1.1.1.1 either
bt90 avatar
cn flag
HTTPS RR actually do resolve for CNAMEs with Google DNS: https://dns.google/query?name=subdomain.proliantnas.dedyn.io&rr_type=HTTPS That's whyi think that it might be a Cloudflare bug.
jp flag
You are probably correct that the root issue is with authoritative NS as it doesn't return even a `CNAME` itself for `type65`.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.