Hello, apex CNAME is inherently incompatible with forwarding, as I see the standards *now*.
I wonder if such special-casing of some types like DNSKEY could solve (almost) all issues with CNAME at apex. (additional candidates off the top of my head: NS, SOA, DNAME?) I didn't think it through sufficiently at this moment, but there have been efforts to standardize CNAME at apex in some sensible way, and all of them have failed so far (with hope of getting addressed soon in other ways - currently HTTPSSVC). If this approach does not solve "sufficiently large" fraction of the issues (or does not eventually get standardized via dnsop), I'm afraid the additional complexity won't be worth it, along with encouraging apex CNAMEs. https://dnsflagday.net comes into mind. I'd hope that eventually we make apex CNAMEs either always work or always fail; this in-between state for commonly desired features is unhealthy. > Even if the CNAME enters an iterative resolver's data cache, the DNSKEY > should be served from in preference to any CNAME learned at some point > later, i.e. at a signed zone apex, the CNAME should be ignored when > responding to DNSKEY queries. Detail: if I did this, I would ignore any CNAME *regardless* of the existence of DNSKEY on the name (all conditioned by QTYPE == DNSKEY). Maybe that was your intention, I'm not sure. --Vladimir _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
