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

Brian Dickson <> Wed, 19 May 2021 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C29823A1E23 for <>; Wed, 19 May 2021 13:34:56 -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 GavMxzNJURd6 for <>; Wed, 19 May 2021 13:34:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3740A3A1E22 for <>; Wed, 19 May 2021 13:34:55 -0700 (PDT)
Received: by with SMTP id r5so21043401lfr.5 for <>; Wed, 19 May 2021 13:34:54 -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=lEW5Dj/vADNE0O8aW+2e9qugrEwqf0Knx6w5pnqB2nU=; b=o+ijf2gsNglmyynQ4k5iZ057wmiWX6jvpdJQwQzb4mbj4UFQMxV56SvwJhS9jLLaIK fhbWJmekJyR5huCMQ9rqyiUrNwh26sVdm0qvCJQzZleBPg3A5GK1kRAW2F2W4pIB54+l tYlDErIBwbiNdkL1yK8nkVNs4wJid6ExSV+T0z35MwXas5jG1FqHsjnGjl6Ll+c8tURg uk+v+8h9YIrw44uC+8NFA/GlZI+sRhMgdVwgMVV1HCP5TCXmNmXt49HBBcK+OXj1KaKv dGGt0l+iLygb9FlqcOny+b8j2IgyxhaCQpZ6RCwWJKYHqgy4IxS8n5dzQibZSnpwYhsR UZmg==
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=lEW5Dj/vADNE0O8aW+2e9qugrEwqf0Knx6w5pnqB2nU=; b=i4CHRMDe1Ncgs40F9+gt2/Fd+vXQ4EGi+yaNB0K7sPMZlEKFYZ61HEw7I7toWRXruI d7x2U2mTmJgX3T2R5NK9drtcPN0M1bbeq4bRbmJLO1GlidG97e+jeieSAa5bURbEDJ2m WLw//FXyfMSis8+YSuTV6JtbAOrrBJDvK3mnlL2WHaxRQpKl4m11KS0criuPDTg8+lee HrAeAuXdthkw19oVFP7FGQ73Cy2uF2E/K8zMjNU8LCACPezmokJPdyqvDPiRitncVm27 jtERmx8YGMAhR/7RSmpLkAHwX232xDShJ4wnalQuVQG3OLi8YFbMRq8vnP4Z3FZ0x4tz N90A==
X-Gm-Message-State: AOAM533UxsOu4ZntSZ5hZCDxWffSIwdM7bb2k8GlxahpnGYHO7Lro4km +ga3DXncVtZMG9Q2pqrRG08EcQm5HLS6Y3glIC4=
X-Google-Smtp-Source: ABdhPJw9/LPJ1BNn82sStjumiFiPmU395X6jmK7cGSfwuxnGCtNTHRN+clY6reGrofmRHp0weDb2g4rGIFaQE8IjBEY=
X-Received: by 2002:ac2:560b:: with SMTP id v11mr868268lfd.315.1621456491776; Wed, 19 May 2021 13:34:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 19 May 2021 13:34:40 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: Erik Nygren <>, dnsop <>, Ben Schwartz <>, John Levine <>, Eric Orth <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="0000000000003610ff05c2b4c23f"
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 20:34:57 -0000

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.