Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Brian Dickson <[e-mail]>]

On Tue, May 11, 2021 at 11:12 AM Ben Schwartz <bemasc=
[e-mail]> wrote:

>
>
> On Tue, May 11, 2021 at 10:32 AM Joe Abley <[e-mail]> wrote:
>
>> On 11 May 2021, at 12:32, Ben Schwartz <[e-mail]> wrote:
>>
>> > On Tue, May 11, 2021 at 9:20 AM Joe Abley <[e-mail]> wrote:
>> >> On 11 May 2021, at 12:08, Ben Schwartz <bemasc=
>> [e-mail]> 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