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

Eric Orth <> Thu, 13 May 2021 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A91FF3A105E for <>; Thu, 13 May 2021 08:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 QPFai5hDD5ot for <>; Thu, 13 May 2021 08:29:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 550DB3A105C for <>; Thu, 13 May 2021 08:29:21 -0700 (PDT)
Received: by with SMTP id i4so35226475ybe.2 for <>; Thu, 13 May 2021 08:29:21 -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=+Ll9hCW4vzXCsEYD3gVUYMtnR1heUngGq7cc+kPF3Aw=; b=Go/83T5Xggxz9fIddtbg8KA2J/fRFcftNy3Un2FJF3x24nLo3DAtnKf1Yn0m+eGBgy ghz1QZ19G0+DSQ5nt/u2O72knMVjOc/cZabOW/XoKpmkoptBdH0U4ewnVQg6x32qHKf+ yhhJgvedyPPLX+mFMBHwJO+XL3cQ/m7EBA4YGKB6HOwg/Fa2AU1KL/deLWNit4Ptd3sd HuLMBzlj8IgS39GTktn+wDvw2aX2+KSN0pKA1s7onxfwaxvr9dH+YPpYOUJo50er8END zF+qIncle0U3MP8jQ7+ui5l9I9KZ+vlpCVEw5NxwVDzh2lAxMQqNXm3EhIkJGYzX/TKd 4D4w==
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=+Ll9hCW4vzXCsEYD3gVUYMtnR1heUngGq7cc+kPF3Aw=; b=P7b12z/llRYh5s7a7+Eks5M2e29Ifxbdsmir53DnM167hqOFRNFpZEVnONvrE6w4bj hCfm2Na+BpPGjDS8q9juj5JP3NcOWzs+kBGpCgrRzD/U1nm6p8/U9tir6mI8TJj70asF Wbsf1gaLronzBaoT7AtkLjbOraWeVEpiT++xm5ZwS9q0TGrTVd04kIXVTe8BSyRDfM8B JIgcybD1QTwX7Aqoexpgulqz/4igTKdq4MAk9fxigjj+txB3c0OLgGYm1NMBaacbTsU4 K3g41bmf1y88OiP5QgkCgq9TqPIoIeGl/bvn43X+nTBL2i19ACmvMhbJFD5d82ajP88u POuA==
X-Gm-Message-State: AOAM530GJ1AQ4qw0eOsbE3dROnTHA9QUfftvCmEHB7rYyRDzHRrPXJa3 SZ/nWytLBHs+JUva6KCMWFCXmSBcRtEI6TPt1ty51w==
X-Google-Smtp-Source: ABdhPJwirtvLpiLKsKXLxKqEhX/m/trJyN/Y4xJsnyl2fIYNhRxWZ0pcir6jEYEVDm6RbdsDO+Zxtziy3xrBtWBO+K4=
X-Received: by 2002:a25:9745:: with SMTP id h5mr31610917ybo.36.1620919759653; Thu, 13 May 2021 08:29:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Thu, 13 May 2021 11:29:07 -0400
Message-ID: <>
To: Brian Dickson <>
Cc: Ben Schwartz <>, dnsop <>, John Levine <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="0000000000007c39de05c237ca4d"
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: Thu, 13 May 2021 15:29:24 -0000

On Thu, May 13, 2021 at 3:51 AM Brian Dickson <>

> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <> wrote:
>> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
>>> wrote:
>>> It is demonstrably more likely that a complex parser will have problems,
>>> than something that combines data from simple RRs in simple RRsets will
>>> have problems.
>>> (The history of SMTP is, I think, a good poster child for this, with MX,
>>> A, AAAA, plus DNSSEC and TLSA support in the clients, which are email
>>> transport things, not merely DNS things.)
>> The SVCB parameters' wire format is an extremely simple TLV arrangement;
>> I don't think "a complex parser" is required.
> This is an apples/oranges argument, the parsing complexity I'm referring
> to (I thought explicitly, but I guess that is too far up-thread) is the
> presentation (aka zone file) format.
> The initial opinions (not just mine) were that the format, while maybe
> familiar to HTTP implementers, is very un-DNS-like, and the proposition was
> that the complexity was not strictly necessary.
> While combining multiple simple records into a complex record, in wire
> format, would not be difficult, it is not what DNS authority servers do,
> and is not what resolvers do.
> But, the _wire format_ of the original proposed record is not at issue,
> and never has been, so I don't understand why you bring that up.

A lot of the recent debate here has delved into the fundamental structuring
of how SVCB info is divided into records.  That very much affects both
presentation and wire format.

I really prefer the current wire format over most of the suggestions in
this thread, but I don't really have any strong opinions regarding
presentation format.  Making presentation format split things into multiple
"records" but stitching it up into a single wire record isn't a reasonable
option, right?

>> It's also far from a novel design for DNS; in fact, it's identical to the
>> widely implemented OPT RR RDATA format from 1999 [1][2].
> That is actually an interesting point, for one very important reason: NONE
> of the OPT RR elements are zone file constructs. They are all metadata,
> typically established by the configurations of various implementations of
> DNS clients and servers (including authority servers and resolvers).

> So, you are actually making the point for me, that the wire format of
> something that isn't a zone file component, can be complex and trivial to
> parse. We agree on this completely. The TLV aspect is well understood, and
> a component of many protocols (e.g. BGP, another protocol I'm actively
> involved in via the IDR WG).
> Having complex records in zone files is unwise, if it is not strictly
> required.
> The question was raised, as to whether that format is strictly required,
> and I think the consensus is that it is not.
>> What you're describing here, an arrangement in which clients partition
>> RRSets into subsets and then reassemble bindings from those subsets,
>> strikes me as highly novel, in contrast, and somewhat more complex.
> It is a simple table join using a single key. It was unabashedly ripped
> off from the RDBMS field of programming. Or actually COBOL, from the early
> 1980's. It's a hack, slightly clever maybe, but extremely simple and
> reliable.
> The requirement that each SvcParameter occur only once, is actually
> enforced directly via the 4-tuple uniquess criteria for DNS: owner, class,
> type, RDATA. If the RDATA consists of priority, enum, key, value pair, DNS
> enforces the uniqueness automatically.
> (This technically makes the semantic component of what would otherwise be
> a complex parser moot, and the syntactic part, the easy part, is all that
> needs to be implemented.)
> This also vastly simplifies the encoding/decoding of unknown RDATA, since
> the priority, enum, and key are numeric values of fixed size, leaving a
> single "value" component.
> The enumerator is the key (for the table join). The client does not need
> to check parameter uniqueness. It only needs to match up the enums to
> recreate the JSON of the objects in the array of structures (or regroup
> them into the OPT RR wire format if you prefer).
> This is the absolute simplest thing to code, and the absolute furthest
> thing from "novel". Its use as an encoding in DNS might be new, but it is
> the kind of thing that unit tests can handle trivially.
> So, to be clear, I'm only explaining the what and how, and maybe some
> parts of the why. I'm not in particular advocating strongly for using it,
> only presenting it as a viable option, for other folks to discuss the
> merits of.
>> Perhaps complexity is subjective.  The important thing is that the
>> standard be reasonably implementable.  I hope that the list of published
>> implementations [3] will serve as convincing evidence that the current
>> draft is sufficient in that regard.
> Implementable isn't the same as maintainable or simple to debug, or to
> confirm interoperability. This is particularly a concern across situations
> of zone file export, copy, and subsequent import on all of the other
> implementations. You may be underestimating the number of implementations.
> Switching to a zone file format that is simpler to parse would go a long
> way to improving those.
> Brian