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...]
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.
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
