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._tcpRR created in this zone. Basically DUJ does not tell anything about zone cut and still asks to create a zone.
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.
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.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
