idnits 2.17.00 (12 Aug 2021) /tmp/idnits15448/draft-kolkman-cautious-delegation-01.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 150: '... name (FQDN) and SHOULD be tried as a ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2013) is 3251 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 278, but not defined == Unused Reference: 'RFC1035' is defined on line 317, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 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: December 28, 2013 Dyn, Inc. 6 W. Kumari 7 Google, Inc. 8 June 26, 2013 10 A Procedure for Cautious Delegation of a DNS Name 11 draft-kolkman-cautious-delegation-01 13 Abstract 15 Sometimes, a DNS name is known to be in use in the wild even though 16 it was never properly delegated. This situation appears 17 particularly, but not only, true in certain domains near the root of 18 the tree: people have independently used those non-existent top-level 19 domains as private namespaces. If those names are to be delegated in 20 the public DNS, prudence dictates that collisions between the private 21 uses and the public use be minimized. We outline a procedure to 22 evaluate the harm of delegation. 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 December 28, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Background and Introduction . . . . . . . . . . . . . . . . . . 3 60 2.1. Search-path interaction. . . . . . . . . . . . . . . . . . 4 61 3. Predelegation determination of use of a name . . . . . . . . . 4 62 3.1. Predelegation testing is needed . . . . . . . . . . . . . . 5 63 3.2. Determining the names of concern . . . . . . . . . . . . . 5 64 3.2.1. Mode 1: Prior to any delegation . . . . . . . . . . . . 6 65 3.2.2. Mode 2: After delegation . . . . . . . . . . . . . . . 6 66 4. Parameters for operation of this procedure . . . . . . . . . . 7 67 4.1. Median or Mean . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Discussion of Alternatives . . . . . . . . . . . . . . . . 7 69 5. Security considerations . . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Document Editing Details . . . . . . . . . . . . . . . 8 73 A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 8 74 A.2. version 01 . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Terminology 79 NXDOMAIN: an alternate expression for the "Name Error" RCODE as 80 described in [[RFC1035] Section 4.1.1]. The two terms are used 81 interchangeably in this document. (definition from [RFC2308]) 83 In this document we will be using the terms zone, domain and sub- 84 domain. When envisioning the domain namespace as a tree, with nodes 85 at the places where the dots separate the labels in a domain name, 86 then: 88 a 'domain' is an entire branch. e.g. The .org domain is the branch 89 of the domain name tree for which all names end in .org. 90 a 'sub-domain' is a subordinate namespace of a given domain. e.g. 91 all names ending in example.org are in the domain example.org 92 which is a sub-domain of .org 93 a 'zone' is a piece of the domain space that is under administrative 94 control of one party. e.g. the .org zone has delegated the 95 example.org domain to the example.org maintainers. 97 2. Background and Introduction 99 DNS names have always co-existed with other namespaces that are 100 virtually indistinguishable from the DNS. The DNS was itself 101 deployed alongside the host ### table. NetBIOS ### names, though 102 only one label long, could always interact with the DNS search path 103 mechanism to generate DNS names. Additionally, mDNS [RFC6762] names 104 look just like DNS names. Because different naming systems are 105 usually linked together in the user interface, from an end user's 106 point of view these name spaces are all one -- even though they 107 function differently on the Internet. 109 While [RFC6761] reserved certain special names for internal or 110 private use, there is evidence [SAC45] that various sites connected 111 to the Internet have used other names for internal purposes. In 112 fact, [RFC6762] advises not to use .local for private use and 113 observes: "the following top-level domains have been used on private 114 internal networks without the problems caused by trying to reuse 115 ".local." for this purpose:" 116 .intranet. 117 .internal. 118 .private. 119 .corp. 120 .home. 121 .lan. 123 In the event such names are delegated for use in the public DNS, 124 there will be inevitable consequences for such sites. Some of those 125 consequences have implications for security, with the potential for 126 leakage of credentials and HTTP cookies ([RFC6265]). Responsible 127 administration of the public namespace therefore requires great care 128 in permitting public delegation of any name where there is good 129 reason to suppose it is in widespread use as a private namespace, 130 even though such private namespaces are (from the point of view of 131 the DNS) irregular (although not uncommon). 133 2.1. Search-path interaction. 135 In many cases a string appears to be used as an "undelegated TLD" 136 (being used as the rightmost label in an name), but this is simply an 137 artifact of domain search list processing. 139 As an (hypothetical) example, Example Widgets uses a sub-domain 140 (.corp) of their primary domain (example.com) to name their employee 141 workstations, servers, printers and similar. They have an "intranet" 142 server named intranet.corp.example.com. In order to allow their 143 employees to simply type "intranet.corp" to access this server, the 144 users' workstations are configured (probably using [RFC3379]) with 145 the search-list set to "corp.example.com, example.com". 147 When a user enters "intranet.corp", their workstation will try and 148 resolve the name. RFC1535 [RFC1535] specifies that "in any event 149 where a "." exists in a specified name it should be assumed to be a 150 fully qualified domain name (FQDN) and SHOULD be tried as a rooted 151 name first." and so the users workstation will first try and resolve 152 "intranet.corp.". As there is (currently) no .corp TLD this will 153 result in an NXDOMAIN response. The workstation will then append 154 entries in the search-list until it is able to resolve the (now 155 fully-qualified) name. 157 If the .corp label were to be delegated as a TLD and the sub-domain 158 "intranet" created within .corp, the first lookup ("intranet.corp") 159 would no longer generate an NXDOMAIN response. This would stop the 160 search-list processing, and direct the user to the incorrect server. 162 It is worth noting that a researcher analyzing DNS queries hitting 163 the root servers would see queries before search-list processing 164 expands them. While this may not change whether or not it is safe to 165 delegate these names, having an understanding of the cause is 166 valuable. 168 3. Predelegation determination of use of a name 170 It is possible for the operator of a zone authoritative for some 171 domain name to tell whether a particular subordinate name has a 172 widespread use outside the DNS. In order to do this, the operator of 173 the zone monitors queries against the zone to learn the names for 174 which there are queries, ignoring those names that actually exist 175 i.e. those names the zone owner delegated or created resource records 176 for (in the remainder of this document we will not make the 177 distinction between entering data with a name or making a delegation; 178 within the context of this document the same considerations apply). 179 The operator then establishes a baseline "noise" level of queries for 180 non-existent subordinate names. Any name that is queried with 181 significantly greater frequency is to be treated as in widespread 182 private use, and it should not be released for delegation. The rest 183 of this section describes the mechanisms for such determination in 184 detail. 186 3.1. Predelegation testing is needed 188 In order for this procedure to be useful, it should be undertaken 189 before any subordinate names are delegated. Otherwise, it will be 190 difficult to tell whether a subordinate name is being queried because 191 it is already delegated or because it is in private use. 193 At the same time, it is possible that the operator of a zone may wish 194 to consider the private use of a descendant name, where some 195 intermediate namespace has been delegated. In that case, it is 196 necessary to ensure that the descendant name is not actually 197 delegated when evaluating queries against that name. 199 3.2. Determining the names of concern 201 [ ED NOTE: This methodology needs to tested. First assessment of 202 data indicates that this approach may be far to trivial ] 204 There are two modes of operation for determining names of concern. 205 The most usual is to examine names for which there is no intermediate 206 delegation. This is useful in case the operator of the zone is 207 deciding whether to permit delegation or addition of a particular 208 name. The second, more unusual mode, is to examine subordinate names 209 inside a sub-domain that has already been delegated. This mode is 210 useful only as part of a regime of contract enforcement with the 211 operator of the (already delegated) sub-domain. [WK Note: Are we 212 sure we even want to address/suggest this second "limited delegation" 213 option? If we are going to discuss it, referring to it as "limited 214 delegation" or similar may help clarify. Personally I think 'tis a 215 silly idea, but... There is talk of doing "test" delegations - 216 basically launch a TLD / domain with a low TTL. If nothing goes 217 "boom" then delegate for longer...] 219 3.2.1. Mode 1: Prior to any delegation 221 The procedure starts with the name of a zone, which is called the 222 "starting domain". In order to determine what subordinate names may 223 be problematic, the starting domain zone operator captures all the 224 names it receives in queries. The operator discards as irrelevant 225 any sub-domain it has already delegated in its namespace. Every 226 other queried name will result in a response of Name Error, RCODE=3 227 ###STD13 ("NXDOMAIN" ###Negative cache). We call the resulting list 228 the "NX names". (See Section 4 for guidance on the sample size.) 230 The operator then takes the list of NX names, and builds a frequency 231 of queries for each potential delegation point (in practice all 232 immediately subordinate names). The operator proceeds in the fully- 233 qualified domain name ("FQDN") label by label until the next label 234 past the operator's namespace (in practice, these are the names at 235 which delegation will potentially take place). We call these the 236 "target names". The operator counts the number of queries for each 237 target name. 239 The operator determines the mean and median number of queries over 240 the set of target names. Any name that receives more queries than 241 ###SIGMA -- needs xref to params### greater than the mean, or 242 ###SIGMA2### greater than the median, should be regarded as in 243 widespread private use on the Internet and therefore not a candidate 244 for delegation. 246 It is possible that only a portion of a namespace subordinate to a 247 target name is actually in private use. It is possible to measure 248 this situation simply by treating the beginning of the namespace in 249 question as the starting domain, and then repeating the procedure 250 above. This could be useful in order to establish baseline 251 restrictions on the operator of a subordinate namespace prior to 252 delegation. 254 3.2.2. Mode 2: After delegation 256 This mode is more likely to be useful if the evaluation at the end of 257 the previous section has already been performed. In this case, some 258 sub-domain to the operator's zone is to be evaluated for possible 259 private use, where that sub domain has already been delegated. The 260 zone operator operates the "parent starting zone", and is evaluating 261 use inside a starting domain already operated by someone else. The 262 very same mechanisms as are outlined in Section 3.2.1 are used, but 263 the evaluation must take into consideration the effects of negative 264 TTLs ### for the starting domain. Because of the combining effects 265 of multiple negative TTLs, it is inadvisable to attempt to perform 266 this evaluation beyond the boundary of a single delegation. 268 4. Parameters for operation of this procedure 270 This section ought to have some words about sane parameters to use 271 for the procedure.? 273 4.1. Median or Mean 275 In this section we would like to describe some likely distributions. 276 Our assumption is that incoming queries will usually follow some 277 dictionary pattern. The 'everybody wants to be Mr. Black' 278 [ResevoirDogs] effect is that queries are much more likely for 279 popular names than for labels filled with random content. Therefore 280 distributions for non-existent names will have relatively little 281 power in the long tail. However, the long tail is significant in the 282 sense that the names in the long tail are most likely not to exist. 284 The exact type of distribution and the statistical parameters that 285 signify it is subject for a future version of the draft. 287 4.2. Discussion of Alternatives 289 The above method is based on looking at names that the querying 290 population perceives to exist. Alternatively one could count queries 291 for a set of random name like "ao42hft3tofj4irsavc4owajhro.example". 292 That type of measurement will set the baseline of _real_ non-existing 293 names and set the noise level (likely zero queries within a 294 reasonable timescale). However, using truly random names introduced 295 the problem that any signal (e.g. a handful of queries used for 296 probing of availability) will make the domain name unavailable. 298 5. Security considerations 300 Applying this mechanism as the basis for decisions on whether or not 301 to delegate domains introduces a motivation for gaming the system. 302 The reception of a lot of queries for a particular domain may cause 303 it to not be delegated, while the reception of many random queries 304 (changing the properties of the query distribution) may cause a 305 domain that is in common use to be delegated (by hiding the actual 306 use of names in that domain in the noise). Careful analysis of data 307 (for example, by studying root for queries, and taking into account 308 historical trending) could, in case of suspicion of gaming, help to 309 supplement decisions. 311 6. IANA Considerations 313 This document makes no requests of the IANA. 315 7. Informative References 317 [RFC1035] Mockapetris, P., "Domain names - implementation and 318 specification", STD 13, RFC 1035, November 1987. 320 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 321 With Widely Deployed DNS Software", RFC 1535, 322 October 1993. 324 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 325 NCACHE)", RFC 2308, March 1998. 327 [RFC3379] Pinkas, D. and R. Housley, "Delegated Path Validation and 328 Delegated Path Discovery Protocol Requirements", RFC 3379, 329 September 2002. 331 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 332 April 2011. 334 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 335 RFC 6761, February 2013. 337 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 338 February 2013. 340 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 341 Top Level Domain Queries at the Root Level of the Domain 342 Name System", 11 2010, . 345 Appendix A. Document Editing Details 347 [To Be Removed before publication] 349 $Id: draft-kolkman-cautious-delegation.xml 3 2013-05-02 14:27:06Z 350 olaf $ 352 A.1. version 00 354 Documenting the first rough outline based on hallway discussions with 355 the specific purpose to document the idea in the public domain. 357 $Id: draft-kolkman-cautious-delegation.xml 5 2013-06-11 21:49:28Z 358 warren $ 360 A.2. version 01 362 o Bunch 'o nits. 363 o Added section on search-path processing. 364 o 366 Authors' Addresses 368 Olaf Kolkman 369 NLnet Labs 370 Science Park 400 371 Amsterdam 1098 XH 372 The Netherlands 374 Email: olaf@NLnetLabs.nl 376 Andrew Sullivan 377 Dyn, Inc. 378 150 Dow St 379 Manchester, NH 03101 380 U.S.A. 382 Email: asullivan@dyn.com 384 Warren Kumari 385 Google, Inc. 386 1600 Amphitheatre Pkwy 387 Mountain View, CA 94043 388 U.S.A. 390 Email: warren@kumari.net