[DNSOP] normative language in BCPs Re: DNS Delegation Requirements

[Suzanne Woolf <[e-mail]>]

(no hats)

George,

I've been thinking about this post, and this general topic, for quite some time, and I think I have a coherent answer, but the WG needs to weigh in. Generally speaking, I think it deserves more attention than it's gotten from us, which is why I'm writing now.

I think I'm actually OK with normative language in an operational document, *if* that document is intended to be a BCP.  A BCP RFC gets more scrutiny than an Informational one under IETF process; it's supposed to be an IETF consensus document just as a standards track document is; and at least to my mind, it's thus defensible to use more prescriptive language. 

RFC 2026 Section 5, which talks about BCPs, seems consistent with this approach.

In the case of a BCP, there's also a sensible answer to your question about consequences of violating a MUST: The violation of a MUST in a protocol document means that the implementation isn't compliant with the protocol specification, and may not interoperate with other implementations that do comply. I think a similar argument can be made for what it means to be compliant with an operational BCP.

With that said, RFC 2119 is also pretty cautionary about being careful in the use of MUSTs and SHOULDs: it suggests staying away from those terms unless there are identifiable consequences to violating them, i.e. they're not just expressing an aesthetic preference.

This draft was posted with an intended status of Informational. I'm interested in what the authors and the WG would think of it as a BCP.

The no-response draft has a similar issue IMO, in that it's quite prescriptive about what a certain set of players (TLD operators) should do about identified problems, and silent on advice to anyone else (registrars who have customer relationships with domain owners, DNS hosting operators, DNS implementers,….)

I think the other way to frame the use of strongly prescriptive language in this document would be to leave the intended status at Informational, and introduce it as an example of what some operators consider good practice in setting up their delegations, without claiming general applicability.

Comments?

thanks,
Suzanne



On Feb 9, 2016, at 7:14 PM, George Michaelson <[e-mail]> wrote:

