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

Mark Andrews <marka@isc.org> Thu, 05 March 2015 04:25 UTC

Return-Path: <marka@isc.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 C69FC1A8F50 for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 20:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 NsKGzSbkDVOo for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 20:25:28 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8BA1A8F3B for <ietf@ietf.org>; Wed, 4 Mar 2015 20:25:28 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1727F1FCC85; Thu, 5 Mar 2015 04:25:25 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8E5EA160055; Thu, 5 Mar 2015 04:32:24 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 59D75160050; Thu, 5 Mar 2015 04:32:24 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 503032AEE91B; Thu, 5 Mar 2015 15:25:20 +1100 (EST)
To: Jari Arkko <jari.arkko@piuha.net>
From: Mark Andrews <marka@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> <19332445E29DABDB188C589E@JcK-HP8200.jck.com> <20150223004033.726752A206EE@rock.dv.isc.org> <20150225154520.GD3297@mx1.yitter.info> <20150227002650.B8A5B2A6ADE8@rock.dv.isc.org> <B42E8628-7F12-40F4-B74C-598116D0AF17@piuha.net>
Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
In-reply-to: Your message of "Thu, 05 Mar 2015 04:56:49 +0200." <B42E8628-7F12-40F4-B74C-598116D0AF17@piuha.net>
Date: Thu, 05 Mar 2015 15:25:19 +1100
Message-Id: <20150305042520.503032AEE91B@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/tgGThRzsQ4AOf8T2xeMPV7YUXD4>
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:25:30 -0000

In message <B42E8628-7F12-40F4-B74C-598116D0AF17@piuha.net>, Jari Arkko writes:
>
> >> If that is something you want, this document is certainly not the
> >> place to do it.  That's a protocol specification change, and this
> >> document is not altering the DNS protocol in any way.
> >>
> >> Best regards,
> >
> > Well reflecting back the bit isn't permitted and requiring that
> > such queries get answered are parts of the existing specification
> > which are not being followed.  Requiring just these parts be correctly
> > followed will make future deployment easier.
>
> For what it is worth, I agree with Andrew that this document is
> not a protocol specification, and these other things belong
> elsewhere. And it seems you have a draft already, so...

There is follow the existing RFC and clean up ambiguities.  The
error code selection is cleanup.  The non reflecting of reserved
bit and correct EDNS behaviour are existing behaviour.  Expecting
root servers to follow the defined parts of the protocol should be
a no brainer.

The draft-andrews-dns-no-response-issue isn't formally changing
anything.  It is pointing out a real problem and it is requesting
that parent zone operators, in particular TLD and public SLD
operators, regularly audit the servers that they are delegating
namespace to for compliance and to report non-compliance even if
that has to go through a intermeditory.  It's also providing something
that the delegated zone operators / nameserver vendors can check
their servers with.

I'm not sure that it would be the best document to update RFC
103[45].  It would be scope creep to do so.  I think something more
like RFC 2181 would be more appopriate for that.  I don't mind
working on such a document.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org