Re: [DNSOP] DNS Delegation Requirements

Patrik Wallström <pawal@blipp.com> Mon, 08 February 2016 13:22 UTC

Return-Path: <pawal@blipp.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB681B2AC9 for <dnsop@ietfa.amsl.com>; Mon, 8 Feb 2016 05:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.019
X-Spam-Level:
X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, MIME_HEADER_CTYPE_ONLY=0.717] autolearn=no
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 H-W0-Hvcp7VG for <dnsop@ietfa.amsl.com>; Mon, 8 Feb 2016 05:22:32 -0800 (PST)
Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA9F1B2AC6 for <dnsop@ietf.org>; Mon, 8 Feb 2016 05:22:31 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_ED3ED500-AE1A-4D7B-8A38-01E8D71E3448"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.5.2
From: Patrik Wallström <pawal@blipp.com>
In-Reply-To: <CAN6NTqw=zkoMDxvyY0RN5PVe+2_WjYTdPW20utvmKC7vuqo+Yg@mail.gmail.com>
Date: Mon, 08 Feb 2016 14:22:24 +0100
Message-Id: <EA6C6B62-226A-4729-A7F4-46F15B78BD67@blipp.com>
References: <3A6EF5A0-928C-4F10-BD68-265DAE87F9A8@kirei.se> <CAN6NTqw=zkoMDxvyY0RN5PVe+2_WjYTdPW20utvmKC7vuqo+Yg@mail.gmail.com>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/LHS_QQXhwVYPVjTHDKNG2dqW0rw>
Cc: dnsop <dnsop@ietf.org>, Jakob Schlyter <jakob@kirei.se>
Subject: Re: [DNSOP] DNS Delegation Requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 08 Feb 2016 13:22:34 -0000

Olafur,

> On 08 Feb 2016, at 13:57, Ólafur Guðmundsson <olafur@cloudflare.com> wrote:
> 
> Jakob, Patrik
> thanks for writing this up, a great start.
> 
> On first read this document seems to be duplicating what is in https://tools.ietf.org/html/rfc1912
> It is hard to see what is new and what is the same.

Yes, some parts of it are duplicated. However, I believe it is clear that these two documents are very different in what they are. One could also argue that this draft is supposed to be a BCP, which 1912 is not.

> There are number of assumptions in the current draft, that only apply when the DNS contents  are distributed as zone in "files or axfr"  which not all operators use.

Yes. It would be useful to describe that AXFR is just one way to distribute a zone.

> There are few other examples of "rules" that show this document is written from a TLD's perspective which is different from what Domain operators may want to practice.

It is indeed written from a TLD perspective, but also what IANA requires for delegations at the root. But our hope is to make this a generic enough document that suits any part of the DNS tree.

> So before we start working on exactly what is in the current draft, can we have a discussion about what should be in the document.

We started with the assumption that most of the things we wanted to include was already documented in other RFCs, and thus already accepted by this community in some way. If the aim is to have a BCP we may go beyond this, but I think this would make it very hard for the working group to agree on the content. Yes, we need to have this discussion.

> For example the document omits all discussion on TTL's is that good/bad/separate ?

As the document comes from the work on Zonecheck, DNSCheck and Zonemaster, this is one of the things that none of these tools ever looked at. But if we can agree on that it is important to include, and on a recommendation, we will be happy to add it.

> Do we want to talk about how many addresses are associated with a name server name. (common practice is 1 A and/or 1 AAAA but will more work?)
> Are the "current" naming rules still something we want to promote, i.e. can we get rid of the Hostname rules from https://tools.ietf.org/html/rfc953

If we want to update RFC953, I think that would better fit in another document rather than this one.

> IMHO this should be a BCP candidate that obsoletes all prior guidance, no matter what RFC the guidance came from.

Thank you.