> its maybe me, I'm having a bad (no?) hair day, I need more caffiene.. but this feels like a "oh can't we just stop" moment.
> 
> MUST in protocols terms is good: its proscriptive, definitive language around on-the-wire.
> 
> MUST in operations terms is getting way off IETF charter, even with an ops focus.
> 
> waddaya gonna do if I don't do the MUST? you gonna blacklist me? you gonna forbid applications to flow?
> 
> I feel like capitalized normatives in operational recommendations is a big mistake. 
> 
> Sure, by all means lets recommend "please: don't put your authoritative NS eggs in one AS basket" but MUST?  MUST we? must WE?
> 
> -G
> 
> On Wed, Feb 10, 2016 at 9:39 AM, Darcy Kevin (FCA) <[e-mail]> wrote:
> True, the MX case falls within the intersection of DNS and SMTP standards, and thus must conform to the naming restrictions of both. That was a bad example and I shouldn't have cited it.
> 
>                                                                                         - Kevin
> 
> -----Original Message-----
> From: Mark Andrews [mailto:[e-mail]]
> Sent: Tuesday, February 09, 2016 6:35 PM
> To: Darcy Kevin (FCA)
> Cc: dnsop
> Subject: Re: [DNSOP] DNS Delegation Requirements
> 
> 
> In message <[e-mail]>, "Darcy Kevin (FCA)" writes:
> > Thats a very good catch. Restrictions on *hostnames* are different
> > than restrictions on *domain*names*. The language below, from RFC
> > 2181, Section 11 (incorrectly cited as RFC 2182, Section 11, in the
> > draft; but RFC 2182 has no Section 11), should be controlling, and the
> > other references (to RFCs 1035, 1123) should be discarded, since they
> > refer specifically to *hostname* (not *domain*name*) restrictions,
> > and/or are ambiguous as to whether they apply to hostnames or domain
> > names. The reference to RFC 3696 should be discarded also, since it is
> > only an Informational RFC, and defers to the others (1035, 1123 and
> > 2181) as authoritative (and in any case, makes an explicit exception
> > for names that are normally not seen by users).
> >
> > --- RFC 2181, SECTION 11 ---
> > Occasionally it is assumed that the Domain Name System serves only
> >    the purpose of mapping Internet host names to data, and mapping
> >    Internet addresses to host names.  This is not correct, the DNS is a
> >    general (if somewhat limited) hierarchical database, and can store
> >    almost any kind of data, for almost any purpose.
> >
> >    The DNS itself places only one restriction on the particular labels
> >    that can be used to identify resource records.  That one restriction
> >    relates to the length of the label and the full name.  The length of
> >    any one label is limited to between 1 and 63 octets.  A full domain
> >    name is limited to 255 octets (including the separators).  The zero
> >    length full name is defined as representing the root of the DNS tree,
> >    and is typically written and displayed as ".".  Those restrictions
> >    aside, any binary string whatever can be used as the label of any
> >    resource record.  Similarly, any binary string can serve as the value
> >    of any record that includes a domain name as some or all of its
> > value
> >
> >    (SOA, NS, MX, PTR, CNAME, and any others that may be added).
> > --- END QUOTE ---
> >
> > (Nota bene the reference to any binary string being legal as the value
> > of an NS record  how can that be compatible with subjecting
> > delegations to hostname rules?).
> >
> > Now, if a particular *registry* wants to put additional restrictions
> > on the names it will delegate, then thats another matter, but IMO
> > outside the scope of this draft.
> >
> > In practice, it is quite common to delegate subzones whose only
> > contained leaf RRs are of type SRV and thus *must*, according to the
> > naming conventions of SRV, contain underscores in their FQDNs. As long
> > as those zones contain no hostname records, this is perfectly legal
> > and acceptable, according to current standards, and I see no
> > compelling reason to disparage or mark as defective, the delegation of such domains.
> > Although much rarer, some zones might only contain MX records, and/or
> > some other record type(s) which is/are not considered to represent a
> > hostname, _per_se_.
> 
> Mail domains have exactly the same syntax requirements as hostnames.
> 
> If you see a MX record w/o a LDH owner then it is not being used for a mail domain or it is there in error the same way as A / AAAA without a LDH owner is not being used as a hostname or it is there in error.
> 
> Mark
> 
> >             - Kevin
> >
> > From: DNSOP mailto:[e-mail] On Behalf Of Jacques Latour
> > Sent: Tuesday, February 09, 2016 12:00 PM
> > To: Warren Kumari; Darcy Kevin (FCA); dnsop
> > Subject: Re: DNSOP DNS Delegation Requirements
> >
> >
> > Hi,
> >
> >
> >
> > Sent something relating to this on DNS-OARC this morning, but it seems
> > to be legit to have delegation for a _tcp.example.ca, which fails the
> > syntax requirements defined in section  8.1.  Illegal characters MUST
> > NOT be in the domain name".
> >
> >
> >
> > A delegation can happen to a valid domain name, not necessarily a
> > valid hostname.
> >
> >
> >
> > Zonemaster fails on delegations like _sips._tcp.cam.ac.uk
> >
> >
> >
> > # dig _sips._tcp.cam.ac.uk  ns +short
> >
> > rnb-uls2-jabber.phone.cam.ac.uk.
> >
> > cnh-uls2-jabber.phone.cam.ac.uk.
> >
> > wolf-uls2-jabber.phone.cam.ac.uk.
> >
> >
> >
> >
> >
> > Jack
> >
> >
> >
> >
> > From: DNSOP mailto:[e-mail] On Behalf Of Warren Kumari
> > Sent: February-08-16 6:51 PM
> > To: Darcy Kevin (FCA); dnsop
> > Subject: Re: DNSOP DNS Delegation Requirements
> >
> >
> > On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA)
> > <[e-mail]<mailto:[e-mail]>> wrote:
> > My 2 cents
> >
> > I dont think any DNS RFC should be tied to any specific element of
> > Internet routing technology. Keep it relatively generic and avoid
> > mention of ASes and the like, since this RFC may outlive the use of
> > ASes for Internet routing. Path diversity, link diversity,
> > network-level redundancy, those are all fine.
> >
> > That works too -- RFC 2182, 3.1. ? :-)
> >
> > W
> >
> >
> >
> >
> >                                               - Kevin
> >
> > From: DNSOP
> > mailto:[e-mail]<mailto:[e-mail]>
> > On Behalf Of Warren Kumari
> > Sent: Monday, February 08, 2016 9:21 AM
> > To: Ralf Weber; Jakob Schlyter
> > Cc: dnsop; Patrik Wallstrm
> > Subject: Re: DNSOP DNS Delegation Requirements
> >
> >
> > On Mon, Feb 8, 2016 at 2:00 AM Ralf Weber
> > <[e-mail]<mailto:[e-mail]>> wrote:
> > Moin!
> >
> > On 8 Feb 2016, at 9:57, Jakob Schlyter wrote:
> > > 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.
> > Thanks a lot for this work. I certainly would like dnsop to work on
> > this.
> >
> > I would soften some of language and have a question.
> >
> > 5.1. There are use cases where the serial number rarely if ever is the
> > same on all servers and it's only really used inside communication for
> > a given domain and not during resolution. So the only people who know
> > if a divergent serial number is a problem are the domain owners. So we
> > shouldn't tell the public that this is a problem. I would say that a
> > different SOA serial number could be seen as an indicator of an
> > inconsistent setup, but that further analysis is required to really
> > conclude that.
> >
> > 6.2 The name servers SHOULD NOT belong to the same AS I would drop
> > that requirement altogether or make it a MAY. We really should not
> > tell people how to build networks from the DNS world.
> >
> >
> > I think that the SHOULD NOT is actually correct here -- from RFC1771:
> > The use of the term Autonomous System here stresses the fact that,
> > even when multiple IGPs and metrics are used, the administration of an
> > AS appears to other ASs to have a single coherent interior routing
> > plan and presents a consistent picture of what destinations are
> > reachable through it.
> >
> > An AS is a "network", run by one organization. This means that there
> > is a monkey sitting somewhere making all of the routing decisions, and
> > sometimes monkeys screw up. Having a nameserver in an AS that is run
> > by a different monkey means that you need multiple monkeys messing up
> > at the same time0. Also, a significant amount of routing and traffic
> > engineering decisions are made at the AS level ("Meh, I'll local-pref
> > AS 42 down to move this traffic $there") - this means that sometimes
> > folk screw up and accidentally block access to some set of ASes - SIDR
> > may or may not make this more likely :-)
> >
> > This is *not* telling people how to build their network - it is simply
> > *suggesting* that they consider putting some net of nameservers in a
> > network run by someone else.  If you understand the implications of
> > putting all of your nameservers in one AS, good for you. If not,
> > chances are it's safer to put at least some elsewhere...
> >
> > W
> > 0: This (obviously) isn't really true, both ASs could share the same
> > upstream, router, etc. RFC 2182, 3.1. says it best:
> > "They should also be connected to
> > the net via quite diverse paths.  This means that the failure of any
> > one link, or of routing within some segment of the network (such as a
> > service provider) will not make all of the servers unreachable."
> >
> >
> >
> >
> >
> >
> > 8.7 We should point out here that neither an MX nor an A record are
> > required at the zone apex or do you want either of them mandatory?
> >
> > On the SOA settings I do have a question. Would the following SOA be
> > legitimate according to this draft?
> >         localhost. root.localhost. 1115106304 16384 2048 1048576 2560
> > If not why not, as my spot checking didn't find anything that made it
> > invalid.
> >
> > So long
> > -Ralf
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/dnsop
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/dnsop
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop