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

Reply via email to