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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 05 March 2015 04:43 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 889541A874C; Wed, 4 Mar 2015 20:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 vV4l13Ycn9WU; Wed, 4 Mar 2015 20:43:00 -0800 (PST)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 AC7D81A8742; Wed, 4 Mar 2015 20:43:00 -0800 (PST)
Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t254gx6v054592 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2015 21:42:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109]
Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_851F61D0-7820-4AA6-8FDE-F79559505C04"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b5
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <E537C710-56D4-4009-B495-E6781A42893E@piuha.net>
Date: Wed, 04 Mar 2015 20:42:54 -0800
Message-Id: <78A73ED3-BAAB-448F-A550-77F69535422B@vpnc.org>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca> <94F2C35A-95D1-41CA-9CA5-2F7D59111E0B@vpnc.org> <E537C710-56D4-4009-B495-E6781A42893E@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/bn_USpZePkNkjrkkCIonDcyOBZE>
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 04:43:01 -0000

On Mar 4, 2015, at 6:57 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
>> 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?

Oddly, that doesn't appear in any of the DNS-related RFC I know of. It is not in the "base" DNS RFCs of 1034 & 1035 & 2181, nor is it in 5966 (DNS use of TCP). Of the ~100 DNS-related RFCs that Standcore has reviewed in the DNS conformance testbed, RFC 1912 has the same wording about verifying UDP checksums without saying what to do if there is a verification failure, and 1995 has advice of what to do if the checksum is 0. Other than that, 2870 is the only other RFC that mentions UDP checksums.

Maybe there is a UDP-specific RFC that says what to do when you get a failed checksum.

--Paul Hoffman