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

John R Levine <> Thu, 13 May 2021 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F4BA3A05AC for <>; Thu, 13 May 2021 10:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=y94GsU2B; dkim=pass (2048-bit key) header.b=JJ47lgfM
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aGpdGfuSOfxp for <>; Thu, 13 May 2021 10:59:53 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D003A03EF for <>; Thu, 13 May 2021 10:59:52 -0700 (PDT)
Received: (qmail 91768 invoked from network); 13 May 2021 17:59:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=16676.609d6916.k2105; bh=r2b3aGDDLxYdP5qHLcBfqkBa3Mc7pZVOfDpx7EJA/Ys=; b=y94GsU2Bnl5TSYqKDxJyMcXFex9qhCg+tB1JzOHgQb/7+WXIvHYDP/limI6i5Bq0cHv5D5m1aUkY7p+3M9SuWTux8BFyPDmZU6AN6NiILxI711ZrkcGt/REj3NJ1h2edbN+0ZN5KFvK9GnNxVnC/kYOf0k9YsiggA5IWfs7WkHA3peTj3vMHdJw17IJPdmZPpCWQTeDvy96azAcVdCTNbdEVUfENyQ85ZIvsM1bzeMkskTa/91CM5RBh4WZK9GDdCBwajYlAfXLcZxnYjamJp30G79zcenxegVlRWh+bGgSJscIFSZYXIruXxHzRa1f64HFJ3LPJzZCecD6BQ2s6mA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=16676.609d6916.k2105; bh=r2b3aGDDLxYdP5qHLcBfqkBa3Mc7pZVOfDpx7EJA/Ys=; b=JJ47lgfMaL0WMQH3A0hB9ZZTg1QLDjbbnEomCrWPilyv+qn09oslqVs6kkEqhiGU7daTeBdMsbz30dseu5mFQI9XMTaYZ+s5YIwg9MHnZblngVe7JVdyfqRyNCUIU4biK9KUnwo2gHAdo7yoY0J6ViYQfnyqPDmDAdJfAbCJi1MfsU3HS88nSEtzHvcEqdI9D0gwvfYfghnj+6vzwJqcJTxoicIa2RN1NXJeXxsVUGcl+R+5UtBDmt77sdoM2bbMe9+6TEUGJeUXgBQ5jd9IsYEMlgN9W6+ScqB4obTPhy3gmxNWWh5zFYhMlYCyoiYAxMEFRq7Zca8GLGJOPUzE4Q==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 May 2021 17:59:49 -0000
Received: by ary.qy (Postfix, from userid 501) id 29DFA7BB470; Thu, 13 May 2021 13:59:47 -0400 (EDT)
Received: from localhost (localhost []) by ary.qy (Postfix) with ESMTP id 7B89E7BB452; Thu, 13 May 2021 13:59:47 -0400 (EDT)
Date: 13 May 2021 13:59:47 -0400
Message-ID: <>
From: "John R Levine" <>
To: "Ben Schwartz" <>, "Brian Dickson" <>
Cc: "dnsop" <>
X-X-Sender: johnl@ary.qy
In-Reply-To: <>
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
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:59:58 -0000

On Thu, 13 May 2021, Ben Schwartz wrote:
> SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
> 6763); it is not new to DNS users.

Hey, wait a minute.  DNS-SD just sticks the "key=value" strings as-is into 
text fields.  Now that I look closer, I see what Brian's objection is and 
I have a lot more sympathy for it.

No other RRTYPE has master file processing anywhere near as complicated as 

~>  - sort the SvcParams by key
>  - verify their uniqueness
>  - deal with list of fields nested in other fields (this includes the
> discussed comma escaping)~

If you put the SvcParams into text strings and let the client sort it out, 
I think the objections would go away.  This would mean that there could be 
zone files with semantically invalid SVCB records, yes, but that's nothing 
new, and the client has to check for that anyway.

Look at NAPTR.  It has a reputation for being very complicated but the DNS 
part is trivial, just a few numbers and strings.  The heavy lifting of 
regular expression matching all happens in the client.  If someone 
publishes a NAPTR with an invalid regexp, that's not the master file or 
server's problem.  It's something to catch at a higher level.

John Levine,, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.