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

John C Klensin <john-ietf@jck.com> Sun, 22 February 2015 13:32 UTC

Return-Path: <john-ietf@jck.com>
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 ED83E1A1B9A; Sun, 22 Feb 2015 05:32:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 8BT-1wchlCrB; Sun, 22 Feb 2015 05:32:37 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A598D1A1AC1; Sun, 22 Feb 2015 05:32:37 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YPWe8-000Lun-II; Sun, 22 Feb 2015 08:32:32 -0500
Date: Sun, 22 Feb 2015 08:32:27 -0500
From: John C Klensin <john-ietf@jck.com>
To: Mark Andrews <marka@isc.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
Message-ID: <19332445E29DABDB188C589E@JcK-HP8200.jck.com>
In-Reply-To: <20150221205119.F30E02A0BA40@rock.dv.isc.org>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca> <94F2C35A-95D1-41CA-9CA5-2F7D59111E0B@vpnc.org> <20150221205119.F30E02A0BA40@rock.dv.isc.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/HcbOj8M5Ul8sS0NuEViUFg6qpWc>
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: Sun, 22 Feb 2015 13:32:39 -0000


--On Sunday, February 22, 2015 07:51 +1100 Mark Andrews
<marka@isc.org> wrote:

>...

I'm not going to comment on the rest of this except to observe
that the Protocol Police (and associated judges and jails) have
been notably less available in the DNS area -- where many of the
TLD operator on whom you want to impose requirements not only
have a history of ignoring mandates but of being quite
articulate about their right to do so -- than in a variety of
others.

However...

> The last reserved bit in the DNS header should also be ignored
> if present in a query and not be present in the response.
> This is implied by RFC 1034 but not formally stated.  There
> are nameserver implementions that will drop such queries.
> There are nameserver implementions that will return FORMERR to
> such queries.  There are nameserver implementions that will
> return NOTIMP to such queries
> 
> Root nameservers should be a future proof as possible in their
> handling of queries.

If you want future-proofing, it is unwise to ignore any bit,
including reserved ones, unless you know in advance whatever its
implications are.  The requirement stated above changes the
status of that bit from "reserved, can be used for something in
the future if needed" to "reserved, can be used in the future
only for things that are safely ignored".  That is actually a
rather significant change.

     john