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

Pieter Lexis <pieter.lexis@powerdns.com> Fri, 07 May 2021 10:21 UTC

Return-Path: <pieter.lexis@powerdns.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB913A18BD for <dnsop@ietfa.amsl.com>; Fri, 7 May 2021 03:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lseTTKy9foAM for <dnsop@ietfa.amsl.com>; Fri, 7 May 2021 03:21:15 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4003A18BC for <dnsop@ietf.org>; Fri, 7 May 2021 03:21:15 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [82.161.33.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPSA id DB1726A0CB for <dnsop@ietf.org>; Fri, 7 May 2021 12:21:12 +0200 (CEST)
Received: from ananas.home.plexis.eu ([82.161.33.1]) by imap.open-xchange.com with ESMTPSA id e1sUNJgUlWC0RQAA3c6Kzw (envelope-from <pieter.lexis@powerdns.com>) for <dnsop@ietf.org>; Fri, 07 May 2021 12:21:12 +0200
To: dnsop@ietf.org
References: <161901308063.21005.875603362157576926@ietfa.amsl.com> <6245BB4F-4E2F-435F-ABC0-18C0420C8541@akamai.com> <CAHbrMsDGq0usDiqr0HtbFCR4Y8swtyv_0i7UOFf=C_ExW+0FNQ@mail.gmail.com> <303AD4A1-A9BE-4C31-B730-7B4D42587206@akamai.com> <CAHbrMsCj8OToEhjo7O0YkW4WGosGK7stBYTneYHUoX_KckY7Uw@mail.gmail.com> <80539395-F1F6-4BA1-8AFF-667DDF7604B1@icann.org> <CAHbrMsAC3Mb+e18Gv361XnCU3kBOWqCbUXPujuuqOULh4e-v=g@mail.gmail.com> <CAKW6Ri4Yi2v+owa7KABATBoRmEB9u0k_hxd235iDL0ngbGhuLA@mail.gmail.com> <B0F5B473-9A40-447D-9555-F549F54CE0B5@isc.org> <CAHbrMsDNUKzYC__R1z6yzt_9xxyp4Eov1FekumT9sDpFkmPVPw@mail.gmail.com> <CAKW6Ri6bybyLTZOPFjR=Gpus96OYz1_DcxsJe8r+K9u7z=_LXQ@mail.gmail.com> <CAHbrMsCgShoeTbSruFH_zigYtXEQEoEOihjE6kjSUmfW5VSVUw@mail.gmail.com> <CAKW6Ri6HWTv_7_qcJX5mnxJODfwGsDmc1X2UW4kxPi=ZfZBDcA@mail.gmail.com> <CAHbrMsCYFmmM+WfS8VQWfSvRQgp4wXHEsOJcHi3Nvunb++wuHg@mail.gmail.com> <CAKW6Ri6BPXPeb_jExwoUk2MNccCVTwPTZRahqSouEUcMeskA=g@mail.gmail.com>
From: Pieter Lexis <pieter.lexis@powerdns.com>
Message-ID: <aa9f870b-b3f1-ffa5-3a64-f5882e26e116@powerdns.com>
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: <CAKW6Ri6BPXPeb_jExwoUk2MNccCVTwPTZRahqSouEUcMeskA=g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/q3qNac5Mp3Uufm2tniZZgolCjAc>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 <bemasc@google.com> wrote:
>> On Thu, May 6, 2021 at 8:50 AM Dick Franks <rwfranks@gmail.com> 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.

Regards,

Pieter
-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com