Thanks for the detailed review! On Feb 1, 2025, at 13:47, Robert Edmonds <edmo...@mycre.ws> wrote: > > Paul Hoffman wrote: >> Greetings again. The following is a proposal to help end-users who are told >> "please enter this record in your zone to prove your existence". It >> simplifies the process without automating it; in short, it makes >> copy-and-pasting more likely to work, particularly for the _label names that >> are being used more. (DomainConnect is working on automation, but with a >> different target audience.) >> >> If this interests you, please read the short draft, particularly the use >> case and design descriptions in the introduction. Those sections describe >> why the format is purposely limited for this narrow use case. > > Hi, Paul: > > 1) This format does not specify what zone to apply the change to. E.g., > taking the example: > > ["DUJ", [["add", "mail.yourname.example", "TXT", > "v=spf1 a:mail.yourname.example ip4:192.0.2.49"]]] > > Should this update be applied to the mail.yourname.example zone, the > yourname.example zone, the example zone, or the root zone?
The mail.yourname.example. Yipes: I never said that explicitly! Will update to say that, and give an example. > If the goal is to reduce errors by making it easier for a user to > specify an operation to a DNS operator's interface, including the zone > name would make sure the correct zone is being operated on, or allow > reducing the number of interactions (for instance, not needing to > manually select a zone to operate on first). Yes, exactly. > 2) Regarding: > > The DNS operator SHOULD be able to handle [RFC3597] RRtypes. > However, they may have a local policy to not allow users to add or > delete unknown RRtypes. > > A DNS operator MAY reject any DUJ string for any reason. If the > DUJ was received from a user interface, the DNS operator SHOULD > clearly describe why a DUJ was rejected. > > The RFC 3597 generic syntax is not limited to unknown RRtypes. It can > also be used to represent RRtypes known to the implementation. Whether > to support the 3597 syntax or not should probably be orthogonal to > whether the operator supports the RRtype or not for updating via a DUJ > string (indeed, the next sentence allows rejecting a DUJ object for > any reason). > > If the use case is to support ease copy-and-paste operations, though, > why not *only* use the RFC 3597 generic syntax? That would simplify > parsing and generation of DUJ strings. Presumably an operator accepting > a DUJ string could render the record data encoded in the DUJ string and > present UI to the user to confirm the operation. Actually, this would > be a good idea even if the DUJ string contained display format encoded > record data. > > So my suggestion would be to mandate the RFC 3597 syntax as the only > allowable syntax for encoding record data, unless there is also an > unstated requirement that the record data be visually decipherable on > its own to end-users without the aid of external tools (in which case, > *allowing* RFC 3597 format as an option would seem to cut against such > a requirement). Good point. Lots of operators won't support (or care about) not-yet-defined RRtypes, which is why RFC 3597 support is SHOULD, not MUST. I'll clarify that reason for using the "normal" syntax is to make the string possibly-readable by the user; that's a design goal. > 3) Regarding: > > Some RRtypes require multiple character-strings, where > "character-string" is defined in Section 5.1 of [RFC1035]. In such a > case, each character-string is a separate JSON string. For example: > > ["DUJ", [["add", "yourname.example", "WALLET", "ETH", > "0xb775599c76b4672B0D820E3AA534F7cF9312c263"]]] > > I guess this should be "<character-string>", which appears in the > section of RFC 1035 about the encoding of the zone file format used > by nameservers. Yes, good catch. > So does a DUJ encode the display format of record data, > or does it encode a zone file fragment that embeds the display format of > record data? It encodes the display format. The draft says "The strings are expressed in the same manner as the display format defined for the RRtype." > Not all record types are encoded as one or more <character-string>'s, > for instance the SOA RDATA encodes two <domain-name>'s followed by five > 32-bit integers. Should that be represented like this? > > ["DUJ", [["add", "yourname.example", "SOA", > "ns1.yourname.example", "hostmaster.yourname.example", "2024112101", > "7200", "3600", "604800", "60"]]] > > Or like this? > > ["DUJ", [["add", "yourname.example", "SOA", > "ns1.yourname.example hostmaster.yourname.example 2024112101 7200 3600 > 604800 60"]]] The latter, according to a normal reading of RFC 1035. Nothing in Section 3.3.13 suggests that the fields are <character-string>s; neither does the example in Section 5.3 there. > What about this? > > ["DUJ", [["add", "yourname.example", "SOA", > "(\n yourname.example. ; MNAME\n hostmaster.yourname.example. ; RNAME\n > 2024112101 ; SERIAL\n 2H ; REFRESH\n 1H ; RETRY\n 1W ; EXPIRE\n 1M ; > MINIMUM\n)" > ]]] Nothing in DUJ says that comments are allowed; I'll add an explicit prohibition. > > SOA's are probably unlikely to be encoded using DUJ strings, but what > about e.g. MX records? Should those be represented like this? > > ["DUJ", [["add", "yourname.example", "MX", "10 mx1.provider.example"]]] > > Or like this? > > ["DUJ", [["add", "yourname.example", "MX", "10", "mx1.provider.example"]]] The latter, according to the example in Section 5.3 in RFC 1035. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
