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

Pieter Lexis <> Fri, 07 May 2021 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FB913A18BD for <>; Fri, 7 May 2021 03:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lseTTKy9foAM for <>; Fri, 7 May 2021 03:21:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE4003A18BC for <>; Fri, 7 May 2021 03:21:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id DB1726A0CB for <>; Fri, 7 May 2021 12:21:12 +0200 (CEST)
Received: from ([]) by with ESMTPSA id e1sUNJgUlWC0RQAA3c6Kzw (envelope-from <>) for <>; Fri, 07 May 2021 12:21:12 +0200
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Pieter Lexis <>
Message-ID: <>
Date: Fri, 7 May 2021 12:21:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Fri, 07 May 2021 10:21:20 -0000

Hi folks,

On 5/6/21 10:16 PM, Dick Franks wrote:
> On Thu, 6 May 2021 at 19:11, Ben Schwartz <> wrote:
>> On Thu, May 6, 2021 at 8:50 AM Dick Franks <> wrote:
>>> BIND, NSD, and Net::DNS are all able to arrive at implementations of
>>> SVCB using the RFC1035 standard escape conventions, which demonstrates
>>> beyond reasonable doubt that recognising "\\," is not an essential
>>> requirement.
>> I disagree: what you are proposing is a deviation from RFC1035 escape conventions, and what the draft does is specifically to ensure that no such deviation is required.
> I am advocating strict adherence to RFC1035 escape conventions.  You
> are the one proposing to deviate.
>> ...  I have now encountered multiple codebases where modifying the RFC1035 char-string parsing in the way that you suggest would be prohibitively complex, and that complexity will only grow over time as new SvcParamValues are defined.>
> If the development cost is prohibitive, the obvious solution is to use
> BIND, NSD, or one of the other respectable implementations which are
> certain to be not far behind.  If Google cannot afford the license
> fee, a six line perl Net::DNS script could be used to translate
> RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.
, respectively).
> [...]
> That is no justification at all.   SPF people can do whatever they
> like within the arguments of a TXT record.

For PowerDNS, we treat the parsing of SVCParams as a two-step process.
First we use the normal rfc1035 character decoder on the full SVCParam
value, after which we apply the value-list parser. The former parses
'foo\\,bar' into 'foo\,bar' that is then parsed to a list of length 1
with value {'foo,bar'}. So nothing changes from the perspective of the
rfc 1035 parser.

I can see how this might be confusing to those writing zone contents and
would support a solution that either prohibits comma's in SVCParam list
values or a different value separator that is not allowed to be embedded
in values.


Pieter Lexis
PowerDNS.COM BV --