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

Brian Dickson <> Thu, 13 May 2021 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED2C23A2E09 for <>; Thu, 13 May 2021 00:51:16 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fx9qPQDG4azG for <>; Thu, 13 May 2021 00:51:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB97E3A2E08 for <>; Thu, 13 May 2021 00:51:11 -0700 (PDT)
Received: by with SMTP id h4so37417745lfv.0 for <>; Thu, 13 May 2021 00:51:11 -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=ThfOkRdyix/3ejkpc7qMZmD0S01nxKNybaxLKQKvMLQ=; b=dy2Hqp98Cp3q/Z+q89gkzOHiqfl0pmpKXPmv3JXGd3cXiWO31o9C6m256Nl+7GarDd 4RxwTidNU9/uFwZ/7mVyimZ6ZXgrepM89OPb8cB0vGdPk7S8QH6z0tgzafZy1nkWP6jk YvG7u7tqMgxIrJhBJpW3iiH0lCZ46UNdkUzSeDrRQkceK5Z5ztur6D4BONyHE8UtB3d9 5XYiYiLmlK+MUmT2g/EG7FiBQp7WMdKUeKlLt2NFSmO2cDmHaiWDaIF5+Cyhz0dNRFg4 cRBrBK53WF3xNmsW6U2dUROgHbxCWdJF4rlHdOOEgZfCfX2zJM7Qt82ic25zVbI8NfRM VDaQ==
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=ThfOkRdyix/3ejkpc7qMZmD0S01nxKNybaxLKQKvMLQ=; b=LBOdpp2x3BqpHtVYHrbJtBO+hD36Hj83Wtg+MyraPNA6otSqj85vpab06ZdFn+DFLK GBPghXvTHpyvQ9KCBzNNaDCLHEMsohVDakHYW20WEd6pr8litZFjXZhfOni2OlZpZaT4 yxhloZBE/6V/Ar2Bso495CS6vzirM+Tu9PWUafPDKwH3JGDAKDfULqKnc7QxjDS+Vfig pVg6FDPwEmBZutV6bpkBHIGRNXX/xuh7S5HNw8t4YDSO3RwNp8NqU8qx9P+QlBUKRORN GNhgCNzeVeZDqs5asDJHi52RHnLPKuTAYNy2rjgIfM4SrNIz8eoVJHh6yvgXIVyeZ0Gu RsOw==
X-Gm-Message-State: AOAM530c3FgCspLUE+U6KLPjw8E3ZD+7kw9QeSXOyyi4cKtiSqmeM3zg JRKfgY6P47VzfWpnZe08AwodxBuJ/N2TLnxUBFg=
X-Google-Smtp-Source: ABdhPJwfR3Nbb2yv4hsZDytKrhduL7ZlfLLxIyG566TMVIuaZLjGuhPsMseJhWGWJxauyPSfGoApxYKd9m7cj4d+q/w=
X-Received: by 2002:a19:48d3:: with SMTP id v202mr27299633lfa.315.1620892269505; Thu, 13 May 2021 00:51:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 13 May 2021 00:50:57 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Eric Orth <>, dnsop <>, John Levine <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="000000000000f177ac05c231631e"
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 07:51:17 -0000

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.

> 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

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
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.