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

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

On 21/08/2026 18.10, Pawel Kowalik wrote:
>> 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. 


10.4 contributed to my confusion significantly, as it says:

> For example it is very common for DNS provider not to allow CNAME 
> records to be at the zone apex.

but the DNS *protocol* does not allow CNAME at a zone's apex. While one 
can find authoritative servers which will return it nevertheless, I 
certainly wouldn't recommend it, as the resulting ambiguity is bad and 
breaks things on resolver side (especially with forwarding).


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

Common authoritative servers (and resolvers) shouldn't have any trouble 
handling unknown record types, I believe, but I don't know too well how 
the custom code bases in front of auths handle these.  Still, RFC 3597 
is 23 years old and pretty simple...

But to make myself clear, I wrote this just as a consideration.


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

It will most likely suffice.  I see two schemes with keys and signatures 
under a couple kilobytes which have been already selected by NIST 
(ML-DSA + FN-DSA), so I do hope that some such schemes will remain 
(unbroken, etc.) - and if not, I guess we'll have more serious 
complications than around dconn.


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

Oh, okay.  Same as above, it will most likely work out.  And contrary to 
DNS, the URL length limits shouldn't be so difficult to increase if a 
real "global need" arises (to persuade the implementers).

I was being unnecessarily careful here, I guess.


I won't repeat the remaining nits, as they do look addressed :-) (in an 
unmerged pull request)

--Vladimir