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

[Pawel Kowalik <[e-mail]>]

Hi Vladimir,

On 23.08.26 13:04, Vladimír Čunát wrote:
> 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).
>
Ok, got your point. At least I hope so. Would following edits work for you:

10.4:

old:
-   Note: DNS Provider MUST also check applicability of all generated
-   records to the target DNS zone in its own system.  For example it is
-   very common for DNS provider not to allow CNAME records to be at the
-   zone apex.
new:
+   Note: A DNS Provider MUST also check the applicability of all
+   generated records to the target DNS zone against constraints imposed
+   by the DNS protocol itself, such as the coexistence rules of
+   [RFC2181], as well as any other local capabilities, limits or
+   policies.

>>> - 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.
>
Yes, the front-ends or the systems in between are a limiting factor from 
my experience - and I tested quite a few of them. Therefore as long as I 
don't hear other WG members shouting good reasons to go other way we 
should stay with a design which proved working.

I also regret the trend of putting everything into TXT, as this is 
likely not how the designed extensibility model of DNS was thought of. 
Maybe domain connect, when even wider adopted, would close this gap when 
user interface won't be the primary medium of DNS configuration.

> [ snip PK]
Kind Regards,
Pawel