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

Brian Dickson <> Tue, 11 May 2021 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 246F03A2738 for <>; Tue, 11 May 2021 14:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8OLwnU1Aa7OX for <>; Tue, 11 May 2021 14:30:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EB8A3A273A for <>; Tue, 11 May 2021 14:30:56 -0700 (PDT)
Received: by with SMTP id h4so30777664lfv.0 for <>; Tue, 11 May 2021 14:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2gc8H+SgTwzMgSFFH05xIoYHDl72E8piEbsfHboqpWI=; b=Qv6W3IMd7KfV/f3Q1php2SbKieYSDtBtOhXH0PchjQDgxVu/kvQhGBZEQWW1gtJqLK uCeTCgdC0iwCVBAjd4Yb2zE7Z2I7QH8XMMU8r4xUxLtrKE1VB4tqCT08/cU6MNAD/TV8 8Vo6gg7ABtII6AghLRV6ACEiwAhgcSFxHlGuzp1uBvieYfNbNz19rG8vBkjGY6aRg5Po 04ZZ1E/JjzLT3VTcooyFyWWitz2GuvFdOs4k7LRxiR+wqLLQhEIgcGQU51wQOpFTAQ0s 6LJ2RtUTERkjD0hf7zyiPde7ztF/OjOFG+thSq/V+j7dw4So9/KxfiEbJ5kzclRxzn4Q Niuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2gc8H+SgTwzMgSFFH05xIoYHDl72E8piEbsfHboqpWI=; b=ibRzgyofNbs91LR7y7So5UpA0ugWcBd4zow5IBdJ5uyjLotuUlQNwJna2LyQMtcvua f9v1YIFai+7S2wbctdhse8S2K7/f7V8y2fqSNrVQMrhLO2MMGN5s+ZmpvgNqbLAT37ed /KVQuVJXNgtsf/Q4FWOL0IIKNbk/Td8aE4RP9WdJ1LGgv37k1cstHwZTKc2BUd7g6Ph6 7VVkWCWSAeA44cclapCPGKWUQJDEJQvf2YOc0/Dr/CXaigEU5Un9VEq5NpkY6ZuJmlJr YJdcU/fJ5V5a+1bDkODu5uyHGg01zWhIF8UaGd4oN8PcBYERVO7SzT5rfq0UdhMXF46R /6Yg==
X-Gm-Message-State: AOAM531NfswtP1jxQDkr07HHrFqPSWbbae77MfyWermNQT17egRpXdof 24lkmpEIaPAUwJ+a0dkH17OSTRyzpK2/m4Ho4lM=
X-Google-Smtp-Source: ABdhPJzNgn3l1iZfP+FVUVytDOo3vxkrmT20y5/gz/srFz1XuyaLIsbTFgVlaYADmOCVeOXnx7VFy0ujf9wG0Kso3Rk=
X-Received: by 2002:a05:6512:3f04:: with SMTP id y4mr23173398lfa.458.1620768649700; Tue, 11 May 2021 14:30:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 11 May 2021 14:30:37 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Joe Abley <>, dnsop <>, "libor.peltan" <>
Content-Type: multipart/alternative; boundary="000000000000a0eef905c2149b05"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2021 21:31:02 -0000

On Tue, May 11, 2021 at 11:12 AM Ben Schwartz <bemasc=> wrote:

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

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

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

These are observations and suggestions, hopefully helpful in keeping the
conversation moving in a productive direction.