Hi all,
this is actually not the first time someone has come with this issue:
https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=WxZLxeJF3vSHiOG0jGm8kek5ajI
If there really is a strong reason for putting multiple key-value
records into one RData (instead of one RRSet), it should be described
somewhere clearly (more clearly than Ben's two pretty relativisable
sentences). If so, I would accept it happily.
Brian, thanks for nice elaborate on the "counter-proposal". What exactly
is illogical on that, in the end?
FYI in Knot DNS authoritative, we were able to implement
zonefile<->wireformat transitions according current draft (being a Merge
request to date). I feel no need to change the escaping manner.
Libor
Dne 11. 05. 21 v 1:59 Brian Dickson napsal(a):
On Mon, May 10, 2021 at 9:58 AM Ben Schwartz
<bemasc=40google....@dmarc.ietf.org
<mailto:40google....@dmarc.ietf.org>> wrote:
I don't support breaking the SvcParams into separate RRs across
the RRSet. This would be an extremely inefficient encoding in
wire format, and would conflict with the usual understanding of
resource records as independently meaningful alternatives.
[snip]
To see why I favor two-pass, consider a SvcParam whose wire format
value is defined to be CBOR, represented as JSON in the zone
file. JSON is defined as UTF-16, and allows strings containing
any character from the Basic Multilingual Plane. It also allows
various kinds of backslash escaping including " \" " for quotes
within strings, and "\uD834\uDD1E" for extended unicode
codepoints. A one-pass parser must somehow integrate this into
the flow of zone file parsing. The easiest way is to simply
disable all RFC1035-style escapes and line-breaks for the duration
of the SvcParamValue, but this is a major breach of standard zone
file practice, and raises questions about how to store UTF-16
characters in a zone file. Alternatively, we could somehow combine
both RFC1035 and JSON escaping, but if this is even possible, it
would seem to require writing a new RFC1035+JSON hybrid parser. I
also think these behaviors would be confusing to users, who would
have to try to understand how this new integrated escaping works
in order to author zone files containing either kind of escape.
[snip]
Let me ask what is probably a really leading question, in terms of the
semantics for SVCB (and HTTPS).
If I understand the draft in its current form, the goal is to be able
to encode and parse some DNS RRset in such a way as it lets you
obtain, in one fell swoop (but possibly multiple passes for parsing)
everything needed to obtain:
- A well-ordered list of one or more targets, where each target has a
set of attributes.
- The examples currently show RRsets with multiple distinct Priority
values
- However, the words indicate that it is permissible for two RRs in
the set to have the same Priority value.
- The effect is having an array of objects, each of which has a
priority, name, and optional set of key/value pairs (where values can
be lists).
So, I have a proposed solution that will make the parsing, and
generation of post-parsing JSON objects as close to trivial as possible.
This borrows heavily from what Joe Abley already wrote. I'm just
taking the concept to its (il)logical conclusion.
Encode everything using the following mechanism:
Priority Enumeration Key Value
One of the "Keys" would be Target, with a corresponding Value of FQDN.
All of the records with the same value for "enumeration" belong
together, and form a single SvcParameter list.
For the AliasForm, both the Priority and Enumeration would be 0, and
only a single Target,Value pair are permitted.
To take one example from the draft, and re-encode it thusly:
$ORIGIN svc.example. ; A hosting provider.
pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
HTTPS 2 . alpn=h2 ech="abc..."
pool 300 IN A 192.0.2.2
AAAA 2001:db8::2
h3pool 300 IN A 192.0.2.3
AAAA 2001:db8::3
This would become (for brevity, encoding just a list of RDATA values
for all of the "pool HTTPS" records):
1 1 target "h3pool"
1 1 alpn "h2,h3"
1 1 ech "123..."
2 2 target "."
2 2 alpn "h2"
2 2 ech "abc..."
I think this is likely a lot easier to parse, and to convert into
whatever form your ALPN-handling stuff wants (including JSON).
I is also very close to trivial to write a JSON -> Zone File
transliterator, so user input in JSON (which meets the JSON structure
expected) can be handled, and even bidirectionally allow Zone File ->
JSON for user editing of already-existent entries.
For the example above;
If the priority of both of the above were the same, they would be all
"1 1 ..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".
If my JSON isn't horribly bad, I think this would get converted into:
[ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" :
"h2,h3", "ech" : "123..." } }, ...]
IMNSHO, it'll be faster to discard any existing parsing code, and
embrace this as the Zone File format (and wire format) going forward.
Hope this is helpful to the discussion.
Brian
_______________________________________________
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
