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

Joe Abley <> Tue, 11 May 2021 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E77D53A1D2D for <>; Tue, 11 May 2021 09:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J3nbSlDdDlFR for <>; Tue, 11 May 2021 09:20:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 628AD3A1D1E for <>; Tue, 11 May 2021 09:20:04 -0700 (PDT)
Received: by with SMTP id a22so18716722qkl.10 for <>; Tue, 11 May 2021 09:20:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZKmkRhboseVeu2dh7vdc03RYizKkXP9WmrjckMZLTRo=; b=BCIXui1klFjnV0qyRds/HmWssWjDisdTTHblu3XKN2YXxrEZDXddjo7irmVVecpGJQ OKtV/w0pc3WXxbhPID8K/T/T7wgxATYnmuLtFKWqHPasqYgQlm+F4MThSQMre52RGnu5 CtJMoX7AYoor0x04RKTdLnNn2TQvbMx7oDiMQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZKmkRhboseVeu2dh7vdc03RYizKkXP9WmrjckMZLTRo=; b=snGntU8oSOlPVBtufac2pJOOdqGZQs4nCsYM0mYngdDGOh7rYzNZwUDeeM0vqaP0d8 DyyYMjLm0U9gTh7KHZJ5hWmCcsTAkBE34adrPohmeKMagjGc9TRQTQK3SsvosKBYPM0o IWUfJla8417o1LS949uxCfDdm1pXSTn+O4fH5S7ItEVskiED/rP1GvI7EQNiVePMimy1 6XD9S9B3X1/ItLWOcKKKrH3jzHWgwcfIwLIFNNObv+Rh1d9uHUxgAc0v24onJSSt5194 /2wx0tJfWcUBLbkNdntzHSqMzR70lyogZOz3oSYAJeEMWs2N35Jie4fZHFb/ygoZ+ygf sNRw==
X-Gm-Message-State: AOAM5304zZu4GAyCyLtS6rMHXk6cX8M2VXRZnZO+ZZ50AOm1YXX3QeMg Mh9U3+5mFYsgcjMRgRk4BTzHc57SBgr1LVoQ
X-Google-Smtp-Source: ABdhPJxq5C9TAB0/F6zusWZWFx3C/X/SoUsci+t9GwnR7SXthBcj+afI/01meb+b6UMy6xV41mGDDA==
X-Received: by 2002:a37:a54b:: with SMTP id o72mr25963619qke.261.1620750002592; Tue, 11 May 2021 09:20:02 -0700 (PDT)
Received: from ([2607:f2c0:e784:c7:40a9:8726:f5fa:24d0]) by with ESMTPSA id m124sm14393530qkc.70.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 May 2021 09:20:01 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_338DC424-EB50-4866-BB2D-65AF002EABF8"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 11 May 2021 12:19:59 -0400
In-Reply-To: <>
Cc: "libor.peltan" <>, dnsop <>
To: Ben Schwartz <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
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: Tue, 11 May 2021 16:20:09 -0000

Hi Ben,

On 11 May 2021, at 12:08, Ben Schwartz <> wrote:

> OK, I've proposed text documenting the reasoning here: <>.

I definitely appreciate the effort, since I think I agree that documenting the design decisions are a good idea. However, I think perhaps the reasoning needs more work (see below).

> The proposed text is:
> Storing a key-value map within a single RR, rather than placing each key-value
> pair in a separate RR, provides the following advantages:
> * It enables a familiar key=value zone file syntax that matches zone authors'
>   experience with command-line arguments and other typical key-value mappings.

Since zone files generally don't include any key value pairs of the kind SVCB currently specifies, I don't understand this point. Surely the unfamiliarity with how to parse this kind of syntax illustrates that this is not familiar?

> * It avoids requiring zone file authors to manage inter-pair binding IDs.

I think you will have to expand that point, since I'm not convinced I understand what you mean.

> * It makes each record independently meaningful, consistent with the usual
>   convention for DNS records (c.f. SRV, MX, AAAA, etc.).

If you think of the DNS itself as a key-value store, with keys of the form (QCLASS, QTYPE, QNAME) then the corresponding value is an RRSet, not an individual resource record. Individual RRs are not returned in responses; RRSets are (understanding that the results are not functionally different in the case of an RRSet with a single member).

Your examples of SRV, MX and AAAA, somewhat ironically, are all prime examples of why the whole RRSet matters and you can't rely on a single RR from a set in a respose.

> * It saves at least 11 bytes of overhead per parameter by avoiding repetition of
>   the name, type, class, TTL, and inter-pair binding ID.

... but it inflates response volume in the case where a separate SvcParams RRSet is able to be cached significantly longer than the SVCB RRSet.

> * It provides a wire format whose structural nesting matches the logical scope
>   of each key=value pair, and avoids requiring cross-RR reconstruction of
>   bindings by the client.

This seems like it is documenting a design choice rather than explaining it. The decision to include a list of key-value pairs in the SVCB RDATA is good because it avoids having to do something different?