On 2/7/25 23:34, Paul Hoffman wrote:
On Feb 7, 2025, at 01:10, Peter Thomassen <pe...@desec.io> wrote:
- For clarity, I'd prefer DUJ-S and DUJ-B64. (That denotes the variants as
belonging to the same concept, and it prevents confusing the 64 part with
DNS64.)
There's a hyphen in the bikeshed! :-)
And a B!
- As in the first version, I'm not sure why the format isn't
["DUJ-S", {"add": [zone-data...], "delete": [zone-data...]}]
with object elements optional. Can you shed some light on this?
As it says in the design section of the document:
The design choice to use JSON arrays instead of objects is to increase security
and reliability.
This is to prevent key-value pairs to be added that might cause users or
operators to possibly process the DUJ strings incorrectly or to misinterpret
them.
Sure. However, another way to achieve this is to mandate that a DNS operator
MUST reject DUJ requests with unknown object keys (aka: if it violates the
prescribed schema), so I was still unclear about this choice.
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.)
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?
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
