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