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

Joe Abley <> Fri, 08 February 2019 01:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1EF712D4F3 for <>; Thu, 7 Feb 2019 17:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gr5PcQ_qEkBe for <>; Thu, 7 Feb 2019 17:53:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABAA21274D0 for <>; Thu, 7 Feb 2019 17:53:37 -0800 (PST)
Received: by with SMTP id r6so5349573itk.0 for <>; Thu, 07 Feb 2019 17:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=r/+71ygfRG1kkvODpDYET4MBCWsLkav9ZShMrD0/q2M=; b=PZu+uGx4mkN3MmBo5EMUwtuI8QBi2ACmAxYyOgASMJmwEpoeAJhYMhaLMLc09efKWi IozuQhlqGOChaGbQn4yzgHPdlbzjZUcQpCMvf8D28zEyhVNH0ylPo8FbZk4vnA1ZnOhD qGx3cfd7HHXyq0n551d9hwh/CHkQttMynYGoQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=r/+71ygfRG1kkvODpDYET4MBCWsLkav9ZShMrD0/q2M=; b=jNjMwT9k/MivHCaQOi9PiDdlxT1JGu5eFWGHG3ow/KrIRUezK1RzOMs6ZtnHLardeG DNkm0yQLzxcz2+nWvW2M6a3ee4DVsg5bNUZMixfI5aaUawvLkBHJT1eMcAXHbBr+asPb UWlzUEskRGZ0dShhqi0EYqZ62kwXKJSzmJZUrX6hVYfF3R0QErM4vzhXUv45jH9Mc2yV +qz1px9SdpHdbwQL5Pl9fx7LLEUUkUV07vcDe/XsGeqWoW+WHUX1ppEReYqhVZiSPP7i MYP7N3p+SKm3EErgtVVADjpMcTgWmPiHqd/JQuCcF6Ay1X1pvcI6nPnIsEfm5nsQpEPh ED3w==
X-Gm-Message-State: AHQUAua7raO1MtHr1Nq2+teEWcVR+7YZMx7nJyK2vaodQwwgboHYUsV2 UNm0cEFKvG1UM7JR2hCWUMFCcpsgtEg=
X-Google-Smtp-Source: AHgI3IYBOD4BlKCi39Q4n85rgDhrZOxdk8/G95whcbfuYOHqk/MLUwSErp99UQuq0H6dLFKozYKl3A==
X-Received: by 2002:a05:660c:91:: with SMTP id t17mr5988744itj.41.1549590816853; Thu, 07 Feb 2019 17:53:36 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id f21sm567422itc.14.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 17:53:35 -0800 (PST)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0EBB4EC-C6EF-44CE-9DE0-F751F119E1D2"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 7 Feb 2019 20:53:34 -0500
In-Reply-To: <>
To: Masataka Ohta <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Feb 2019 01:53:40 -0000


On 7 Feb 2019, at 18:28, Masataka Ohta <> 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).

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.