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:[email protected]]
Sent: Tuesday, February 09, 2016 6:35 PM
To: Darcy Kevin (FCA)
Cc: dnsop
Subject: Re: [DNSOP] DNS Delegation Requirements
In message <[email protected]>, "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:[email protected] 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:[email protected] 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)
> <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>
> 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
> <[email protected]<mailto:[email protected]>> 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
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
