All,
I have considerable difficulty with these test vectors at the end of
Appendix D.2:
16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
16 foo.example.org. alpn=f\\\092oo\092,bar,h2
\# 35 (
00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 01 ; key 1
00 0c ; param length 12
08 ; alpn length 8
66 5c 6f 6f 2c 62 61 72 ; alpn value
02 ; alpn length 2
68 32 ; alpn value
)
which appear to be incompatible with RFC1035 5.1 paragraph 10:
Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:
...
\X where X is any character other than a digit (0-9), is
used to quote that character so that its special meaning
does not apply. For example, "\." can be used to place
a dot character in a label.
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD. The resulting
octet is assumed to be text and is not checked for
special meaning.
The intention appears to be to include (a) a single arbitrary octet in
the argument, and (b) a plain text comma not being a delimiter in the
argument list. The specimen result is consistent with that assumption.
Armed with the weapons supplied by RFC1035, the obvious way to
represent such an argument is: alpn="f\092oo\,bar,h2"
A parser adhering strictly to RFC1035 zone file escape conventions:
#!/usr/bin/perl
use Net::DNS 1.31;
use Net::DNS::ZoneFile;
my $zonefile = new Net::DNS::ZoneFile(\*DATA);
while ( my $rr = $zonefile->read ) {
$rr->print;
}
exit;
__DATA__
rfc1035-compliant.example. SVCB 16 foo.example.org.
alpn="f\092oo\,bar,h2"
produces the desired wire-format image:
rfc1035-compliant.example. IN SVCB ( \# 35 0010 ; 16
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
0001 000c 08665c6f6f2c626172026832 )
Other parsers are available.
The test vectors, as written, appear to rely upon somehow reactivating
the special meaning of the escape character which is explicitly
disallowed by RFC1035.
The result in each case is:
non-compliant.example. IN SVCB ( \# 37 0010 ; 16
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
0001 000e 06665c5c6f6f5c03626172026832 )
the escaped escape characters being inserted as uninterpreted text per RFC1035.
Dick Franks
________________________
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
