Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Mark Andrews <marka@isc.org> Fri, 08 February 2019 02:06 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6F3130E25 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 18:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9TkhgnpANWG4 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 18:06:15 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 90362129AA0 for <dnsop@ietf.org>; Thu, 7 Feb 2019 18:06:15 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6BE3F3AB05B; Fri, 8 Feb 2019 02:06:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 53B9E160044; Fri, 8 Feb 2019 02:06:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3BF0B160066; Fri, 8 Feb 2019 02:06:15 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vznTL54mJvcP; Fri, 8 Feb 2019 02:06:15 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 08DAF160044; Fri, 8 Feb 2019 02:06:13 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <7751AB0C-F738-4270-9C7E-2937F773187F@hopcount.ca>
Date: Fri, 8 Feb 2019 13:06:10 +1100
Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B4B9C25-F2CF-43D3-B0CC-64E7D7CA7D6C@isc.org>
References: <fcd790a2-414b-491e-01e2-9aa92f7b1c4e@nic.cz> <CAAeHe+xySnrvpD4-nhi3T0qiEmz8h0ZNUE_2kie7ctq8YPGRPA@mail.gmail.com> <56839e19-afe9-df4b-d432-09a949cc658c@nic.cz> <06E02AB3-5E3B-4E1F-9B23-BB0810F73B66@fugue.com> <CA+nkc8BLA1wVSQ6DEbM7py98Rq94P-=XJtEBzcJAD9LOucN2Ew@mail.gmail.com> <8a7a70e4-7214-c127-8542-0131bbc823bc@nic.cz> <dc68fa90-0d4c-b9d6-09cb-eec55b9f9077@necom830.hpcl.titech.ac.jp> <7751AB0C-F738-4270-9C7E-2937F773187F@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B--AojWZu_E_b3Y8YOCbZxpOQxI>
Subject: Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2019 02:06:17 -0000

> On 8 Feb 2019, at 12:53 pm, Joe Abley <jabley@hopcount.ca> wrote:
> 
> Ohta-san,
> 
> On 7 Feb 2019, at 18:28, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
> 
>> Petr Spacek wrote:
>> 
>>>    5. At least one NS RR must be present at the top of the zone.
>> 
>> At least two.
> 
> With respect, I think the protocol requirement is at least one, not at least two.
> 
> I think best current practice is to avoid single-points of failure with the set of servers used to provide authoritative answers, and I agree that in many cases this is codified in user interfaces and registry policy as requiring two NS RRs. However, there is no shortage of such multiple RRs that refer to a single subnet or even a single instance of a nameserver process (so "at least two" is sometimes insufficient), and its perfectly possible to use anycast or both A and AAAA RRs attached to a single nameserver name that provide useful much more useful diversity than those degenerate two-NS implementations (so "just one" could in some circumstances be adequate).

A single anycast server DOES NOT and never can provide diversity from the client’s perspective.
Additionally multiple servers in the same /24 (IPv4) or same /48 (IPv6) should be treated as a
single server for diversity testing as these are accepted longest accepted prefixes.

> RFC 7108 describes the implementation of a method that includes a single point-of-failure by design (see discussion of IDENTITY.L.ROOT-SERVERS.ORG in section 5).
> 
> In short, this is an operational question with multiple answers and I don't like the idea of formalising an over-simplistic restriction in the protocol specification.
> 
> 
> Joe
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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