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

Joe Abley <jabley@hopcount.ca> Fri, 08 February 2019 02:16 UTC

Return-Path: <jabley@hopcount.ca>
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 7C7E2130E25 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 18:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 hFzJRCoSx0p5 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 18:16:51 -0800 (PST)
Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE471274D0 for <dnsop@ietf.org>; Thu, 7 Feb 2019 18:16:51 -0800 (PST)
Received: by mail-qk1-x741.google.com with SMTP id f196so779181qke.10 for <dnsop@ietf.org>; Thu, 07 Feb 2019 18:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ERETKD1ziwDuWkFe6o2KXa3XnNlTFMDoUhzJlSZIsfI=; b=R09RCXqJ/t5YFw/Trhzclhik7nfxlqz/JnwFmc+5E2NnKnAuiL+YVNsxdgUdK2Cccb gfWALxDIMRj/zkE9KS0oCisZMU1AnW5/n0hodaOxNX/kC4/LDYCVrPFiX1tKIAMnzm3b c+dbOn3wQUsbu8Jh7+SBMR0j/yuOIUyKu/48g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ERETKD1ziwDuWkFe6o2KXa3XnNlTFMDoUhzJlSZIsfI=; b=Po6pDkYnPJ3QCr6RRZ4Cl+c5b0g6MSwBdFbsukzlAaxM4xCb9AHUJ9bfzZahUayxlS i+hL0xvmnE0+AeMxcdEMxSoffqaxYgxG0vlAxp3boJNs0qqypY8lVth1R6PE+OQx/a79 McEy//iuHXfRCBTFhrHwDIJFjeNhfLFVQL8tEIG9obpULYF2c4dpgyN8W4uUS8TDe1Pt Htn6HOaTODFUVSkOanAge2mKx4ItYMP9T3i3hB2w/ptmxVw4hyFXlTGRLKf4iunF30T2 0RmDxRIacEsqQ8VnE2qqjANcPCRI0P4GDtov7zosRSDQD3ZoqRG0ngSyFzVrD/7SGRzd YtDg==
X-Gm-Message-State: AHQUAuYUkoR6jziP31mDtUIlTwUlBVUuFA9m/E/bmAAYKV2cqLjun0As HpQA5RqkgVeqLk6fMjuQ5JTyAg==
X-Google-Smtp-Source: AHgI3IZQUSrfwzoRbwS4wj7OXBBlZ9iaRfLtVNCjrrLIuBIDi4VY1zHzG2eNq94jwEgxyEvo33w5LA==
X-Received: by 2002:a37:657:: with SMTP id 84mr13429556qkg.86.1549592210575; Thu, 07 Feb 2019 18:16:50 -0800 (PST)
Received: from [199.212.90.100] (198-84-215-70.cpe.teksavvy.com. [198.84.215.70]) by smtp.gmail.com with ESMTPSA id e35sm687467qte.8.2019.02.07.18.16.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 18:16:49 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <2B4B9C25-F2CF-43D3-B0CC-64E7D7CA7D6C@isc.org>
Date: Thu, 7 Feb 2019 21:16:48 -0500
Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A3C20FC-CCA2-4902-9153-D4E7F696B9DA@hopcount.ca>
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> <2B4B9C25-F2CF-43D3-B0CC-64E7D7CA7D6C@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O1-s8aIecvhJ0I9L9VZz8SE_bDU>
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:16:53 -0000

On 7 Feb 2019, at 21:06, Mark Andrews <marka@isc.org>; wrote:

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

That depends on what you mean by "server" and how things are provisioned. It's not 1981 and there are many valid approaches for the removal of the outer feline layers.

I'll suggest that while recommendations and guidance about formulating a risk analysis are valuable outputs for this working group, absolute and broad statements are bet viewed with suspicion. No individual, no matter how well-informed and well-intentioned, can possibly know with certainty the complete situation of every relying party.

I think it's best for this working group to stick to what it's good at.


Joe