On Fri, 7 May 2021 at 16:52, Paul Hoffman <[email protected]> wrote:
>
> On May 7, 2021, at 3:21 AM, Pieter Lexis <[email protected]> wrote:
> > For PowerDNS, we treat the parsing of SVCParams as a two-step process.
> > First we use the normal rfc1035 character decoder on the full SVCParam
> > value, after which we apply the value-list parser. The former parses
> > 'foo\\,bar' into 'foo\,bar' that is then parsed to a list of length 1
> > with value {'foo,bar'}. So nothing changes from the perspective of the
> > rfc 1035 parser.

Pre-processing of '\\,' into the RFC1035 standard '\,' is
superficially attractive, but also fraught with danger.

A parser could have some fun with this one:

    $ORIGIN example.com
    @   SVCB   1 foo
key6="\032\001\013\184\000\000\000\000\000\000\000\000\\\\,\000"
    ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00

> >
> > I can see how this might be confusing to those writing zone contents and
> > would support a solution that either prohibits comma's in SVCParam list
> > values or a different value separator that is not allowed to be embedded
> > in values.
>
> Pieter has a point here: to parse correctly, you need a two-step (or 
> two-level) process. The *only* way to prevent that in the spec would be to 
> say that commas are forbidden in  parameter values. However, even if the spec 
> said that, someone would mess up and put a comma in a parameter value, and 
> then different parsers will yield different values based on whether or not 
> they took that shortcut.
>
> Escaping is hard.

Undeniably.

The spec only needs to say that a comma needs to be escaped  ( \, ) in
order to be disregarded as a separator.

BIND, NSD, Net::DNS, and PowerDNS can all do this, so there is little
mileage in claiming that it is not possible.

The "impossible" can be made possible by doing the right things in the
correct order.
Selecting the right things and the correct order is left as an
exercise for the student.




--Dick

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to