Re: [DNSOP] DNS Delegation Requirements

["Darcy Kevin (FCA)" <[e-mail]>]

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]