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.
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
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.