On Mon, May 10, 2021 at 9:58 AM Ben Schwartz <bemasc=
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
