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

Petr Špaček <petr.spacek@nic.cz> Thu, 07 February 2019 16:05 UTC

Return-Path: <petr.spacek@nic.cz>
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 C2D4E129619 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 08:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.994
X-Spam-Level:
X-Spam-Status: No, score=-4.994 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 PwlEcrWkl-QC for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 08:05:29 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CD012008F for <dnsop@ietf.org>; Thu, 7 Feb 2019 08:05:29 -0800 (PST)
Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:2198:e685:86e1:b423]) by mail.nic.cz (Postfix) with ESMTPSA id 082FB633BA; Thu, 7 Feb 2019 17:05:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1549555527; bh=vu4C+Ys5ciM13BTBLvW+SsbZhyfCpMc0/Ys3kp3kMCc=; h=To:From:Date; b=ZgnidfvbDBHwskYmBGCsCFjajBxOza8x0iWExeXPUHxzF+DaC7TY0TCFAAnrXIbuw fzF0SX+0IUN7MJF8JZ3zZX6iJdfqgAhXAPA8vRFSUovfRRQwssvu3A97x3Kn5ZFFwk YHGxXCLs/xgxUvqwHtXlMeO8xEvCx3sPmyDTDGoo=
To: Bob Harold <rharolde@umich.edu>, Ted Lemon <mellon@fugue.com>
Cc: Tony Finch <dot@dotat.at>, IETF DNSOP WG <dnsop@ietf.org>, Kevin Darcy <kevin.darcy@fcagroup.com>
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>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ=
Organization: CZ.NIC
Message-ID: <8a7a70e4-7214-c127-8542-0131bbc823bc@nic.cz>
Date: Thu, 7 Feb 2019 17:05:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CA+nkc8BLA1wVSQ6DEbM7py98Rq94P-=XJtEBzcJAD9LOucN2Ew@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: cs
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SRe_2R1PW-9p09ZYsje5TI9EX2I>
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 16:05:34 -0000


On 07. 02. 19 16:48, Bob Harold wrote:
> 
> On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon <mellon@fugue.com
> <mailto:mellon@fugue.com>> wrote:
> 
>     On Feb 7, 2019, at 10:06 AM, Petr Špaček <petr.spacek@nic.cz
>     <mailto: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.
> 
>     I hate to say it, but we should really make sure that this is
>     actually stated somewhere where it can reasonably be found.   If it
>     is not, we should state it.   Petr was completely sensible to think
>     it was the case but not be sure.   Saying that it is the case, and
>     why it is the case, would be helpful.   This is something that I
>     hadn’t really thought through before Petr asked the question, but
>     I’d been wondering about it too because the question comes up in the
>     DNSSD Discovery Proxy code I’m working on (I assumed the answer was
>     yes).
> 
> 
> If we write it down, perhaps we should also mention that other things
> that answer DNS queries, like load balancers, should also return proper
> SOA and NS records, not just A and AAAA records,  for the same reasons.

Let's start with this:


-------- Forwarded Message --------
Subject: [Technical Errata Reported] RFC1035 (5626)
Date: Thu,  7 Feb 2019 08:04:27 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: iesg@ietf.org
CC: petr.spacek@nic.cz, rfc-editor@rfc-editor.org

The following errata report has been submitted for RFC1035,
"Domain names - implementation and specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5626

--------------------------------------
Type: Technical
Reported by: Petr Špaček <petr.spacek@nic.cz>

Section: 5.2.

Original Text
-------------
Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

   4. Information present outside of the authoritative nodes in the
      zone should be glue information, rather than the result of an
      origin or similar error.

Corrected Text
--------------
Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

   4. Information present outside of the authoritative nodes in the
      zone should be glue information, rather than the result of an
      origin or similar error.

   5. At least one NS RR must be present at the top of the zone.

Notes
-----
RFC 1034 Section 4.2.1 vaguely specifies that NS RRs are expected to be
found at zone apex but it is missing in the original algorithm above.
This erratum adds explicit requirement for NS RR at zone apex.

Even more importantly this expectation was built into subsequent RFCs,
e.g. RFC 2181 which would break if NS was present only in the parent
zone but not in the child zone.

References to dnsop mailing list:
- https://mailarchive.ietf.org/arch/msg/dnsop/ipwko314FenUxrdzMl5vcick9wQ
- https://mailarchive.ietf.org/arch/msg/dnsop/JAS6TREsOh-b2J4rEAND6cds0Og

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  can log in to
change the status and edit the report, if necessary.
--------------------------------------
RFC1035 (no draft string recorded)
--------------------------------------
Title               : Domain names - implementation and specification
Publication Date    : November 1987
Author(s)           : P.V. Mockapetris
Category            : INTERNET STANDARD
Source              : Legacy
Area                : Legacy
Stream              : IETF
Verifying Party     : IESG

-- 
Petr Špaček  @  CZ.NIC