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

Tony Finch <> Thu, 07 February 2019 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A33D4124BF6 for <>; Thu, 7 Feb 2019 08:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a8R-cMfxmiYd for <>; Thu, 7 Feb 2019 08:59:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5E9E1200D8 for <>; Thu, 7 Feb 2019 08:59:49 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:54390) by ( []:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1grn1e-000F4o-2V (Exim 4.91) (return-path <>); Thu, 07 Feb 2019 16:59:46 +0000
Date: Thu, 7 Feb 2019 16:59:46 +0000
From: Tony Finch <>
To: =?UTF-8?Q?Petr_=C5=A0pa=C4=8Dek?= <>
cc: Kevin Darcy <>,
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-2075598731-1549558705=:18720"
Content-ID: <>
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: Thu, 07 Feb 2019 16:59:53 -0000

Petr Špaček <> wrote:
> We (as developers in our office) all have had gut feeling that NS is
> mandatory but we could not find it in the RFCs.

There's this bit in RFC 1034 which discusses zone cuts and says the NS
RRset above and below the cut should be exactly the same. DNS admins are
generally too relaxed about allowing them to become inconsistent.

: The RRs that describe cuts around the bottom of the zone are NS RRs that
: name the servers for the subzones.  Since the cuts are between nodes,
: these RRs are NOT part of the authoritative data of the zone, and should
: be exactly the same as the corresponding RRs in the top node of the
: subzone.  Since name servers are always associated with zone boundaries,
: NS RRs are only found at nodes which are the top node of some zone.  In
: the data that makes up a zone, NS RRs are found at the top node of the
: zone (and are authoritative) and at cuts around the bottom of the zone
: (where they are not authoritative), but never in between.

See also RFC 1912 section 2.8:

   Make sure your parent domain has the same NS records for your zone as
   you do.

f.anthony.n.finch  <>
Dogger: West, backing southwest, 6 to gale 8. Moderate or rough, occasionally
very rough. Occasional rain. Good occasionally poor.