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

Lars-Johan Liman <liman@netnod.se> Fri, 06 March 2015 12:01 UTC

Return-Path: <liman@netnod.se>
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 F39A51ACDAC; Fri, 6 Mar 2015 04:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35] 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 zZHWD67q6HHC; Fri, 6 Mar 2015 04:01:39 -0800 (PST)
Received: from mail.cafax.se (mail.cafax.se [IPv6:2a00:801:11:53::4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9AF1ACDB6; Fri, 6 Mar 2015 04:01:38 -0800 (PST)
Received: from limac.netnod.se ([IPv6:2a01:3f0:1:0:129a:ddff:fe5a:d3f8]) by mail.cafax.se (8.15.1/8.15.1) with ESMTPS id t26C1Ynl005559 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Mar 2015 13:01:35 +0100 (MET)
Received: from limac.netnod.se (localhost [127.0.0.1]) by limac.netnod.se (Postfix) with ESMTP id 582E1A14D0C; Fri, 6 Mar 2015 13:01:38 +0100 (CET)
From: Lars-Johan Liman <liman@netnod.se>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
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>
Date: Fri, 06 Mar 2015 13:01:38 +0100
In-Reply-To: <E537C710-56D4-4009-B495-E6781A42893E@piuha.net> (Jari Arkko's message of "Thu, 5 Mar 2015 04:57:19 +0200")
Message-ID: <22wq2us5b1.fsf@limac.netnod.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.71 on IPv6:2a00:801:11:53:0:0:0:4
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/fLkc_zaIaqE4EM5Y_gXiv6B7k7w>
Cc: IAB <iab@iab.org>, Paul Hoffman <paul.hoffman@vpnc.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: Fri, 06 Mar 2015 12:01:41 -0000

jari.arkko@piuha.net:
> 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?

(Stepping in as "the other author".)

I agree it makes sense. I'm working on text for -03.

>> 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?

I agree to keep protocol spec out of this document. The document should
only refer to other documents and say "these (parts of) documuments
SHOULD/MUST be followed".

If there are docs that specify what a host should do with such
"malchecksummed" packets, I'm happy to put a pointer in there. If not,
I'd rather avoid discussing it in this draft.

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.               !  E-mail: liman@netnod.se
# Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#----------------------------------------------------------------------