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
