IETF Logo Mail Archive

Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-https

Tommy Pauly <tpauly@apple.com> Wed, 17 June 2020 13:50 UTC

Return-Path: <tpauly@apple.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 17C8A3A08FD for <dnsop@ietfa.amsl.com>; Wed, 17 Jun 2020 06:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.582
X-Spam-Level:
X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.517, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 qRl-w2YqBHIK for <dnsop@ietfa.amsl.com>; Wed, 17 Jun 2020 06:50:31 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 092803A0861 for <dnsop@ietf.org>; Wed, 17 Jun 2020 06:50:25 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05HDi18x004522; Wed, 17 Jun 2020 06:50:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=2n1M2xpt4XkUgSXS6lj4QVwSNo3B3IGfaFndyC6Bobo=; b=nOt17Dehob+UWa4XSGPF3GX8Z2j0UCRj52wF1sgtQJ2iI8Crbx3uC4iK5JfYizlHO78o VcdE1S4+Si1NuYygs1FDjZvU2y/0vwncQg6/AHrqdFUILdMuvhoknM80XIFj3ui9tsEa NGM2NB2pvpTcvbf6IPM/Z1Q+KsTYOLQX6TNbBS9BwTOfmH4g5VYndO79FadI796WnPpf Qtv2lQCdYbqUaYulROfUfqEWTn1Fg7jU6GsNkyeGPvgj3lnHUrGT1vXfZTuTBY8N8amp A8CfeIfM9QAIkX9Fxrblk9LWx0MVv4cCBQEOFHG5hfCUtAf3YDEvu2idA4YS8qQiBhqP 2w==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 31q64adke8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Jun 2020 06:50:24 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QC200DE9P402460@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 17 Jun 2020 06:50:24 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QC200Q00OVX3I00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 17 Jun 2020 06:50:24 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 5185b61404c7ce616e644b88efd95798
X-Va-E-CD: ef18de64bb7cf7b1fb5565858cd80ca4
X-Va-R-CD: 18dbf33ffe8d90a644ff6da8f8a28636
X-Va-CD: 0
X-Va-ID: e123301f-703c-4546-96ef-88b66f52e8d6
X-V-A:
X-V-T-CD: 5185b61404c7ce616e644b88efd95798
X-V-E-CD: ef18de64bb7cf7b1fb5565858cd80ca4
X-V-R-CD: 18dbf33ffe8d90a644ff6da8f8a28636
X-V-CD: 0
X-V-ID: 968a0d8b-9d5f-4eae-b8b1-cd40324d9ded
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-17_04:2020-06-17, 2020-06-17 signatures=0
Received: from [17.232.179.160] (unknown [17.232.179.160]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QC200MB0P3Z3E00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 17 Jun 2020 06:50:24 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <958b1059-a18c-7c01-1280-8deed67a5842@nic.cz>
Date: Wed, 17 Jun 2020 06:50:23 -0700
Cc: dnsop WG <dnsop@ietf.org>, "knot-dns@labs.nic.cz Dns" <knot-dns@labs.nic.cz>
Content-transfer-encoding: quoted-printable
Message-id: <17DCAA83-4936-4458-AEE4-F2D66FC67AE8@apple.com>
References: <958b1059-a18c-7c01-1280-8deed67a5842@nic.cz>
To: "libor.peltan" <libor.peltan@nic.cz>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-17_04:2020-06-17, 2020-06-17 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IZHxzdQdyA2lpx-NfW8x79fAmac>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-https
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: Wed, 17 Jun 2020 13:50:37 -0000


> On Jun 17, 2020, at 5:10 AM, libor.peltan <libor.peltan@nic.cz> wrote:
> 
> Hi all,
> 
> i'm a developer of Knot DNS authoritative server. I have some comments on the SVCB draft and some suggestions for improvements. Just consider my thoughts and then do whatever is best.
> 
> (1) The format of SVCB (and HTTPS) RR is too complicated, especially for parsing presentation format to wireformat and back, including consistency checks. Perhaps instead of
> 
> www 3600 IN HTTPS 1 . alpn=h2 port=8443
> 
> It could be
> 
> www 3600 IN HTTPS 1 . alpn h2
>                   1 . port 8443
> 
> Which gives slightly bigger RRSet wireformat, but not by much.

I find this format suggestion to be far more confusing to read, since these really are key-value pairs, and the SvcDomainName and the SvcDomainPriority fields are shared across the different key-value pairs.

What specifically is too hard to parse in the draft’s format? Is that something that more clarifying examples can help with instead?

Tommy

> 
> (2) Paragraph 2.2 explicitly requires that SvcDomainName must not be compressed. Is there a reason? Especially when the response packets are large (and I expect that for SVCB they will), any compression helps.
> 
> (3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of a domain that has SVCB, AAAA, or A records" versus "SvcDomainName MAY be the owner of a CNAME record". What is the meaning here?
> 
> (4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 4.1 is too vague and I don't see what an authoritative (not recursive!) server shall answer in situation SVCB->CNAME->A (all in-bailiwick). Shall the CNAME and A be added to additional section? For comparison, in situation MX->CNAME->A we don't bother since this situation is forbidden (see RFC 2181).
> 
> (5) Wouldn't one octet for priority field be enough?
> 
> (6) There are not enough examples in the document. There are many variants of SVCB records, the formal ABNF description is difficult to read, and it would also illustrate what kind of services those records are designed to handle.
> 
> Best regards and thanks for your effort,
> 
> Libor Peltan
> CZ.NIC
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

v2.23.0 | Report a Bug | By Email