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

Ben Schwartz <> Thu, 13 May 2021 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A6B73A164F for <>; Thu, 13 May 2021 10:25:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bbfQjKrJmNCr for <>; Thu, 13 May 2021 10:25:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 521AA3A1681 for <>; Thu, 13 May 2021 10:25:26 -0700 (PDT)
Received: by with SMTP id b19-20020a05600c06d3b029014258a636e8so223737wmn.2 for <>; Thu, 13 May 2021 10:25:26 -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=AidsVoSqO4320ei/yU1HGcZ8U1wvpINDXUeTjA4xvBs=; b=v/ww73qdgt+q9jfU/28CVT40fOiid0BeTv9ITzFEm18nzk6CUfu0NB2yWXrFOEveGR +0rtcsJHpUIZ87HeYvB0sl40XWliWFlIg0gjynOcwXOP0922e8cqniBuWD6dgNbEJqJE 5YDlOXu3FNHfWL3irQTTDccJ90b+WguWqWIy0y+MIqjw3ktqNRP64p3eF9aeb081TE3K rzX3WUNxzi6M2Nt3v6Ti5QPTE0WrD6mGvIHPrVsjmiZkDEKVrilIKOOVRDd+viwGB9jy 7V7Bx1uRToHQ4XfVYLQo4eHtnsCEVdhhPcGmMOqNnpaL4gjSsKc/6KmjgFNghsEgcu4N ZTlQ==
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=AidsVoSqO4320ei/yU1HGcZ8U1wvpINDXUeTjA4xvBs=; b=MzyTopdZCKMM/bmOtr1Bl5aJAtm1KfNR20m1NJuxbqq1S6MCfZsvmVB+GWnlx3ltA4 q5rCam8ejWQ0/nBztDN0VViR97WgyDqQZTWaEShnc6Vy9Q9dMJUf83NgZKjcd2iP0CfR oobc8KhakhPC0T75FR9EJDOJ+YKa4WMvu3JXhng5qZ9R85aY9/uBJA/Vo6ePK3bvP8Cy 6J/Fl5MUtsKqNlEWc4Dhu+afcZUQMHfzKLGxup9Os3nXQ4ag+CRIyNB/HmgwEGMKl0II 80PvctjGJZD8StwIUQPFfidZrqcNIhDu8Gc0aXXfcbqa6jHQ3l/RvUsA/us1oyEO4PSJ 4ytQ==
X-Gm-Message-State: AOAM532X7YHPIWqCMynS7R5VFia+Cgp843FtMpXf2qGIIW2/eiTNO26b kR05Q/MJQPFFcMasmSEemMtxFP3GHb9+QxBJZboex1bZTxVzxA==
X-Google-Smtp-Source: ABdhPJwlj+9E2jX0ooLHxfCydMbRdefILLqfQY1DxMQKe7/qD0ldfXsCoQ5Mxl76nWaCEOLRjBWhK4aaaDdcJSSctrE=
X-Received: by 2002:a7b:c5d2:: with SMTP id n18mr4870511wmk.97.1620926723647; Thu, 13 May 2021 10:25:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 13 May 2021 10:25:11 -0700
Message-ID: <>
To: Brian Dickson <>
Cc: Eric Orth <>, dnsop <>, John Levine <>, Joe Abley <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000097bdcb05c2396951"
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 17:25:29 -0000

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

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

Ah, so you were comparing the difficulty of a complex parser (at the
authority) to combining data from RRs (on the client).

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.

SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
6763); it is not new to DNS users.

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.

It is not, at present, what any components do, and the current draft is
designed to keep it that way.

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

This is not the current draft's requirement.  The requirement is that each
key appear only once, to avoid conflicting values.

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.

I don't see any simplification.  The length of each value is explicit in
the TLV, so unknown keys are equally straightforward to handle.

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

The SVCB draft makes no mention of JSON, but I presume you mean any
application-specific representation of the service binding.  I understand
that it would be possible to reconstruct bindings from labeled records
spread across the RRSet in the way you're describing, but simply encoding
each binding into a record seems much more straightforward.

> This is the absolute simplest thing to code

Breaking the binding into pieces creates many new opportunities for error,
such as having multiple TargetNames in a single binding.  It corresponds to
a multimap datastructure instead of a standard map.  Every attribute of
each binding would naturally be an unordered collection, which is a bad fit
for attributes that are required to be singular, or an ordered list, or
anything other than a set.

Switching to a zone file format that is simpler to parse would go a long
> way to improving those.

Separating the binding into separate records transfers complexity from zone
file implementors to zone file authors, who must express a simple key=value
map by writing multiple records using explicit binding indexes.  For a
human reading a zone file, it is particularly difficult: a single binding
could be broken up into records separated across the zone file, with
surprising consequences if you forget to clean one up, typo a binding
index, or accidentally create an index collision between two bindings.

I continue to prefer the draft's current format.  It hews closer to DNS
tradition (wire format from OPT, zone file format from DNS-SD).  It avoids
the novel paradigm of cross-RR reconstruction.  It is not speculative,
having now been validated by at least a dozen full-production
implementations.  It is more efficient on the wire.

Considering alternative formats is an intriguing exercise, but I do not
think it is likely to result in improvements to SVCB.