[dconn] draft-ietf-dconn-domainconnect-03 early Dnsdir review

[Vladimír Čunát via Datatracker <[e-mail]>]

Document: draft-ietf-dconn-domainconnect
Title: Domain Connect Protocol - DNS provisioning between Services and DNS
Providers Reviewer: Vladimír Čunát Review result: Almost Ready

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.