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

Warren Kumari <warren@kumari.net> Thu, 07 February 2019 23:37 UTC

Return-Path: <warren@kumari.net>
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 B1D0F130F12 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 15:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.102
X-Spam-Level:
X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 dW8ptVtUMCNc for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 15:37:28 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 A6017130F15 for <dnsop@ietf.org>; Thu, 7 Feb 2019 15:37:27 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id g67so1637022wmd.2 for <dnsop@ietf.org>; Thu, 07 Feb 2019 15:37:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gfLrLBAT2wUhBlyQVKD/xkL9LpwoNiId22PtXUXC4a8=; b=ee2ekq4SRThVLn0aNf3kPQJiivGjy5clDojxkHQuMScbDjTZrAgIZvvIYNG9UNYGT1 U4PzxbltRHKmxQmWBgOCe2kh1YpvEjWNOtkQXx6anR9td2xXDudSCklKyStrlAaj91q+ zJ6FRc1hKyMCU/E6a+8ru2CzJ6iRXIxII40Bme25xQle4bLZXgUxmR6cuRmVVJoNyVOE tQBVi2Rif+ecjpPeBr3PCkkUvJLggYr+0SqYPaFCf6A+KdnWUxyz1dfB8l6kMN+z+roX MxGgJ+FQRkTUA5fvlcn1qa2xRCjejbsZnXh76EUdcyevJ7tuhESAtk9isKu3BucUSVh9 3/mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gfLrLBAT2wUhBlyQVKD/xkL9LpwoNiId22PtXUXC4a8=; b=EELXLXDmCQlgQrMZoaUCVoypwuO30nMwTehPESPTX/y/JvmlkoLCLf2K6ph/SzhYus hTQdAQuqgEWmCfKhqCYALGxOlhUz594FFepqUw0nEPWjHrXvpYHppK9hQPinwT6aHpNr sR3qAxJYyqpXi1SOBXzsWI7o7JBfc1TaroTLUtVm0FqgLbL05giVriDLF5shFBGAfG4t DZhcZDJVEh3slfZH4/CeJOsXdEh3JJx6itItdgaDw9fHBo6thSj5NUxQ6W++IlKLjXc1 h7sUZCXQnYKoYp3szpWhV+hic+BG4w30dY1/JMPrhm1wSvl+0Vev+dZ5LWzY/KQQQUB5 PtJg==
X-Gm-Message-State: AHQUAuaZcqN2eqQBnZ89B/t+swTNBgTksGqrn0j/NeQFNfWK/jbZNiwI hjHGa3fY+1buz+gdOLUx3lbneSB1SnqNeGSEO6/96Q==
X-Google-Smtp-Source: AHgI3IaWlxvBZxfjhVJmt58dtCSgMs1iwpbr+Eqsnz6mNAvMIFM99HP16qFDAsvEGPAYXAqZyxHN+uuoH28KTS2eOos=
X-Received: by 2002:a7b:c853:: with SMTP id c19mr6793038wml.61.1549582645660; Thu, 07 Feb 2019 15:37:25 -0800 (PST)
MIME-Version: 1.0
References: <fcd790a2-414b-491e-01e2-9aa92f7b1c4e@nic.cz> <CAAeHe+xySnrvpD4-nhi3T0qiEmz8h0ZNUE_2kie7ctq8YPGRPA@mail.gmail.com> <56839e19-afe9-df4b-d432-09a949cc658c@nic.cz> <alpine.DEB.2.20.1902071648340.18720@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1902071648340.18720@grey.csi.cam.ac.uk>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 7 Feb 2019 18:36:48 -0500
Message-ID: <CAHw9_iLOmCY1QFY8c6phU1cpMgQx02EqYuGHZ94mPEhNvX+kEA@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>, dnsop <dnsop@ietf.org>, Kevin Darcy <kevin.darcy@fcagroup.com>
Content-Type: multipart/alternative; boundary="0000000000002525490581565386"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wPE6pboTXcSDkq1kHsCjQq6UzjY>
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: Thu, 07 Feb 2019 23:37:31 -0000

[ Top-post ]

So, I've been staring at the Errata which Petr submitted, and trying to
work out what to do.

I'd like to mark it as either Verified, but the errata process cannot be
used for fixing issues with the protocol itself, or adding additional
restrictions which may cause compatibility issues (otherwise we wouldn't be
able to have the fun of -bis documents :-)) -- so, what I'm trying to
figure out is if this was something where the was consensus  *when RFC1035
was published* (and just missed when writing the list), or if it is a
new(er) restriction.

I agree that it should be checked, but I really want to be able to point at
something in 1034 / 1035 which says this.
Tony's below is close, but not quite there yet - it says they should be the
same, but not that it is an error in the zone file (the section is "5.2.
Use of master files to define zones") if they are not. So, can y'all help
me find evidence *from this timeframe* that shows that this was viewed as
true at that time?

Otherwise, I should be able to make it "Hold for Document Update":
"Changes that modify the working of a protocol to something that might be
different from the intended consensus when the document was approved should
be either Hold for Document Update or Rejected. Deciding between these two
depends on judgment. Changes that are clearly modifications to the intended
consensus, or involve large textual changes, should be Rejected. In unclear
situations, small changes can be Hold for Document Update. "

W



On Thu, Feb 7, 2019 at 12:00 PM Tony Finch <dot@dotat.at> wrote:

> Petr Špaček <petr.spacek@nic.cz> 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.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Dogger: West, backing southwest, 6 to gale 8. Moderate or rough,
> occasionally
> very rough. Occasional rain. Good occasionally
> poor._______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf