Re: [DNSOP] DNS Delegation Requirements
"Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com> Tue, 09 February 2016 22:33 UTC
Return-Path: <kevin.darcy@fcagroup.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467F1B2D40 for <dnsop@ietfa.amsl.com>; Tue, 9 Feb 2016 14:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGdjN6yLeELP for <dnsop@ietfa.amsl.com>; Tue, 9 Feb 2016 14:33:17 -0800 (PST)
Received: from odbmap08.extra.chrysler.com (odbmap08.out.extra.chrysler.com [129.9.107.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF8B1B2D05 for <dnsop@ietf.org>; Tue, 9 Feb 2016 14:33:17 -0800 (PST)
Received: from shbmap09.shdc.chrysler.com (Unknown_Domain [151.171.73.109]) by odbmap08.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id AE.93.14941.C296AB65; Tue, 9 Feb 2016 17:33:16 -0500 (EST)
X-AuditID: 81096b24-f795b6d000003a5d-b3-56ba692c99cd
Received: from MXPA4CHRW.fgremc.it (Unknown_Domain [151.171.20.20]) by shbmap09.shdc.chrysler.com (Symantec Messaging Gateway) with SMTP id 6F.C0.17818.B296AB65; Tue, 9 Feb 2016 17:33:15 -0500 (EST)
Received: from mxph3chrw.fgremc.it (151.171.20.47) by MXPA4CHRW.fgremc.it (151.171.20.20) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 9 Feb 2016 17:33:15 -0500
Received: from mxph4chrw.fgremc.it (151.171.20.48) by mxph3chrw.fgremc.it (151.171.20.47) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 9 Feb 2016 17:33:14 -0500
Received: from mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701]) by mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1156.000; Tue, 9 Feb 2016 17:33:14 -0500
From: "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] DNS Delegation Requirements
Thread-Index: AQHRYk7Ej91R1ae/DkSoWf1yAzUWN58iPk2AgABI0wCAAAA7kIAAnwCAgAEfXgD//+wNsA==
Date: Tue, 09 Feb 2016 22:33:13 +0000
Message-ID: <cd765f8368da465ea1078e20e77ea06c@mxph4chrw.fgremc.it>
References: <3A6EF5A0-928C-4F10-BD68-265DAE87F9A8@kirei.se> <4C7298C1-4331-4953-881F-89C7BB3FED39@fl1ger.de> <CAHw9_iKDcqzW6NQkwyBh933=apjAqCDLKF7O60D5fmLm+PgLkg@mail.gmail.com> <e915c2c6f1b54b0188ee90eb753fbcb7@mxph4chrw.fgremc.it> <CAHw9_iLZfgGFTvjqXWDQvLdUUwpS-Ok3LKKzEbWqtsrQi+w==Q@mail.gmail.com> <C059877D829F76429F49E0B48705D888DDD21B4C@EXCH-01.CORP.CIRA.CA>
In-Reply-To: <C059877D829F76429F49E0B48705D888DDD21B4C@EXCH-01.CORP.CIRA.CA>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [151.171.20.218]
Content-Type: multipart/alternative; boundary="_000_cd765f8368da465ea1078e20e77ea06cmxph4chrwfgremcit_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUyfbVnrq5O5q4wg0cdMhZ331xmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqE7t5gLjnxgqnj2zamB8dszpi5GTg4JAROJR43L2CFsMYkL 99azgdhCApcYJf7+se5i5ACr2bDDp4uRCyh8klFi+oqNLBDOWkaJ76svssM5d8/MZYVwdjBK 7Pl0mxVkFBtQ+8Ird5lBbBEBKYlnsx6xgNjCAgYS629eZoOIG0q8Wvsayg6TeLLoDNh5LAIq Er2r34D18go4SbS8u8EMseA7k0Trs1OMIAlOAR+JNd8Ogi1jBPrh+6k1YM3MAuISt57Mh/pT QGLJnvPMELaoxMvH/1ghbAOJrUv3sUDYShLnV99khOjNlLiz+QETxGJBiZMzn7BAwkVVon/t S2h4zeSQ2LREYAKj9Cwk62YhaZ+FpH0WMCiZBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj +ypG6fyUpNzEAgMLvdSKkqJEveSMosrinNQiveT83E2MwOhv5MxW2cG4Zp7lIUYBDkYlHt7e 9F1hQqyJZcWVuYcYpTlYlMR5r8cChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCmxvw5JM6/ fUt1CW+2hIqhUsN7pmWf1+z+JnZkO4Pvz8Ql82Y5Oy/Udm6UfiFy71kY756/G/4cuhajEvbc 2a5M7JsyW4ZCqelh9SKlQ266qW2nX3ecejO5XMhm2gmugCuzCrP27O9SnjKP3Xuhzx/2HZ8L OVkEJN1rnyRMK5BWuzbFOzTkQbcSS3FGoqEWc1FxIgDn4Ngl3wIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA01Sb0gTYRzmvbttN/HkmlPfrTQ8FKbWnGSREGIiUSFRgfsghJ7u8oabjrtp 2icL7cMqFBGkpZg1QdxslplLLFACUSQVC/JvVlNTR0SUZpR2t8s/357f7/k9z/P+3vfFUdWK TIubS+wMV0JbKHkI1uhWq48mmfuMhpm2hJNzgUksA5x1uTaRiyA35JSJsZjLGS45PT+EHZyd Rm2vvyEVS+uZVWB9CXEAHIdkKuzyZTuAUoCRcHzeK3eAEFxFDgPY2P4Ek4pOADfcE4rdYm60 WSYVPgD7v8/IRL1csGp9O4eKWE1q4ZLzEybicNIAvVOTcqmfAlc71/5jI/Q/HEVEjJFx8K47 ENQSZCas/voelQI2EFizNAJEQklmQ8/6QDAMCIfdGPEExSgZBaf9LYi0BAld/WOohCPgyuct mYQNsKftFSZhCo65p4CkNcPZ7gVECj4Ah+/5gzMqMh7Wdq4o6gB07otw7pM490mcwlWiZAL0 9iVLI7Gw4fZHhYR1sKapWbG//wAoOoCWZwustM2QpudZU6G+kOUqeQvD6QtLrU9B8GXPWXxg uzVtEJA4oEKJ3qI+o0pGl/OV1kGgwREqgghNFFphBaWmSpbm2TyuzMLwgwDiKKUmYgIvjCrC RFdeZ7jSHeogjlFRRJwt45KKLKLtTDHD2Bhuhz2E4xQk7og5BzimiKm4arbY92gEV4rmoYL5 LXGG4G20lTcXSfwI0GijCJ1IkCLBlpXsaldBlLBCOFEtsqHC/91VrQqGiGDYvvVcNLTTe5S2 CjS5Fj2a9vsNHdeyH2N5a8tZj2bZLk1BUnxdvs4XHWldiM3JfHOEavT25wY2N36duPLX3zJZ nzWd+6fnfMHh/gn7F+vx3qSxIWXH4rPu36eHmmtTF03vzPqc9Jdd45PH/B+Koy/EJHYvO6Dn ZvJlfrtv/oacOVM/YAr78ZPT6GoojGfplESU4+l/z42fCXwDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/QxHlXGbGuK8SLYqWo1QB68S0li0>
Subject: Re: [DNSOP] DNS Delegation Requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2016 22:33:21 -0000
That’s 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 that’s 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_. - Kevin From: DNSOP [mailto:dnsop-bounces@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-bounces@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.darcy@fcagroup.com<mailto:kevin.darcy@fcagroup.com>> wrote: My 2 cents… I don’t 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-bounces@ietf.org<mailto:dnsop-bounces@ietf.org>] On Behalf Of Warren Kumari Sent: Monday, February 08, 2016 9:21 AM To: Ralf Weber; Jakob Schlyter Cc: dnsop; Patrik Wallström Subject: Re: [DNSOP] DNS Delegation Requirements On Mon, Feb 8, 2016 at 2:00 AM Ralf Weber <dns@fl1ger.de<mailto:dns@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 time[0]. 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
- Re: [DNSOP] DNS Delegation Requirements Warren Kumari
- Re: [DNSOP] DNS Delegation Requirements Ray Bellis
- Re: [DNSOP] DNS Delegation Requirements Patrik Wallström
- Re: [DNSOP] DNS Delegation Requirements Ólafur Guðmundsson
- Re: [DNSOP] DNS Delegation Requirements Jakob Schlyter
- Re: [DNSOP] DNS Delegation Requirements Mark Andrews
- Re: [DNSOP] DNS Delegation Requirements Shane Kerr
- Re: [DNSOP] DNS Delegation Requirements Ralf Weber
- [DNSOP] DNS Delegation Requirements Jakob Schlyter
- Re: [DNSOP] DNS Delegation Requirements Mark Andrews
- Re: [DNSOP] DNS Delegation Requirements Darcy Kevin (FCA)
- Re: [DNSOP] DNS Delegation Requirements Mark Andrews
- Re: [DNSOP] DNS Delegation Requirements Darcy Kevin (FCA)
- Re: [DNSOP] DNS Delegation Requirements Warren Kumari
- Re: [DNSOP] DNS Delegation Requirements Jacques Latour
- Re: [DNSOP] DNS Delegation Requirements Darcy Kevin (FCA)
- Re: [DNSOP] DNS Delegation Requirements George Michaelson
- Re: [DNSOP] DNS Delegation Requirements Tony Finch
- [DNSOP] normative language in BCPs Re: DNS Delega… Suzanne Woolf
- Re: [DNSOP] normative language in BCPs Re: DNS De… George Michaelson
- Re: [DNSOP] normative language in BCPs Re: DNS De… Mark Andrews
- Re: [DNSOP] DNS Delegation Requirements John Kristoff
- Re: [DNSOP] DNS Delegation Requirements Darcy Kevin (FCA)
- Re: [DNSOP] DNS Delegation Requirements Jakob Schlyter