On Feb 3, 2025, at 05:33, Pawel Kowalik <kowa...@denic.de> wrote: > > This is an interesting approach to solve this problem with potentially low > barrier entry.
Thanks! (For those in DNSOP who don't know, Pawel is a co-author on the DomainConnect draft.) > I think few properties of this solution would be worth being clarified in the > draft. > > 1) Is there an intention that DUJ string could be freely or is welcoming to > be modified by the user? Base64 of DUJ would also do the job the same way, > likely would be less error prone when copy paste and not necessarily welcome > fiddling with the content. There is no such intention. I'll add that to the draft. > 2) Why TTL is not covered? This is common that the service would also suggest > an appropriate TTL for their RRs The TTLs in a zone are usually controlled by the zone operator. I can imange a zone owner saying at a particular record should only be in a zone for so long, but not the TTL. The TTL is an operational part that should be controlled bu the zone operator. > 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. > 4) Also the assumption seems to be, that the service would upfront check the > content of the zone and generate DUJ accordingly. For example a service might > want to add DMARC record only if there isn't one in the zone alteady. If this > assumption is true a valid consideration might be to see how the user might > be informed if the zone content changed in the mean time before DUJ > generation and DUJ application. Ooooh, good point. Will add. > 5) Is DUJ application all-or-nothing? Yes. > Section 4 tells "does so only after verifying all the contents of the DUJ > string.". Does it mean DNS operator needs to ensure that all the operations > can be actually applied and reject whole DUJ if not? Yes. > What is the expectation if out of whatever reason DUJ would fail in the > middle? Is it supposed to be transactional (ergo rollback) or just applied to > the first error? Rollback. If there is a way to say that better in the document than the quoted sentence, I'll certainly add it. > 6) The Action Processing section 4.2. seems to assume DOJ application is not > idempotent. This is an interesting property, as in fact the service issuing > DOJ is rather interested in the final state of the zone, meaning not that a > record is added or deleted, but rather existence or not existence of a > desired RR. So a deletion of an non-existing record would be OK, because this > is what the service wanted. Also adding a record with exactly the same > content as an existing record shall also not be an issue, because in the end > this is what the service was expecting as result of the action. Either would cause the DUJ string to be rejected in whole, so I'm not sure why an application service would suggest that. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
