Review assigned to me by dnsdir.  As the text is quite long, I wasn't trying to be careful with all details and focused mainly on potential DNS protocol issues.  Apart from the Apex-CNAME clarification, my stance is "No Objection".

By the way, I do like what dnconn is trying to do, and it sure isn't easy :-)

#### Apex CNAME

I believe this needs at least major clarification in the text.

If I read the context right, I think your intention for dconn's CNAME is to map to DNS's CNAME except if it's on a zone's apex in which case it tries to map to an ALIAS.

That's a non-standard substitute offered by some vendors, sometimes called ANAME, which generates standard DNS records "dynamically" on authoritative servers.  The key thing in my eyes is that it behaves differently than a CNAME.  In particular it only mirrors the values of A+AAAA - which is why it can coexist with any other RR types - thanks to which it can be reasonably used on a zone's apex (which must contain SOA+NS which can't coexist with a CNAME).  I believe that this situation should be made more explicit in the RFC text, and the difference in behavior might also be a source of confusion to users, but that's probably mainly up to implementers to design this well enough.


#### Minor comments to consider

- syncPubKeyDomain: I'm personaly not a fan of using TXT for everything, though I understand that it might seem like an easier path (short-term at least).

In this case the processing looks significantly more complex than with a dedicated RR type.  Also the combination of a BASE64 layer with splitting will grow the size quite a bit.  That doesn't seem ideal with post-quantum algorithms around the corner and DNS messages still being limited to 64 KiB.

- Template Apply Request: similarly, I'm not 100% sure about putting a signature *inside* an URL.  My insight into the HTTP* world is limited, but a quick search indicates that long URLs (more than a couple kilobytes) don't have great support by default.

- nit/typo 6.3.3: %var%.example.com is confusing, as the "s" characters are missing

- nit: perhaps avoid referencing RFC 8499 -> update to 9499?

- 10.4 nit: maybe explicitly say that a CNAME conflicts also with another CNAME (on the same "host")

- nit: "Class" is something which exists for DNS records (since forever), so reusing the name for something completely different in this context might be a source of confusion, but the risk seems relatively small in this case.

- I'm not sure if it's worth noting e.g. that TTLs must be the same for an RRset (records with the same host+type, [2181.5.2]).  The usual workaround is to use minimum from those TTLs.