b0rk does fun things with DNS: CNAME records at the root of the domain; technically not allowed, definitely not recommended, but somehow work for web browsing
Posted by jpluimers on 2023/12/21
[Wayback/Archive] 🔎Julia Evans🔍 on Twitter: “I’ve always heard that you can’t create CNAME records at the root of the domain. But apparently you can? It seems to work fine as far as I can tell but I’m curious about the possible consequences. (yes, I registered cnameroot.com just to make this tweet) “
bork@grapefruit ~> dig @dns2.registrar-servers.com. A chameroot.com cnameroot.com. 300 IN CNAME examplecat.com. bork@grapefruit ~> dig @dns2.registrar-servers.com. NS cnameroot.com cnameroot.com. 1800 IN NS dns1.registrar-servers.com. cnameroot.com. 1800 IN NS dns2.registrar-servers.com.
> dig +short mx cnameroot.com @dns2.registrar-servers.com 20 eforward5. registrar-servers.com. 15 eforward4. registrar-servers.com. 10 eforward1. registrar-servers.com. 10 eforward2.registrar-servers.com. 10 eforward3.registrar-servers.com. ~ > dig +short mx cnameroot.com examplecat.com.
If course, though great fun, this is definitely recommended as it is against RFCs, see this part of the thread shows:
- [Wayback/Archive] Sergi Isasi on Twitter: “@b0rk This will break other RRs at root. CNAME RFC is that if it exists for a label, it must be the only RR type for that label. This is especially problematic at root because things like MX live there. More detail”
- [Wayback/Archive] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain’s Root
The problem stems from the fact that the DNS specification dates from 1987.
…
Technically, the root could be a CNAME but the RFCs state that once a record has a CNAME it can’t have any other entries associated with it: that’s a problem for a root record like example.com because it will often have an MX record (so email gets delivered), an NS record (to find out which nameserver handles the zone) and an SOA record.
…
- [Wayback/Archive] www.ietf.org/rfc/rfc1035.txt
Network Working Group P. Mockapetris Request for Comments: 1035 ISI November 1987 Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
- [Wayback/Archive] www.ietf.org/rfc/rfc1035.txt
- [Wayback/Archive] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain’s Root
What we needed was a way to support a CNAME at the root, but still follow the RFC and return an IP address for any query for the root record. To accomplish this, we extended our authoritative DNS infrastructure to, in certain cases, act as a kind of DNS resolver. What happens is that, if there’s a CNAME at the root, rather than returning that record directly we recurse through the CNAME chain ourselves until we find an A Record. At that point, we return the IP address associated with the A Record. This, effectively, “flattens” the CNAME chain.
This follows the DNS specification and is invisible to any service that interacts with our DNS. We’ve tested it extensively over the last several months and it works great, completely resolving the Microsoft Exchange and other edge case problems we’d previously seen.
So Cloudflare DNS internally presents flattening as a
CNAMErecord, but externally as anAorAAAArecord reply to the ultimate A or AAAA record content after following the full CNAME record chain. - [Wayback/Archive] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain’s Root
- [Wayback/Archive] 🔎Julia Evans🔍 on Twitter: “@sgisasi how exactly will it break other RRs? I don’t understand why it would break”
- [Wayback/Archive] Patryk Szczygłowski on Twitter: “@b0rk @sgisasi It gives you undefined behaviour. E.g., some resolvers could follow CNAME while requesting MX/NS/etc. instead of getting them from the zone. Some won’t. Some will get confused and return error. This is explicitly forbidden in RFC.”
- [Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@epatryk @b0rk @sgisasi I am eager to learn: any links to the relevant RFC portions for that?”
- [Wayback/Archive] Patryk Szczygłowski on Twitter: “@jpluimers @b0rk @sgisasi
datatracker.ietf.org/doc/html/rfc2181#section-10.1“- [Wayback/Archive] RFC 2181 – Clarifications to the DNS Specification: section 10.1. CNAME resource records
10.1. CNAME resource records The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name. There may be only one such canonical name for any one alias. That name should generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases with the accompanying canonical name undefined in the DNS. An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data. That is, for any label in the DNS (any domain name) exactly one of the following is true: + one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs, + one or more records exist, none being CNAME records, + the name exists, but has no associated RRs of any type, + the name does not exist at all.10.1.1. CNAME terminology It has been traditional to refer to the label of a CNAME record as "a CNAME". This is unfortunate, as "CNAME" is an abbreviation of "canonical name", and the label of a CNAME record is most certainly not a canonical name. It is, however, an entrenched usage. Care must therefore be taken to be very clear whether the label, or the value (the canonical name) of a CNAME resource record is intended. In this document, the label of a CNAME resource record will always be referred to as an alias.
- [Wayback/Archive] RFC 2181 – Clarifications to the DNS Specification: section 10.1. CNAME resource records
- [Wayback/Archive] 🔎Julia Evans🔍 on Twitter: “@epatryk @jpluimers @sgisasi yea I know it’s forbidden by the RFC (and I’m not advocating for it) I’m just curious about how it actually breaks in practice”
- [Wayback/Archive] Patryk Szczygłowski on Twitter: “@b0rk @jpluimers @sgisasi “
dig cnameroot.com soa” I can’t get SOA record! Whiledigis mainly a debug tool, many uses it in production. I think most public resolvers coded around this against-the-RFC behaviour, but I wouldn’t count on DNS clients doing the same.” - [Wayback/Archive] Patryk Szczygłowski on Twitter: “@b0rk @jpluimers @sgisasi Also, take note of DNS Flag Day campaign, which is intended to get rid of against-the-RFC behaviours by coordinating global “stop tolerating this” events. So far two events happened, but it’s possible there might be “CNAME at apex is an error” event happening in the future.”
Related:
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment