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

Tommy Pauly <> Wed, 19 May 2021 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBFB23A1F7A for <>; Wed, 19 May 2021 14:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 xzyzfuFiWZN8 for <>; Wed, 19 May 2021 14:12:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6179D3A1F6B for <>; Wed, 19 May 2021 14:12:55 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 14JL7P1j004253; Wed, 19 May 2021 14:12:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=rrUHAfbyeB7JUHs+2COpivDTIhbFhq5YFGDk5srbEfA=; b=RJMRB4Z+BF47cGT/1DajbvQt9C9fagceeDa5ijuXiiD6Fla6PEAq5TGxb1IoVINALa5r mEgsFaMYjfSJlS0GD7eSjSDyF+/DtOfgKesUVGQLKhabVVBWhtsg9RecRtWHFKvPS2N+ 4HQXcYDpAYzq/FykPA5LtxNDlt5rMYfFj0ri0QfCqq9BErLeTF19erZvH3b4I+Bp1HwK +6OaOTQY2XUrm7CDnJOvNf7ekAnpVd09QB+rHsgOvP4wYhhQpE7QsG9K3CLV8450veye N5alrNsi0Yil6DW5ypQS8FCpkNb6oFAfXISHqcw4gk04UfdrbcYqYWTTaNT/7DbyTLfP vg==
Received: from ( []) by with ESMTP id 38jbvc88ms-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 May 2021 14:12:51 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Dec 3 2020)) with ESMTPS id <>; Wed, 19 May 2021 14:12:51 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Dec 3 2020)) id <>; Wed, 19 May 2021 14:12:51 -0700 (PDT)
X-Va-T-CD: 099c7970583f17edb73a0ec0d35bcca0
X-Va-E-CD: 15cf04f9eac2eb842091974d83fbd438
X-Va-R-CD: d937fe06e0025caedf842e3d09b5492f
X-Va-CD: 0
X-Va-ID: 41b75345-3c2a-403f-adb2-491d1bf8e41b
X-V-T-CD: 099c7970583f17edb73a0ec0d35bcca0
X-V-E-CD: 15cf04f9eac2eb842091974d83fbd438
X-V-R-CD: d937fe06e0025caedf842e3d09b5492f
X-V-CD: 0
X-V-ID: 0c858126-247b-4929-8c1e-852d42a041dd
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_10:2021-05-19, 2021-05-19 signatures=0
Received: from (unknown []) by (Oracle Communications Messaging Server 64bit (built Dec 3 2020)) with ESMTPSA id <>; Wed, 19 May 2021 14:12:51 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_DE65596C-100A-431F-8C9E-ECFD995B6CFF"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 19 May 2021 14:12:50 -0700
In-reply-to: <>
Cc: Erik Nygren <>, dnsop <>, Ben Schwartz <>, John Levine <>, Eric Orth <>, Joe Abley <>
To: Brian Dickson <>
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_10:2021-05-19, 2021-05-19 signatures=0
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: Wed, 19 May 2021 21:13:07 -0000

> On May 19, 2021, at 1:34 PM, Brian Dickson <> wrote:
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly < <>> wrote:
> I wanted to chime in on this discussion as a client-side implementor who has already widely deployed support for SVCB/HTTPS.
> The current format, where the parameters are structured as a list within a single RR, is certainly simpler and less error prone for processing. Much of the information contained as parameters within the SVCB RR are useful for higher-level “application” logic. Within our deployment, the DNS stub resolver daemon receives the RR and does the parsing, and passes up the parameters bundle as a blob that is more or less opaque, to the layer that handles actual connection processing (doing happy eyeballs, protocol selection).
> Processing the content of SVCB parameters must be handled atomically: the ALPN, ECH config, and any other information must be handled clearly as a unit and not have any chance of being broken up. Lots of code is already based on processing RRs as chunks of data, and requiring anyone looking at the information to stitch the parameter list back together based on multiple RRs that must be in a particular order adds complexity and invites in bugs and errors.
> I’d strongly encourage sticking with the wire image we’ve already been using and deploying.
> Would it be accurate to say that as long as the wire format of both SVCB and HTTPS do not change, your client implementation(s) would not be impacted by any changes to zone file format?
> I.e. you don't implement any server code, so what the zone format is does not affect you, and how the wire format gets produced from the zone format is not relevant to you?

That’s correct. My main concern here is keeping the wire format consistent and simple. How the zone format file works is indeed something separate, and not something I have strong opinions on. Anything we can do to make the processing simple for both sides is great.

> Thank you for the details on how your client uses the wire format and the way those impact the end client systems.

Absolutely! Happy to answer any further questions as well.

> Brian