Re: [DNSOP] DNS Delegation Requirements

[Shane Kerr <[e-mail]>]

Jakob,

At 2016-02-08 09:57:15 +0100
Jakob Schlyter <[e-mail]> wrote:

> As we've seen to good summary on requirements for on a well-behaved DNS delegation of a domain name, Patrik Wallström and myself has written an Internet-Draft [1] describing such requirements. The requirements were developed within the CENTR Test Requirements Task Force (TRTF) and m
ost of the original requirements and text originate from the Zonemaster [2][3] project.
> 
> At this point, we're seeking more public comments - on this mailing list (unless the chairs disapproves), on the our issue tracker [4] or via email to the authors.
> 
> 
> 	jakob
> 
> 
> [1] https://www.ietf.org/id/draft-wallstrom-dnsop-dns-delegation-requirements-00.txt
> [2] https://zonemaster.net/
> [3] https://github.com/dotse/zonemaster
> [4] https://github.com/CENTRccTLDs/TRTF/issues


Document structure
----

Just to be clear, the idea here is only to have really, absolutely
essential requirements? Because it seems like a mix of "just the
minimum" and "oh, here are some other things too".

I guess I kind of envision three levels:

1. Actual minimum requirements (SHOULD)
2. Strongly recommended requirements (MUST)
3. "-Wall" requirements, for people who want to know the Proper way to
   run DNS (a.k.a "Aussie rules" DNS operations)

In my mind, organizing the document in this order would be helpful. You
could have the same sections in each, such as "Routing" or "Zone
Contents" - the current set is probably fine.

This should make it easier both for authors - since it is clear what
is really, REALLY a requirement at all times. It should also make it
easier for operators and implementors, because you can start at the top
and then as you move on to softer requirements decide if they fit your
situation or not.


Specific requirements
----
Looking at the list, I see a lot of MUST requirements which seem too
strong for me:

6.3.  The name servers MUST have distinct IP addresses

Certainly this is not a MUST. Name server operations can happily
function like this, and I can possibly even think of reasons why this
might be easier if I squint my eyes and step back a bit. ;)

6.8.  SOA MNAME MUST be authoritative for the zone

Oddly the very first sentence uses SHOULD not MUST, which seems
appropriate. :)

7.1.  The DS Digest Type MUST be assigned by IANA
7.2.  The DNSKEY algorithm MUST be assigned by IANA

Both of these eliminate the chance for private (or public)
experimentation. For example, maybe I want to put in a DNSKEY RR that
uses some alternative crypto in addition to IANA ones. 7.2 forbids that.

8.4.  The SOA RNAME MUST not contain the '@' character
8.5.  The SOA RNAME MUST be a legal hostname
8.6.  The SOA MNAME MUST be a legal hostname

Breaking these rules happens all the time (mostly by mistake), and
nothing breaks. MUST seems too strong.

8.7.  The MX record in apex MUST point to a valid hostname

Getting this wrong will break e-mail, but I'm not 100% sure about MUST.

Cheers,

--
Shane