Hi Paul,No idea how I skipped responding to the mailing list last time, so the conversation went on a private track, but now fixing this.
On 03.02.25 22:12, Paul Hoffman wrote:
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.
[PK] Thanks.
2) Why TTL is not covered? This is common that the service would also suggest an appropriate TTL for their RRsThe 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.
[PK] Typically DNS operator user interface allows for setting of TTL, so it is in fact controlled by the user.
Also most the services typically specify TTL value they would like to see for their records. Likely not always out of good reasons but this is a fact to consider.
For the completeness of DUJ I would advocate to include TTL, even if handling would mean that it might be overwritten/normalised by the DNS 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.
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.
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.
[PK] "verifying all the contents of the DUJ string" is then too vague, or if it refers to section 3.1 not sufficient.
I would rather suggest "...after verifying that the entire DUJ string can be atomically applied to the target zone. The DNS operator MUST NOT process any action within the DUJ if any action would prevent the atomic application of the entire DUJ."
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.
[PK] ok, so generally it's in line with the point 3, that DUJ is always generated according to the state of the zone (or at least relevant part of the zone known to the service generating DUJ), so none of the actions would ever render error unless the zone changed in between. This kind of excludes any static DUJ, also because there is no wildcard matching - so it's impossible to say "remove all A RRs on this host".
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.
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
