On Feb 1, 2025, at 15:10, John R Levine <jo...@taugh.com> wrote: > >>> ["DUJ", [["add", "yourname.example", "TYPE4321", "\# 4 0A000001"]] >>> >>> IF you put quotes around it, you'll get the wrong answer. >> >> I assumed that software that is updating zone files would know this; the >> examples in RFC 3597 are pretty clear about that. But I"ll add a note about >> that because different RRtypes have different quoting requirements. > > But they don't have different quoting requirements. > > The lexical structure of zone files is defined in RFC 1034 section 5 and is > the same for all RRTYPEs. Tokens are separated by any sequence of > whitespace, double quotes enclose a string to make it one token, parens let > you continue a record onto multiple lines, semicolon starts a comment, and a > backslash quotes a character that otherwise would have a special meaning, > such as a space or a dot that is part of a domain name. > > Hence these text records are different: > > a TXT foo bar > b TXT "foo bar" > > The first one has two strings of three characters each, the second has one > string of seven characters, and they mean different things.
The fact that RFC 1035 didn't define this well has been discussed ad nauseam for >30 years. > I would not want to assume that the code that is processing the JSON has > special knowledge of what tokens are supposed to be in each RRTYPE. Right. > Make it so the translation from the JSON to the zone file record is as > mechanical as possible. If only RFC 1035 had helped us with that. > Either make it one long string that is copied verbatim into the zone file, > possibly including embedded quotes and such, or make it a sequence of tokens > to which a dumb lexer can add backslash or quotes as needed so they remain > tokens in the zone file. Both of those place requirements on producers of DUJ strings that are likely to be performed incorrectly. Further, they are greater requirements than the main use case for DUJs: to replace current human instructions about what to "type". Nothing in DUJ is worse than what we already have, I believe, and trying to force DUJ providers to use a syntax with fiddly backslashes seems a step backwards. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
