1

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".

8
  • Can't you do *.nxdomain.info. 600 IN HTTPS 1 . alpn="h3,h2" instead of CNAME?
    – Tomek
    Jan 2 at 17:36
  • This would only work with software which supports HTTPS records, breaking a lot of apps and probably a few browsers too
    – bt90
    Jan 2 at 18:35
  • I don't see how it is different with your CNAME approach. Assuming it works, it would break them in the same way...
    – Tomek
    Jan 2 at 18:42
  • 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.
    – bt90
    Jan 2 at 20:23
  • 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.
    – Tomek
    Jan 2 at 20:47

1 Answer 1

0

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
5
  • that was also my initial theory but it seems to be Cloudflare problem: dig subdomain.nxdomain.info type65 @carl.ns.cloudflare.com
    – bt90
    Jan 2 at 10:02
  • carl.ns.cloudflare.com doesn't allow recursive queries.
    – AlexD
    Jan 2 at 10:58
  • It doesn't work with Cloudflares 1.1.1.1 either
    – bt90
    Jan 2 at 11:13
  • HTTPS RR actually do resolve for CNAMEs with Google DNS: dns.google/… That's whyi think that it might be a Cloudflare bug.
    – bt90
    Jan 2 at 11:40
  • You are probably correct that the root issue is with authoritative NS as it doesn't return even a CNAME itself for type65.
    – AlexD
    Jan 2 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.