On Feb 5, 2025, at 07:16, Pawel Kowalik <kowa...@denic.de> wrote:
> 
> Hi Paul,
> On 04.02.25 20:32, Paul Hoffman wrote: [PK snip...]
>>>>> 3) The assumption seems to be that DUJ is always generated dynamically 
>>>>> for each application. Some simple service scenarios only require a static 
>>>>> setup, so a DUJ could be even offered as part of documentation. This 
>>>>> would require that DUJ would also include relative records, not only FQDN.
>>>>> 
>>>>> 
>>>> A rabbit hole at the bottom of a slippery slope. I think that's best 
>>>> handled by the proposals for automated updates.
>>>> 
>>> Thinking about potential applicability of DUJ, I would say that a 
>>> possibility to have a static DUJ that can be applied to foo.com and bar.com 
>>> same way is an interesting feature (actually going even further away from 
>>> automation), rather than requirement to generate new DUJ for each zone.
>>> 
>> This shifts the burden of work from the application service to the DNS 
>> operator, while at the same time making the string more complicated. I don't 
>> see that as a net win for usability.
> [PK] true that. A design and use-case decision obviously.
> One additional aspect to consider when using FQDN is that it does not offer 
> clarity which zone the DUJ needs to be applied to.
> For existing zone it would be enough to say "apply the template to the most 
> specific zone for given FQND, or all FQNDs in DUJ". An additional question 
> comes to my mind here: should DUJ allow multi-zone changes or not?
> 2.2 states however that "the FQDN might be a zone that does not yet exist 
> because it is being created by an "add" action.". In this sense it won't be 
> deterministic to tell which zone to create. For FQDN 
> "_443._tcp.foo.example.com" the zone might be foo.example.com or example.com. 
> [PK snip...]

Telling someone to create a zone with two levels below the current zone 
inherently creates the zone one level below. I can't see anyone thinking any 
different.

> 
>>> A weak point of this approach, rather than a declarative "desired state" 
>>> approach is that the service does not know how the zone looks like, only 
>>> what responses the RRs deliver. So if a zone would have a wildcard TXT 
>>> record on the APEX and no DMARC, a service might think to remove this TXT 
>>> record on _dmarc host, even though its not a real record and any attempt to 
>>> remove it would fail.
>>> 
>> Good point. I don't know how we could deal with that short of making a mini 
>> programming language, and I think that would again hurt adoption.
>> 
> [PK] A way to deal with it would be to tell that a "del" action won't fail if 
> RR does not exist. Result is the same - the record does not exist. A warning 
> might be appropriate. Actually the same situation is with "add" - if exactly 
> the same RR already exists why would add need to fail? After adding it the 
> records would have existed the same way.

Why allow a service provider, who can do DNS lookups before creating a DUJ, to 
make sloppy errors? I don't see who this helps.

--Paul Hoffman


_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to