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! :-)
> - 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.
For example, it is not possible to include comments in a DUJ string such as
"For DKIM".
The reason for this is that such comments could be used by an attacker to
convince a user to make a change that they otherwise might not by adding a
comment such as "Urgent security update".
> - The use of the term "zone" in the document is confusing. For example,
>
> The owner name of a zone in a zone-data string might be a zone that
> does not yet exist because it is being created by an "add" action. A
> common example of this is adding an "underscore name" [RFC8552] such
> as "_smimecert" and "_xmpp".
>
> It seems that in these example cases, typically the zone would exist, but
> the owner name in it does not yet. The text somehow implies that _smimecert
> and _xmpp would be their own zones. Why is that?
Good catch; I'll clarify.
> - The "zone-data" token I think should be named "record-data", as it can't
> contain a full zonefile.
Yes, I like that too.
> - "The owner-name MUST NOT contain a wildcard." Can we add justification? (I
> think this comes from a concern about deletion operations in the face of
> wildcards, but I'm not sure that it should follow that wildcard "add"
> operations should be forbidden. I also suspect that the prohibition is easily
> overlooked during implementation of "add".)
You're right, it was primarily about deletion. Can others think of a reason to
preven an application service from suggesting adding a wildcard?
--Paul Hoffman
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
