Hi Dick, Ben,
I'm the (new) developer at NLNet Labs who implemented SVCB in NSD. While
I have no strong opinion on the double escaping matter, I will pitch in
that NSD currently adheres to the draft (as far as I'm aware).
Best,
Tom
On 2021-05-06 22:16, Dick Franks wrote:
On Thu, 6 May 2021 at 19:11, Ben Schwartz <bem...@google.com> wrote:
On Thu, May 6, 2021 at 8:50 AM Dick Franks <rwfra...@gmail.com> wrote:
But that is precisely what you are NOT doing.
You have assigned a special significance to the character sequence
"\\," contrary to RFC1035.
The language of RFC1035 is crystal clear that an escaped character is
parsed as plain text, independently, without regard to context, and
that any special meaning does not apply.
Strict application of the RFC1035 rules causes string "...\\,..."
to be equivalent to "...\092,...".
I'm not sure what you're describing. Those two inputs are universally
equivalent in zone files under the current draft. They are both
reduced to {'\', '"'} by char-string parsing, which is applied
uniformly and without modification to all SvcParamValues.
... and the '\' without any special meaning fails to protect the comma
from the attention of the argument splitter.
Each SvcParamValue has its own input format. For some SvcParamValues,
'\' and ',' may not be allowed characters. For others, they may be
ordinary characters to be copied into the output, or they may have
special significance.
... and I might, or might not, have a boiled egg for breakfast!
BIND, NSD, and Net::DNS are all able to arrive at implementations of
SVCB using the RFC1035 standard escape conventions, which demonstrates
beyond reasonable doubt that recognising "\\," is not an essential
requirement.
I disagree: what you are proposing is a deviation from RFC1035 escape
conventions, and what the draft does is specifically to ensure that no
such deviation is required.
I am advocating strict adherence to RFC1035 escape conventions. You
are the one proposing to deviate.
... I have now encountered multiple codebases where modifying the
RFC1035 char-string parsing in the way that you suggest would be
prohibitively complex, and that complexity will only grow over time as
new SvcParamValues are defined.
If the development cost is prohibitive, the obvious solution is to use
BIND, NSD, or one of the other respectable implementations which are
certain to be not far behind. If Google cannot afford the license
fee, a six line perl Net::DNS script could be used to translate
RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.
The "value-list" format is a bit like a (much simpler) cousin of the
SPF macro language (https://tools.ietf.org/html/rfc7208#section-7.1).
In both cases, the char-string decoder's output contains embedded
commands that allow the next processing stage to distinguish between
delimiters (comma and space, respectively) and escaped delimiters ("\,"
and "%_", respectively).
That is no justification at all. SPF people can do whatever they
like within the arguments of a TXT record.
--Dick
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
