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

[Pawel Kowalik <[e-mail]>]

Hi Vladimir,

many thanks for the review. Further comments below with PK>

On 17.08.26 10:55, Vladimír Čunát via Datatracker wrote:
> 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.

PK> Not at all. CNAME in Domain Connect, as it is Fully Specified RR 
type, it corresponds to what RFC 1035 specifies.
It means it cannot be applied to the zone's apex.

A template may express CNAME on @ host, however it would be replaced 
with non-apex label with template application
on a specific host (with host apply parameter). Such template would 
always require host to be set, therefore hostRequired
flag is expected.

The draft covers it in 6.3.2. and a Note in 10.4. is specific about 
conflicts.

>
> 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.
PK> there used to be an extension RR type in domain connect named 
APEXCNAME with exactly this function
express in an explicit way. DCONN WG decided to rather remove such 
extensions from the core draft
therefore it is not there any more but only reserved for the back 
compatibility.
Some providers make such tricks implicit with CNAME, but I see it 
outside of what DCONN shall take care,
same as they are outside of what 1035 specifies.
> #### 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).
PK> this turns out to be operational necessity to use TXT to have 
something deployable in a foreseeable time.
> 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.
PK> not being an expert of PQC, my quick research tells the public keys 
are indeed bigger, but with ~2 KiB still with enough of buffer till 64 
KiB limit would be hit.
> - 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.
PK> the signature is there exactly to protect the URL and still offer an 
opportunity to send it over to someone else (hand-over).

HTTP does not offer any other possibilities for GET requests. POST is 
only possible with way more complexity of form post which does not work 
for the case above.

PQC may hit a limit here as well, but RFC 9112 recommends 8000 octets to 
be supported and this is what one shall expect to work these days.
Here some algorithms might exceed the limit, but there are quite few 
which would fit into 2-4 KiB signature size range.

> - nit/typo 6.3.3: %var%.example.com is confusing, as the "s" characters are
> missing
PK> thx, will correct
>
> - nit: perhaps avoid referencing RFC 8499 -> update to 9499?
PK> corrected
>
> - 10.4 nit: maybe explicitly say that a CNAME conflicts also with another CNAME
> (on the same "host")
old:
    *  A CNAME record conflicts with any other record on the same host,
       and any existing records conflict with a CNAME.
new:
     * A CNAME record conflicts with any other record on the same host,
     including another CNAME, and any existing records conflict with a 
CNAME.
>
> - 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.
PK> good catch. Changed to "Handling"
>
> - 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.

PK> This needs an add in 2 places: template definition and template 
application.

In Section 6.2. under TTL I'd add a clarification:

       Records forming the same RRset (i.e., sharing "host"/"name" and
       record type) SHOULD be given the same "ttl" value in the template
       definition, since [RFC2181] Section 5.2 requires all resource
       records in an RRset to share a single TTL.

In Section 10.2. I'd add a note to 8b)

        b.  Write the Rendered Record Set to the zone in totality.

            i.  Note: if the Rendered Record Set yields differing "ttl"
                values across new and existing RRs that form the same
                RRset, the DNS Provider MUST reconcile them to a single
                TTL (e.g., by taking the lowest value), per [RFC2181]
                Section 5.2

I applied the changes already to an open PR 
https://github.com/Domain-Connect/spec/pull/203

Kind Regards,
Pawel