Re: [DNSOP] DNS Delegation Requirements

[Mark Andrews <[e-mail]>]

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]