idnits 2.17.00 (12 Aug 2021) /tmp/idnits16001/draft-kolkman-cautious-delegation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2, 2013) is 3306 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ResevoirDogs' is mentioned on line 227, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman 3 Internet-Draft NLnet Labs 4 Intended status: Informational A. Sullivan 5 Expires: November 3, 2013 Dyn, Inc. 6 May 2, 2013 8 A Procedure for Cautious Delegation of a DNS Name 9 draft-kolkman-cautious-delegation-00 11 Abstract 13 Sometimes, a DNS name is known to be in use in the wild even though 14 it was never properly delegated. This situation appears 15 particularly, but not only, true in certain domains near the root of 16 the tree: people have independently used those non-existent top-level 17 domains as private namespaces. If those names are to be delegated in 18 the public DNS, prudence demands that collisions between the private 19 uses and the public use be minimized. At the same time, the public 20 use should not be prohibited on the grounds of what is, after all, 21 "hijacking" of a name space. We outline a procedure to minimize harm 22 while permitting delegation to proceed. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 3, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Background and Introduction . . . . . . . . . . . . . . . . . . 3 59 2. terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Predelegation determination of use of a name . . . . . . . . . 4 61 3.1. Predelegation testing is needed . . . . . . . . . . . . . . 4 62 3.2. Determining the names of concern . . . . . . . . . . . . . 4 63 3.2.1. Mode 1: prior to any delegation . . . . . . . . . . . . 5 64 3.2.2. Mode 2: After delegation . . . . . . . . . . . . . . . 5 65 4. Parameters for operation of this procedure . . . . . . . . . . 6 66 4.1. Median or Mean . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Discussion of Alternatives . . . . . . . . . . . . . . . . 6 68 4.3. Security considerations . . . . . . . . . . . . . . . . . . 6 69 5. Informative References . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Document Editing Details . . . . . . . . . . . . . . . 7 71 A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Background and Introduction 76 DNS names have always co-existed with other namespaces that are 77 virtually indistinguishable from the DNS. The DNS was itself 78 deployed alongside the host ### table. NetBIOS ### names, though 79 only one label long, could always interact with the DNS search path 80 mechanism to generate DNS names. Additinally, mDNS [RFC6762] names 81 look just like DNS names. Because different naming systems are 82 usually linked together in the user interface, from an end user's 83 point of view these name spaces are all one -- even though they 84 function differently on the Internet. 86 While [RFC6761] reserved certain special names for private use, there 87 is evidence [SAC45] that various sites connected to the Internet have 88 used other names for internal purposes. In fact, [RFC6762] advises 89 not to use .local for private use and observes: "the following top- 90 level domains have been used on private internal networks without the 91 problems caused by trying to reuse ".local." for this purpose:" 92 .intranet. 93 .internal. 94 .private. 95 .corp. 96 .home. 97 .lan. 98 In the event such names are delegated for use in the public DNS, 99 there will be inevitable consequences for such sites. Some of those 100 consequences have implications for security, with the potential for 101 leakage of username and password combinations. Responsible 102 administration of the public namespace therefore requires great care 103 in permitting public delegation of any name where there is good 104 reason to suppose it is in widespread use as a private namespace, 105 even though such private namespaces are (from the point of view of 106 the DNS) irregular. 108 2. terminology 110 In this document we will be using the terms zone, domain and sub- 111 domain. When envisioning the domain namespace as a tree, with nodes 112 at the places where the dots seperate the labels in a domain name, 113 then: 115 a 'domain' is an entire branch. e.g. The .org domain is the branch 116 of the domain name tree for which all names end in .org. 118 a 'sub-domain' is a subordinate namespace of a given domain. e.g. 119 all names ending in example.org are in the domain example org 120 which is a sub-domain of .org. 121 a 'zone' is a piece of the domain space that is under 122 andministrative control of one party. e.g. the .org zone has 123 delegated the example.org domain to the example.org 124 maintainers. 126 3. Predelegation determination of use of a name 128 It is possible for the operator of a zone authoritative for some 129 domain name to tell whether a particular subordinate name has a 130 widespread use outside the DNS. In order to do this, the operator of 131 the zone monitors queries against the zone to learn the names for 132 which there are queries, ignoring those names that actually exist 133 i.e. those names the zoneowner delegated or created resource records 134 for (in the remainder of this document we will not make the 135 distinction between entering data with a name or making a delegation, 136 within the context of this document the same considerations apply). 137 The operator then establishes a baseline "noise" level of queries for 138 non-existent subordinate names. Any name that is queried with 139 significantly greater frequency is to be treated as in widespread 140 private use, and it should not be released for delegation. The rest 141 of this section describes the mechanisms for such determination in 142 detail. 144 3.1. Predelegation testing is needed 146 In order that this procedure be useful, it should be undertaken 147 before any subordinate names are delegated. Otherwise, it will be 148 difficult to tell whether a subordinate name is being queried because 149 it is already delegated, or because it is in private use. 151 At the same time, it is possible that the operator of a zone may wish 152 to consider the private use of a descendent name, where some 153 intermediate namespace has been delegated. In that case, it is 154 necessary to ensure that the descendent name is not actually 155 delegated when evaluating queries against that name. 157 3.2. Determining the names of concern 159 There are two modes of operation for determining names of concern. 160 The most usual is to examine names for which there is no intermediate 161 delegation. This is useful in case the operator of the zone is 162 deciding whether to permit delegation or addition of a particular 163 name. The second, more unusual mode, is to examine subordinate names 164 inside a sub-domain that has already been delegated. This mode is 165 useful only as part of a regime of contract enforcement with the 166 operator of the (already delegated) sub-domain. 168 3.2.1. Mode 1: prior to any delegation 170 The procedure starts with the name of a zone, which is called the 171 "starting domain". In order to determine what subordinate names may 172 be problematic, the starting domain zone operator captures all the 173 names it receives in queries. The operator discards as irrelevant 174 any sub-domain it has already delegated in its namespace. Every 175 other queried name will result in a response of Name Error, RCODE=3 176 ###STD13 ("NXDOMAIN" ###Negative cache). We call the resulting list 177 the "NX names". (See Section 4 for guidance on the sample size.) 179 The operator then takes the list of NX names, and builds a frequency 180 of queries for each potential delegation point (in practice all 181 immediately subordinate names). The operator proceeds in the fully- 182 qualified domain name ("FQDN") label by label until the next label 183 past the operator's namespace (in practice these are the names at 184 which delegation will potentially take place). We call these the 185 "target names". The operator counts the number of queries for each 186 target name. 188 The operator determines the mean and median number of queries over 189 the set of target names. Any name that receives more queries than 190 ###SIGMA -- needs xref to params### greater than the mean, or 191 ###SIGMA2### greater than the median, should be regarded as in 192 widespread private use on the Internet and therefore not a candidate 193 for delegation. 195 It is possible that only a portion of a namespace subordinate to a 196 target name is actually in private use. It is possible to measure 197 this situation simply by treating the beginning of the namespace in 198 question as the starting domain, and then repeating the procedure 199 above. This could be useful in order to establish baseline 200 restrictions on the operator of a subordinate namespace prior to 201 delegation. 203 3.2.2. Mode 2: After delegation 205 This mode is more likely to be useful if the evaluation at the end of 206 the previous section has already been performed. In this case, some 207 sub-domain to the operator's zone is to be evaluated for possible 208 private use, where that sub domain has already been delegated. The 209 zone operator operates the "parent starting zone", and is evaluating 210 use inside a starting domain already operated by someone else. The 211 very same mechanisms as are outlined in Section 3.2.1 are used, but 212 the evaluation must take into consideration the effects of negative 213 TTLs ### for the starting domain. Because of the combining effects 214 of multiple negative TTLs, it is inadvisable to attempt to perform 215 this evaluation beyond the boundary of a single delegation. 217 4. Parameters for operation of this procedure 219 This section ought to have some words about sane parameters to use 220 for the procedure. 222 4.1. Median or Mean 224 In this section we would like to describe some likely distributions. 225 Our assumption is that incoming queries will usually follow some 226 dictionary pattern. The 'everybody wants to be mr. Black' 227 [ResevoirDogs] effect is that queries are much more likely for 228 pupular names than for labels filled with random content. Therefore 229 distributions for non-existent names will have relatively little 230 power in the long tail. However, the long tail is significant in the 231 sense that the names in the long tail are most likely not to exist. 233 The exact type of distribution and the statistical parameters that 234 signify it is subject for a future version of the draft. 236 4.2. Discussion of Alternatives 238 The above method is based on looking at names that the querying 239 population perceives to exist. Alternatively one could count queries 240 for a set of random name like "ao42hft3tofj4irsavc4owajhro.example". 241 That type of measurement will set the baseline of _real_ non-existing 242 names and set the noise level (likely zero queries within a 243 reasonable timescale). However, using trully random names introduced 244 the problem that any signal (e.g. a handful of queries used for 245 probing of availability) will make the domain name unavailable. 247 4.3. Security considerations 249 Applying this mechansism as the basis for decisions to delegate 250 domains, or not, introduces a motivation for gaming the system. The 251 reception of a lot of queries for a particular domain may cause it to 252 not be delegated while the reception of many random queries (changing 253 the properties of the query distribution) may cause a domain that is 254 in comon use to be delegated. Careful analysis of data i.e. by 255 studying root for queries could, in case of suspicion of gaming, help 256 to supplement decisions. 258 5. Informative References 260 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 261 RFC 6761, February 2013. 263 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 264 February 2013. 266 [SAC45] ICANN Security and Stability Advisory Commitee, "Invalid 267 Top Level Domain Queries at the Root Level of the Domain 268 Name System", 11 2010, . 271 Appendix A. Document Editing Details 273 [To Be Removed before publication] 275 $Id: draft-kolkman-cautious-delegation.xml 3 2013-05-02 14:27:06Z 276 olaf $ 278 A.1. version 00 280 Documenting the first rough outline based on hallway discussions with 281 the specific purpose to document the idea in the public domain. 283 Authors' Addresses 285 Olaf Kolkman 286 NLnet Labs 287 Science Park 400 288 Amsterdam 1098 XH 289 The Netherlands 291 Email: olaf@NLnetLabs.nl 293 Andrew Sullivan 294 Dyn, Inc. 295 150 Dow St 296 Manchester, NH 03101 297 U.S.A. 299 Email: asullivan@dyn.com