On 4/14/22 4:00 PM, Mark Andrews wrote:
Bring on HTTPS support in browsers as then this CNAME at the apex idiocy can go away.
I have doubts about this, because a) that will take a long time (a decade or more until people feel comfortable that most browsers are using them), and b) people are still going to want the same protocol-independent effect in other software that will never be updated to support HTTPS or SVCB records.
As a silly example, some people are going to want to "ping example.com" and expect it to reach the same IP address as "https://example.com";.
I was disappointed to see the ANAME draft <https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/> retired in favor of HTTPS records, because unless I'm misunderstanding, they don't really solve the same problem, or at least not in the same way.
Experience shows that people really do want a way to express "every A record lookup for example.com should return the same value as whatever example.net (which I have no control over) currently returns", with no specification of protocols needed. They'll continue to want that for various (perhaps misguided) reasons.
I suppose the proper solution for people who want to do this is to use software that synthesizes A records based on lookups of the CNAME/ANAME/ALIAS target. But that has its own complications, and people will keep trying to do it natively in DNS with "CNAME at the apex" hacks and so on. It would be nicer if there was a proper way to do what people (think they) need.
(BTW, the isc.org "CNAME at the apex of a zone" page at <https://kb.isc.org/docs/aa-01640> has some text at the bottom that doesn't make sense, starting with "authoritative for a zone have been made capable".)
-- Robert L Mathews _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
