Re: [DNSOP] DNS Delegation Requirements

[George Michaelson <[e-mail]>]

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
>