On Tue, May 11, 2021 at 11:12 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote:
> > > On Tue, May 11, 2021 at 10:32 AM Joe Abley <jab...@hopcount.ca> wrote: > >> On 11 May 2021, at 12:32, Ben Schwartz <bem...@google.com> wrote: >> >> > On Tue, May 11, 2021 at 9:20 AM Joe Abley <jab...@hopcount.ca> wrote: >> >> On 11 May 2021, at 12:08, Ben Schwartz <bemasc= >> 40google....@dmarc.ietf.org> wrote: >> >> .. >> >>> * It saves at least 11 bytes of overhead per parameter by avoiding >> repetition of >> >>> the name, type, class, TTL, and inter-pair binding ID. >> > >> > ... but it inflates response volume in the case where a separate >> SvcParams RRSet is able to be cached significantly longer than the SVCB >> RRSet. >> > >> > It sounds like you're proposing a design in which the information in >> one SVCB record is not just spread across multiple records in an RRSet, but >> actually across multiple RRSets. >> >> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB >> RR becomes a pointer to a second RRSet with a different RRType. So the >> SvcParams information is spread across multiple records in a a different >> RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try >> again. >> >> Note that I'm not proposing a change to the spec, just illustrating that >> different design choices were possible that avoid the need for delimiters >> or escaping. >> > >> > This design choice, like many aspects of SVCB, was constrained by latency > and efficiency considerations. > I have a question (or maybe several) about the latency issue(s)... see below for context and the question(s). > > >> What are the concrete syntactical structure and the abstract conceptual >> structures? If those are terms of art I apologise; I'm not familiar with >> them. >> > > The concrete wire-format syntax is an octet sequence containing a > TargetName and some SvcParam key-value pairs. > > The abstract structure is a "binding" comprising a TargetName and a > key-value map that is associated with that TargetName. > Also related to the latency question(s) is (are) the questions about TargetName and associated values.... see below... > > What are you comparing the client implementation to in your final comment? >> What other design option was found to be more complex to implement on the >> client side? >> > > I was comparing it to designs where the TargetName and params are > separated into different RRs, or mixed into an RRSet with other bindings. > In such designs, the client must perform additional work to fetch, > associate, or reconstruct these different components that are encoded or > delivered separately but are only usable as a unit. > Here's where the related questions begin (and also include the client activities for fetching data, but also relate to publication of data being fetched....) I think there are design details (or maybe architecture is a better term) on the components of the binding, and the origin of those components, that is worth exploring in greater detail. I'll start with what I think are the relevant entities/parties, and how those relate to the HTTPS parts, and the DNS parts that support those (and for which the SVCB and HTTPS records are intending to improve). I believe the highest-level entities would be: - One (or more) Web hosting and/or CDN providers, which include some DNS components specific to the domain (the domain which is the owner name of the HTTPS record) - A DNS operator (either DNS hosting provider, or possibly the domain owner doing their own DNS) - From the perspective of a client, a DNS resolver (which may or may not have been upgraded to do anything special for handing of HTTPS or SVCB) - The client itself (web browser which is doing the appropriate queries including HTTPS or SVCB) If I understand things correctly, each Web hosting or CDN provider would supply the appropriate (corresponding) SvcParameters that are associated with the particular TargetName to the domain owner. Another way to put it is, the SvcParameters are actually bound to the TargetName, not the owner name of the HTTPS record, and the Web/CDN provider is (semantically speaking, not DNS-speaking) "authoritative" for those parameters. Is this accurate? So, the binding (of TargetName to SvcParams) is the thing that optimizes the HTTPS connections (e.g. H2/H3 etc), And, the placement of the binding parameters at the DNS record that references the TargetName, is an optimization to reduce DNS lookup latency. In the current design, the domain owner needs to, in effect, do a copy/paste from each Web/CDN providers' information into the domain owner's own DNS zone, including the TargetName and SvcParameters. The domain owner then would assign Priority values to each such record, thus prioritizing and/or balancing records provided by multiple Web/CDN providers. There is a potential for errors to be produced when the domain owner does this copy/paste. And the issue of managing any expansion of key,value pairs as different records in the RRset is the result of the copy/paste mechanism (i.e. copy/paste without having to understand or adjust any DNS record elements), and the potential for conflicting values from combining the records from multiple Web/CDN providers. I believe each TargetName still needs to be queried for A/AAAA records, although the "hints" from the SVCB/HTTPS records are (I believe) intended to allow the client to at least attempt to avoid the need for that query. The following would be very different from the existing SVCB/HTTPS proposal: - Publish SvcParameters as some sort of RRtype at (or below) each corresponding TargetName in the Web/CDN provider's own DNS zone - Or, have each Web/CDN provider publish a set of common parameters at some namespace within that Web/CDN providers DNS space, and have the SvcParams added to the HTTPS (or SVCB) record, by name rather than including the values. Either method (plus optional address hints) could reduce the complexity of what the domain owner would need to include, simplifying the parsing and allowing validation of names used (by doing DNS checks in addition to syntax checks). If the parameter sets were managed by the Web/CDN provider, and given a distinct DNS name (and referenced by name rather than value), the scalability of the bindings would likely improve, e.g. reference via CNAMEs (with the CNAME targets being long-lived and cacheable). This would also reduce or eliminate errors, by only having the SvcParams published by the party that is actually authoritative for them (i.e. the Web/CDN provider). The DNS latency issue is quite possibly a separate issue, depending on what the respective RTTs are for these different DNS relationships: - Client - Resolver (RTTc) - Resolver - Web/CDN DNS auth server (RTTw) - Resolver - Domain Owner DNS auth server (RTTd) I.e. if RTTc is small (local resolver near the client), and the cache is populated, I think the multiple-lookup thing becomes a non-issue. And, conversely, if RTTc is large, I think the wrong problem is being solved via adding SvcParams to the record in the domain owners' zone. I'm not sure if the latency changes much (or at all) if the resolver is HTTPS/SVCB-aware... These are observations and suggestions, hopefully helpful in keeping the conversation moving in a productive direction. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
