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

Normen Kowalewski <> Fri, 08 February 2019 09:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4D851288BD for <>; Fri, 8 Feb 2019 01:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4FFxUUeW1PQt for <>; Fri, 8 Feb 2019 01:28:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D9E9124B0C for <>; Fri, 8 Feb 2019 01:28:07 -0800 (PST)
Received: from [] ([]) by (mrgmx101 []) with ESMTPSA (Nemesis) id 0Lbi2Z-1hYGpR1jfH-00lBZO; Fri, 08 Feb 2019 10:27:58 +0100
From: Normen Kowalewski <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_01FE93E4-52B8-4526-A8BF-1AB7B89E1666"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 8 Feb 2019 10:27:55 +0100
In-Reply-To: <>
Cc: "" <>
To: Ted Lemon <>, Tony Finch <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
X-Provags-ID: V03:K1:hKh9fDbB3PGQ9qTvF+trqS0bWS1fZ1At5xETCJxGx/f1Iqj1vEk mKgF5esRoiIrHoApJovaSnMq9FwXZAan7TwkfvU230dDzvhm2NBo617ryIPITq6/DdCy6Vf lLWFtCBQM3/34HJ4DOMEG85xptgtVw5H475g1Uj/z0R32T1AYP+l/J43NBArIeV2XI4FcFK xDxIfLCj0LVPquyigFcNw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:qCz866fdovw=:j9RgJ60aeHbov1VTGH9klI LhV/xITV1rQyOAzfpdHtl3U/XxJIN4N30ylwHA/GlBRbSsm7a9ibbWFK/2oyp4hhTw+UGxM2g 7bi2CZIAB5OCfy+8O4kwjYDej1n1ZWGD+AWYoyzWT2fT1KQqocdYmuKcKiHGOOKwoTFwEPWAX 8MoTmMurHaTwk70ahaDLU6D8CG4u27w/oIWMUdMUVa5aQfVDAr5tTFm6vR7ThwDoT9e76tuYu GVdv8UIyudetgJeo+HT+mz0+fWPpksusXdmrNjEOTP5iRB/Kto8cjWN0mndFa454zc+YQD/u5 /2pLCWFcjbOv5bULcVrRsUJOFCgY81Kmq0mloMaIk8cX+zMrh2jKd8gJF8eZYjmWFnSzSlPOV ypw4s3F0At7+DEbGuWVz38B84UWgUWQdYy9JBOyZQzptLLTlrJdOyKcPtXnb41OYf1C5Wf3Lo Nji6sdLu9AP+adLX/k8VHObfKc7IsH693wcnZbmWGrBJ+VxGiK3IvCC5b97kVA1SSDN2tmd7x CwsPCQF1JrPuoQKebxPQRBgax9S+8v10XNWNgRESDoDM0ULoNqnuPIQyeuCW04XlzGTwg4xjI P8bOlQDzqAT7W/6yW5S/zJEctpPSZLFkUUISbgvOUmzVtKaP/VpgxW+OI+lujw5ssekmXWWf6 9IzZrMP6HUow9AixXV28CeWicBd3F6khiUOkg286E4mUZCASFxLQ3ObRStHPbHBln1jm5vmyO dFzw0l3eXuM7GAeSyoB3XQUr1C/oGPJCEgz56SG4kQ7AGtDlXDvwZIWhKlcNs18Gc4BZAAkb7 Ac4owQQJEY74UAm0JUp9HrrMiTRv6IrtJt92k1iplwyzSZe5yHwDgwfEuvjhABtFVOysIGBLu wXQjM04SM11m5tt2bXxw1HRbwdAmk9ibImL1ATcDSAV70eKR884Z8EUsUe+MFhSpJmUOChUZG pXjvxnOQm4g==
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 09:28:11 -0000

Hi Tony, Ted,

seem to not be  a DNSOP specific thing: Obviously the inherent understanding of what consensus is at the time of creation of the textual representation of that consensus may be still ambiguous at time of writing to some, however may also become ambiguous over time, in part because over time ALL originators of a text might no longer be reachable for questions, and also there may be no snippets of text that could be cited from WG mailing lists.

Feels to me like something is needed as a tool to augment this, something that can more formally represent what the consensus requirements and definitions indeed are. IMHO to grow the set of representations of DNS in form of a suite of RFC7950 YANG based models could help for many such clarification cases, completely independent from the general usefulness of gaining an interoperable representation of DNS related data. 


> On 7. Feb 2019, at 15:40, Ted Lemon <> wrote:
> On Feb 7, 2019, at 9:16 AM, Tony Finch < <>> wrote:
>> But in this scenario things soon go wrong, because RFC 2181 says the
>> NODATA reply replaces the delegation records in the resolver's cache. This
>> means that if a client explicitly asks for the NS records of a zone that
>> lacks them, resolution for other records in the zone will subsequently
>> fail.
> Ah, there you have it.   So then it _is_ required.   Kevin’s point also points in that direction.
> Is there somewhere in a later spec where this is stated explicitly, then?
> _______________________________________________
> DNSOP mailing list