Hi all, Just dropping a note here to say I think this is useful work - I have just been through a particularly painful episode of having to update TXT records for a number of non-technical domain owners, all with different registrars, and came here wondering if there was a "better way"...
While DomainConnect will certainly help in some circumstances, not all users have access to their DNS management console, so this is a more universal approach. On Sat, 1 Feb 2025 at 21:48, Robert Edmonds <edmo...@mycre.ws> wrote: > 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). I would not underestimate the ability for data to be munged between copying and pasting. The JSON could be pasted into an email, chat message, or Word doc (!) and sent to someone else to perform the update... I'm not sure if the above is the best approach but anything to maintain the integrity of what is produced by the DUJ generator through to the DUJ recipient would be useful, to reduce instances of the pasted DUJ being rejected as invalid, or not resulting in the change that was intended by the generator. I agree that the DNS operator should present UI to the user to confirm "valid DUJ received, this is the change I'm proposing to make...". Hope that helps, Mike _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
