IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Wed, 17 June 2020 13:58 UTC

Return-Path: <marka@isc.org>
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 57C4B3A085B for <dnsop@ietfa.amsl.com>; Wed, 17 Jun 2020 06:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1eZ2nCXT4I5J for <dnsop@ietfa.amsl.com>; Wed, 17 Jun 2020 06:58:48 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 232E73A0859 for <dnsop@ietf.org>; Wed, 17 Jun 2020 06:58:48 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id EC08A3AB003; Wed, 17 Jun 2020 13:58:47 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D7605160046; Wed, 17 Jun 2020 13:58:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B19E0160060; Wed, 17 Jun 2020 13:58:47 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7M0kEONHcjB3; Wed, 17 Jun 2020 13:58:47 +0000 (UTC)
Received: from [172.30.42.89] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 3B784160046; Wed, 17 Jun 2020 13:58:47 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Wed, 17 Jun 2020 23:58:43 +1000
Message-Id: <5C631F12-C038-41D9-B8B9-C3BB98EF029F@isc.org>
References: <958b1059-a18c-7c01-1280-8deed67a5842@nic.cz>
Cc: dnsop@ietf.org, "knot-dns@labs.nic.cz Dns" <knot-dns@labs.nic.cz>
In-Reply-To: <958b1059-a18c-7c01-1280-8deed67a5842@nic.cz>
To: "libor.peltan" <libor.peltan@nic.cz>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pgQepJjuNEFbFIxOFvFLZF89Xq8>
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:59:02 -0000

Well 2 is a DNS requirement from the word dot.  I’m surprised any DNS developer would not know that. It allows records to pass through servers that don’t know the rdata fields structure. 

-- 
Mark Andrews

> On 17 Jun 2020, at 22:57, 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.
> 
> (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