Jakob, At 2016-02-08 09:57:15 +0100 Jakob Schlyter <ja...@kirei.se> 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 most 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
