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) <kevin.da...@fcagroup.com > 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:ma...@isc.org] > Sent: Tuesday, February 09, 2016 6:35 PM > To: Darcy Kevin (FCA) > Cc: dnsop > Subject: Re: [DNSOP] DNS Delegation Requirements > > > In message <cd765f8368da465ea1078e20e77ea...@mxph4chrw.fgremc.it>, "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:dnsop-boun...@ietf.org 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:dnsop-boun...@ietf.org 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) > > <kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>> 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:dnsop-boun...@ietf.org<mailto:dnsop-boun...@ietf.org> > > 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 > > <d...@fl1ger.de<mailto:d...@fl1ger.de>> 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 > > DNSOP@ietf.org<mailto:DNSOP@ietf.org> > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org<mailto:DNSOP@ietf.org> > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
