On Feb 6, 2025, at 12:36, Pawel Kowalik <kowa...@denic.de> wrote: > > Hi Paul, > On 06.02.25 19:32, Paul Hoffman wrote: >> 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. > [PK] Having the example above, assuming the user does have example.com in > their account one way of processing would be to just add the RR _443._tcp.foo > to this zone. Other interpretation would be that foo.example.com needs to be > created as a separate zone and _443._tcp RR created in this zone. Basically > DUJ does not tell anything about zone cut and still asks to create a zone.
Correct. It says "this target zone should exist, with this data". > If example.com is not in the account then DNS operator can only "guess" which > zone to create. example.com or foo.example.com or maybe something else? > 2 ways out of this problem: define clearly the zone in DUJ or remove this > part about creating zone that does not exist and being created by "add". I > would rather opt for the latter as service provider may not exactly know the > zone cuts when creating DUJ. Fair point. I can add that. >>>>> 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. > [PK] This is not about sloppy errors but about situation (quite common for > TXT records btw) that a wildcard would make service provider think they would > have to remove a record, which in fact does not exist. I keep forgetting about wildcard responses. <sigh>. I'll add this. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
