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
