On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <bem...@google.com> wrote:
> On Wed, May 12, 2021 at 7:14 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> It is demonstrably more likely that a complex parser will have problems, >> than something that combines data from simple RRs in simple RRsets will >> have problems. >> (The history of SMTP is, I think, a good poster child for this, with MX, >> A, AAAA, plus DNSSEC and TLSA support in the clients, which are email >> transport things, not merely DNS things.) >> > > The SVCB parameters' wire format is an extremely simple TLV arrangement; I > don't think "a complex parser" is required. > This is an apples/oranges argument, the parsing complexity I'm referring to (I thought explicitly, but I guess that is too far up-thread) is the presentation (aka zone file) format. The initial opinions (not just mine) were that the format, while maybe familiar to HTTP implementers, is very un-DNS-like, and the proposition was that the complexity was not strictly necessary. While combining multiple simple records into a complex record, in wire format, would not be difficult, it is not what DNS authority servers do, and is not what resolvers do. But, the _wire format_ of the original proposed record is not at issue, and never has been, so I don't understand why you bring that up. > It's also far from a novel design for DNS; in fact, it's identical to the > widely implemented OPT RR RDATA format from 1999 [1][2]. > That is actually an interesting point, for one very important reason: NONE of the OPT RR elements are zone file constructs. They are all metadata, typically established by the configurations of various implementations of DNS clients and servers (including authority servers and resolvers). So, you are actually making the point for me, that the wire format of something that isn't a zone file component, can be complex and trivial to parse. We agree on this completely. The TLV aspect is well understood, and a component of many protocols (e.g. BGP, another protocol I'm actively involved in via the IDR WG). Having complex records in zone files is unwise, if it is not strictly required. The question was raised, as to whether that format is strictly required, and I think the consensus is that it is not. > > What you're describing here, an arrangement in which clients partition > RRSets into subsets and then reassemble bindings from those subsets, > strikes me as highly novel, in contrast, and somewhat more complex. > It is a simple table join using a single key. It was unabashedly ripped off from the RDBMS field of programming. Or actually COBOL, from the early 1980's. It's a hack, slightly clever maybe, but extremely simple and reliable. The requirement that each SvcParameter occur only once, is actually enforced directly via the 4-tuple uniquess criteria for DNS: owner, class, type, RDATA. If the RDATA consists of priority, enum, key, value pair, DNS enforces the uniqueness automatically. (This technically makes the semantic component of what would otherwise be a complex parser moot, and the syntactic part, the easy part, is all that needs to be implemented.) This also vastly simplifies the encoding/decoding of unknown RDATA, since the priority, enum, and key are numeric values of fixed size, leaving a single "value" component. The enumerator is the key (for the table join). The client does not need to check parameter uniqueness. It only needs to match up the enums to recreate the JSON of the objects in the array of structures (or regroup them into the OPT RR wire format if you prefer). This is the absolute simplest thing to code, and the absolute furthest thing from "novel". Its use as an encoding in DNS might be new, but it is the kind of thing that unit tests can handle trivially. So, to be clear, I'm only explaining the what and how, and maybe some parts of the why. I'm not in particular advocating strongly for using it, only presenting it as a viable option, for other folks to discuss the merits of. > > Perhaps complexity is subjective. The important thing is that the > standard be reasonably implementable. I hope that the list of published > implementations [3] will serve as convincing evidence that the current > draft is sufficient in that regard. > Implementable isn't the same as maintainable or simple to debug, or to confirm interoperability. This is particularly a concern across situations of zone file export, copy, and subsequent import on all of the other implementations. You may be underestimating the number of implementations. Switching to a zone file format that is simpler to parse would go a long way to improving those. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
