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

Brian Dickson <> Wed, 19 May 2021 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD2DC3A1F7B for <>; Wed, 19 May 2021 14:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DLUrzpc063Dg for <>; Wed, 19 May 2021 14:21:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B0E13A1F7A for <>; Wed, 19 May 2021 14:21:07 -0700 (PDT)
Received: by with SMTP id i9so21203117lfe.13 for <>; Wed, 19 May 2021 14:21:07 -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=srAkGqLkGToJI+1hnZ7vguyjBoIKWfUAaSAYjwvjtDY=; b=RtOUJAQwMSSGrDOPqpu/Sv9Bp9PCWBfku3/FqpO0QB4zKbLfuiekrpPlBqjxIhNAlN ZAmVooR3iL5AZSKUxEII871Jkxw0vciY/j88UTuR8mBKqJGJQMteVLO9jRyBIuBpA4HE y4vApvDQHiM5Lg2sOSbRBco74Z23dBh6q4B4k1Q4H5nsOtMkPEn4m9abJBncMWu+QGI7 TZyQYCFjE38+I3c3Jw5A6MsxC2VOpUTw8z8th45UhZhlgYCAurSngpFqCdseWKIKc0w6 /txCpWBW0b1ufoCCT76xrOXjhxUlLVM4feWdHtsN5OSbmx3cr8DAlXnmNtT8YMbATA5z tojQ==
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=srAkGqLkGToJI+1hnZ7vguyjBoIKWfUAaSAYjwvjtDY=; b=AIWaIr2ai5P9W7Ef1hf9jEqH8OyAFVURKVbFWe9XIoMI4QoVjmMHe+4p42mJSJVYdT Lfr1BoVo3Q+9bQCBPvUp2+7b+PNwMDyfT5c4K4XZf9SWdjyiJzit9w0rVLhMzLtHamPl c4rOsfQmuykrqvgREqKF193/OJ31o9NMuGoSsNTi8q5V133Oj1LBdnRfuC2pgu719aPd UhmnmaWYTDRepGv1g66TpBqM2krVcB14edKixJce75znRzoClJNlV6zQMJcr7Y1vRKkC FqcCJikPVHsBw6WCiIa/bnrGatJ58MCyM5mQsBCZ5SgWKBtWxZTrSYmydrZohOyUzYwE w4tA==
X-Gm-Message-State: AOAM531MV1/v48qAI+Q1Sa2GWjD5sz6Xdf5jVOJGX3OT71nvMfxaw94P GsbrKdkOUOMZa/VvMskzcpZRTuuiQYAaTg/76aY=
X-Google-Smtp-Source: ABdhPJxQiQ4StTXtiPhw/xLPf9hrSoIuCXG3RAmajix4FkPRa7JuPJct/5pzmpoTPJyEwGIybQrvx7QZIdohzoe21PQ=
X-Received: by 2002:a19:f505:: with SMTP id j5mr1029272lfb.441.1621459264149; Wed, 19 May 2021 14:21:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 19 May 2021 14:20:52 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: Erik Nygren <>, dnsop <>, Ben Schwartz <>, John Levine <>, Eric Orth <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="000000000000751b2705c2b56751"
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:21:10 -0000

Given the request below to preserve the current wire format for both HTTPS
and SVCB, I think this raises some interesting options and questions:

   - My understanding of SVCB is that it is intended to be the "parent"
   type for both HTTPS and other future "mappings" over SVCB.
   - HTTPS is the first "instantiation" of an SVCB-compatible record type.

Given those two statements, would it not then make sense to separate out
the following:

   - HTTPS and SVCB zone file encoding schemes
      - HTTPS will be, in effect, "set in stone" by the whatever RFC
      defines it, and can have a zone file format that is tailored to the
      pre-defined parameters used for HTTPS (and excluding new HTTPS
      modulo an update to an HTTPS RFC)
      - SVCB should not be set in stone, and be extensible, and thus may
      have need for a more flexible zone file format
   - Regardless of whether the zone file formats differ, splitting the
   current draft into two drafts (one for SVCB and one for HTTPS) makes a lot
   of sense.
      - Updates to HTTPS should not require touching SVCB
      - RR-specific RFCs are the norm
      - Decoupling them removes any artificial constraints on their
      respective zone file formats
      - Overly-generalized RRs was one of the major problems with SRV, and
      we should take advantage of that lesson. There is no benefit to burdening
      the zone file format of HTTPS with general-purpose machinery.
      - Referencing the wire format of SVCB reduces the unique elements of
      an HTTPS draft, allowing it to focus on the things that make HTTPS unique.
   - The decision to split them into two drafts should not in and of itself
   depend on what the specific contents of the HTTPS draft (i.e. details of
   that draft) are.
   - Even if the HTTPS zone file format does not change, there is still
   valid reason to split them into two drafts.
   - This also provides a sensible template for future SVCB-compatible
   - Any potential for burning a code point for the early allocation for
   HTTPS should not automatically impact the code point for SVCB. Splitting
   the draft into two formalizes that, and reduces any perceived issues with
   causing a code point to be consumed by revisions to either draft.

I'll follow up with some more specific suggestions about the zone file
format for HTTPS.
I don't really have major problems with SVCB, as the use case I'm primarily
concerned with is HTTPS.
Also, vendor/operator support for HTTPS and SVCB should also be decoupled.
It should be anticipated that some vendors will support HTTPS but not
support SVCB.


On Wed, May 19, 2021 at 1:34 PM Brian Dickson <>

> 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?
> Thank you for the details on how your client uses the wire format and the
> way those impact the end client systems.
> Brian