On Feb 4, 2025, at 03:52, Pawel Kowalik <kowa...@denic.de> wrote: >>> 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. > [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.
OK, I did not know that. > 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. Let's revisit that if the WG adopts the draft. I can see "must be specified by the application service" and "might be ignored by the operator", but the latter makes me nervous. >>> 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. >>> 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." Excellent; I'll add that to the next version of the draft. >>> 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". As a note, the application service could query for A records and then list them all for deletion. I don't want to suggest that they do 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. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
