Hi Paul,
Thanks for this, and sorry I didn't catch it before the DNSOP session today,
unnecessarily taking everyone's time.
On 3/20/25 09:58, Paul Hoffman wrote:
Anyway, if objects are to be avoided, the repetition of "add" and "delete" in
each update array can also be prevented by allowing multiple record-data (zone-data) values:
[ ..., [ ["add", "foo.example MX 10 mail1.test.", "mail.foo.example MX 20
mail2.test."] ] ]
This structure is enabled because the record-data is now a string and no longer
a variable-length list of fields, freeing up that degree of freedom. It also
prevents comments etc.
(I'd still permit multiple "add" or "delete" update arrays; I just would not
mandate that an update array can only add/delete a single record.)
This is fine too. I don't see a strong reason to do one of the other.
In my view, avoiding unnecessary repetition is a good thing.
Unrelated: Is a DUJ request valid which adds a record and then deletes the
same? If yes, would it be valid if the order of the add and delete arrays were
reversed?
It is "valid", but the the DNS operator doesn't have to actually process it. Or anything.
As the draft says: "A DNS operator SHOULD tell a user about every change made from a DUJ."
Indeed, that addresses my concern.
I could strengthen that to also say "A DNS operator may reject a DUJ for any reason,
such as if it adds and then deletes the same record."
Even with the concern addressed, I would like that. :)
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
