Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

Jari Arkko <jari.arkko@piuha.net> Thu, 05 March 2015 02:57 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12D1A8AD1 for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 18:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 4Debd01eH6Xl for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 18:57:19 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 58A241A8ACD for <ietf@ietf.org>; Wed, 4 Mar 2015 18:57:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0026A2CC5D; Thu, 5 Mar 2015 04:57:18 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8hC86ePXdlu; Thu, 5 Mar 2015 04:57:17 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2EFB42CC4D; Thu, 5 Mar 2015 04:57:17 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_A4D1030A-9C6D-439A-9B26-5D05B149A13A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <94F2C35A-95D1-41CA-9CA5-2F7D59111E0B@vpnc.org>
Date: Thu, 5 Mar 2015 04:57:19 +0200
Message-Id: <E537C710-56D4-4009-B495-E6781A42893E@piuha.net>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca> <94F2C35A-95D1-41CA-9CA5-2F7D59111E0B@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/gDoWPvudZsTOL-SHr119ZVIZhk0>
Cc: IAB <iab@iab.org>, IETF Discussion List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2015 02:57:21 -0000

Hi Paul,

and thanks for your review.

> The requirements in Section 2 should be clearly stated as being appropriate only for the authoritative name service. The last bullet says this, but the first bullet says "MUST implement core DNS [RFC1035] and clarifications to the DNS [RFC2181]." That could be interpreted as saying that the root name service must follow all the rules of RFC 1035, not just those that apply to authoritative name servers, and there are a bunch that should not be required. Consider changing that sentence fragment to "MUST implement core DNS [RFC1035] and clarifications to the DNS [RFC2181], as an authoritative name service”.

I think this seems reasonable. Marc?

> Another bullet in Section 2 may be problematic:
>      MUST generate checksums when sending UDP datagrams and MUST verify
>      checksums when receiving UDP datagrams containing a non-zero
>      checksum.
> What happens if a root name server receives a UDP datagram with a bad checksum? It fails verification, but then what? This sentence *might* incorporate the following clarification, but I'm not sure if it actually matches the intent.
>      MUST generate checksums when sending UDP datagrams, and MUST
>      ignore a received UDP datagram containing a non-zero checksum
>      when that checksum does not verify.
> If that's not the intent, I'm not sure what "verify" means without a follow-on action.

I would not like to specify protocol in this document. It would be best if one of the referenced documents already said this, and we could simply add a reference. Do they?

Jari