idnits 2.17.00 (12 Aug 2021) /tmp/idnits65028/draft-kolkman-root-test-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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 138: '... name (FQDN) and SHOULD be tried as a ...' RFC 2119 keyword, line 226: '...ver, the name server MUST respond with...' RFC 2119 keyword, line 251: '... The TestName MUST be a randomly cho...' RFC 2119 keyword, line 252: '... the experiment, MUST be a syntactical...' RFC 2119 keyword, line 253: '... SHOULD be semantic nonsense, an MUS...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2013) is 3165 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: Experimental Protocol A. Sullivan 5 Expires: March 22, 2014 Dyn, Inc. 6 W. Kumari 7 Google, Inc. 8 September 20, 2013 10 Using Test Delegations from the Root Prior to Full Allocation and 11 Delegation 12 draft-kolkman-root-test-delegation-00 14 Abstract 16 The delegation of certain strings as TLDs will cause stability and 17 security issues if such strings have been used in private 18 environments prior to their delegation. It is recommended that test 19 delegations be used to enable empirical research on the extent of the 20 possible disruption prior to actual allocation and delegation of any 21 label in the root zone. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 22, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 57 1.1. Search-path interaction. . . . . . . . . . . . . . . . . . 3 58 1.2. Scire est mensurare . . . . . . . . . . . . . . . . . . . 4 59 2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4 60 3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 5 62 3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. The Name Server . . . . . . . . . . . . . . . . . . . . . 7 65 4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. A Basis for Acceptable Behaviour . . . . . . . . . . . . . . . 9 67 6. Possible Experiment Extension . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction and Motivation 75 [[The authors are aware that this first version of the document does 76 is not fully consistent. However they would value feedback on 77 whether the idea is worth further pursuance.]] 79 [Editor not: An appropriate mailinglist for discussion of this draft 80 has not yet been identified] 82 DNS names have always co-existed with other namespaces that are 83 virtually indistinguishable from the DNS. The DNS was itself deployed 84 alongside the host [RFC0822] table. NetBIOS [NETBIOS] names, though 85 only one label long, could always interact with the DNS search path 86 mechanism to generate DNS names. Additionally, mDNS [RFC6762] names 87 often look just like DNS names. Because different naming systems are 88 usually linked together in the user interface, from an end user's 89 point of view these name spaces are all one -- even though they 90 function differently on the Internet. 92 While [RFC6761] reserved certain special names for internal or 93 private use, there is evidence [SAC45] that various sites connected 94 to the Internet have used other names for internal purposes. In 95 fact, [RFC6762] advises not to use .local for private use and 96 observes: "the following top-level domains have been used on private 97 internal networks without the problems caused by trying to reuse 98 ".local." for this purpose:" 99 .intranet. 101 .internal. 103 .private. 105 .corp. 107 .home. 109 .lan. 111 In the event such names are delegated for use in the public DNS, 112 there will be inevitable consequences for sites that have used those 113 names. Some of those consequences have implications for security, 114 with the potential for leakage of credentials and HTTP cookies 115 ([RFC6265]). Responsible administration of the public namespace 116 therefore requires great care in permitting public delegation of any 117 name when there is good reason to suppose it is in widespread use as 118 a private namespace, even though such private namespaces are (from 119 the point of view of the DNS) irregular, even if common. 121 1.1. Search-path interaction. 123 In many cases a string appears to be used as an "undelegated TLD" 124 (being used as the rightmost label in an name), but this is simply an 125 artifact of domain search list processing. 127 For example, suppose the Example Widgets corporation uses a sub- 128 domain (.corp) of their primary domain (example.com) to name their 129 employee workstations, servers, printers and similar. They have an 130 "intranet" server named intranet.corp.example.com. In order to allow 131 their employees to simply type "intranet.corp" to access this server, 132 the users' workstations are configured (probably using [RFC3379]) 133 with the search-list set to "corp.example.com, example.com". 135 When a user enters "intranet.corp", their workstation will try and 136 resolve the name. RFC1535 [RFC1535] specifies that "in any event 137 where a "." exists in a specified name it should be assumed to be a 138 fully qualified domain name (FQDN) and SHOULD be tried as a rooted 139 name first." So, the user's workstation will first try and resolve 140 "intranet.corp.". As there is (currently) no .corp TLD this will 141 result in an NXDOMAIN response. The workstation will then append 142 entries in the search-list until it is able to resolve the (now 143 fully-qualified) name. 145 If the .corp label were to be delegated as a TLD and the sub-domain 146 "intranet" created within .corp, the first lookup ("intranet.corp") 147 would no longer generate an NXDOMAIN response. This would stop the 148 search-list processing, and direct the user somewhere other than 149 where the user intended to go -- the "wrong server", in the eyes of 150 the user, even if right according to the DNS. 152 It is worth noting that a researcher analyzing DNS queries hitting 153 the root servers would see queries before search-list processing 154 expands them. While this may not change whether or not it is safe to 155 delegate these names, having an understanding of the cause is 156 valuable. 158 1.2. Scire est mensurare 160 The local use of undelegated top-level domain names is troublesome 161 because it produces different experience depending on the search path 162 and location of a given device. That is a normal effect of the 163 search path mechanism or the roaming of users, but with the advent of 164 new generic top-level domains (gTLDs), the problem gets more acute, 165 because many TLDs are intended to be mnemonics that will be intuitive 166 to humans. Since names higher in the DNS tree are likely also to use 167 those same intuitive labels, there is potential for user confusion 168 and information leakage. 170 At the same time, it is not clear that the DNS protocol was designed 171 around a static list of top-level domains (TLDs), and therefore it 172 seems reasonable to plan for the possible addition of new TLDs whose 173 use might conflict with deployed search path settings. Yet prudent 174 operation of the root zone requires that deployment of new names in 175 the root should not cause widespread untoward effects for users of 176 the DNS, particularly when those users are relying on features that 177 have always been part of the protocol. 179 What is needed is a mechanism to test whether a particular delegation 180 from the root zone presents a serious conflict with widespread use. 181 This memo presents a methodology for making such a determination. 183 The methodology depends on temporary delegation of the top-level 184 domains in question, and the use of a domain under an existing TLD in 185 order to capture and compare queries generated by a large number of 186 querying sources under the control of the experiment. 188 2. Terms and Conventions Used in this Memo 190 The mechanism outlined here is intended to complement the analysis 191 already performed in "Name Collision in the DNS" [namecollision]. We 192 therefore use the terms defined in section 1.1 of [namecollision] 193 whenever appropriate. 195 Note that the evaluation methodology outlined here is intended to be 196 complementary input to a risk analysis e.g. as found in 197 [namecollision]; risk tradeofs are likely to include other factors 198 than the effects measured herewith. 200 3. Principle of Operation 201 In order to assess whether there is significant use of a given 202 candidate string (CandidateTLD), probes will send out sets of queries 203 from a large number of random locations. The queries are answered by 204 dedicated servers that collect statistics. In this section we 205 describe the query generation, data-collection, and what the 206 dedicated servers should answer to not interfere with Internet 207 traffic. 209 The goal of the experiment is to assess whether there is significant 210 existing use of a single CandidateTLD. 212 3.1. Measurements Servers and Zones 214 In addition to the candidate string ("CandidateTLD") the methodology 215 uses a specific sting "TestName". During an experiment the Proposed 216 TLD under evaluation ("CandidateTLD") and a control TLD ("TestName") 217 are delegated from the root zone to a special DNS name server, the 218 experiment's server. Further, a second control name 219 (TestName.ExistingTLD) is delegated from a 'common' existing TLD 220 (ExistingTLD) to the experiment's server. 222 The experiment's server has two functions: 224 First, with one exception detailed below in Section 3.4, if any 225 request for any name inside the CandidateTLD or the TestName 226 namespace reaches the name server, the name server MUST respond with 227 RCODE 3 (Name Error or NXDOMAIN) (Note that from a DNS client 228 perspective the ultimate RCODE 3 response is indistinguishable from 229 what is returned without the test delegation in place.) 231 Second, the experiment's server tracks every name in any request it 232 receives, the time at which the request arrived, the RRTYPE and CLASS 233 in the request, and the source network for the request. 235 3.2. Query Generation 237 Software probes will need to be deployed throughout the Internet 238 (also see Section 3.3) these probes will send, in parallel, sets of 239 queries. 241 Each set comprises one measurement and consists of three queries (or 242 even 4, see Section 6). A measurement is identified by a unique 243 measurement identifier (, syntactically a valid hostname); 244 the set will include the following: 246 the QNAME is -a.TestName. 248 the QNAME is -b.TestName.CandidateTLD 249 the QNAME is -c.TestName.ExistingTLD 251 The TestName MUST be a randomly chosen name that remains constant for 252 the duration of the experiment, MUST be a syntactically valid label, 253 SHOULD be semantic nonsense, an MUST NOT be delegated from the root 254 or in the ExistingTLD already. 256 Depending on the environment in which the probe is located the query 257 that is send by a stub resolver is handled differently. We 258 distinguish 4 possibilities. 260 Local CandidateTLD use without Search List: The probe is located 261 within a network that locally resolves the candidateTLD and there 262 are no searchlists being used that append CandidateTLD. The query 263 with a QNAME of -b.TestName.CandidateTLD will not exit 264 the local network while the queries with a QNAME of 265 -c.TestName.ExistingTLD. and QNAME of 266 -a.TestName. will arrive at the authoritative servers 267 for the respective domains. 269 Local CandidateTLD and CandidateTLD appened Search List: The probe is 270 located within a network that locally resolves the candidateTLD 271 and there are searchlists being used that append CandidateTLD. The 272 query with a QNAME of -b.TestName.CandidateTLD will not 273 exit the local network while the queries with a QNAME of 274 lt;uniqueid>-c.TestName.ExistingTLD. will arrive at the 275 authoritative server for the domain. The query with a QNAME of 276 -a.TestName. is subject to the search algortithm, the 277 query name will effectively be substitude to 278 -a.TestName.CandidateTLD and be resolved localy. The 279 query for -a.TestName. will therefore not be seen at 280 the authoritative server. 282 No use of CandidateTLD and no use of Search List: The probe is 283 located within a network that does not resolve the candidate TLD 284 and no searchlists being used that append CandidateTLD. All 285 queries will arrive at the authoritative servers for the 286 respective domains. 288 No use of CandidateTLD and CandidateTLD appended by Search List: The 289 probe is located within a network that does not resolve the 290 candidate TLD but search list processing appends CandidateTLD. In 291 this case the queries for Lt;uniqueid>-a.TestName. get rewritten 292 to lt;uniqueid>-a.TestName.CandidateTLD and arrive, together with 293 lt;uniqueid>-b.TestName.CandidateTLD at the authoritative server 294 for CandidateTLD, while queries for the QNAME 295 -c.TestName.ExistingTLD arrive at the server 296 authoritative for TestName.ExistingTLD. 298 As a result, by comparing what arrives at the authoritative servers 299 one can establish the prevalence of the various scenarios. Under the 300 assumption of a broad unbiased sample exclusively observing the 3rd 301 option (all queries hitting their respective servers) would be a 302 strong indication that a candidate TLD is not in use. 304 3.3. Sampling 306 To perform the evaluation, a names of the form 307 .TestName.CandidateTLD and 308 .controlname.ExistingTLD are embedded in content that is 309 placed around the web. As people visit web sites, the content is 310 processed, yielding attempts at resolution of the names. 312 The easiest way to provide the content that causes the relevant DNS 313 lookup is to use an online (ad) campaign. There is no reason for the 314 campaign actually to cause users to click though, so it should be as 315 boring as possible. However, the campaign must result in the 316 independent resolution of both the control and test names. Behavior 317 of this sort is trivially achievable with several available online 318 advertising systems. 320 It is critical that the sampling be as representative of the Internet 321 population as possible. This sort of sample already has the 322 significant problem that it can only measure users of the web. And 323 there may be sampling effects that might prevent measurements from 324 taking place in those environments that need to be reached. For 325 instance, add-blocking or different web surfing behavior in corporate 326 environements. 328 The measurements should be unbiased with respect to temporal behavior 329 like sleep-wake and work-rest cycles. 331 [[The sampling biases probably deserve their own section with much 332 more elaboration and more possible biases]] 334 3.4. The Name Server 336 This procedure rests on a name server that is configured and 337 instrumented in particular ways. First, the name server must be 338 configurable so that it authoritative for all requests inside the 339 Candidate TLD. Normally, it will always return RCODE 3 (NXDOMAIN) for 340 all queries inside that Candidate TLD, except that the name server 341 must also be configurable so that it is the authoritative name server 342 for the test name. All names underneath the test name, however, also 343 return RCODE 3. A summary of the behavior is in Table 1. 345 +-----------------------------+------------+-----------+------------+ 346 | Domain Name | RRTYPE | RCODE | Actions if | 347 | | queried | returned | any | 348 +-----------------------------+------------+-----------+------------+ 349 | CandidateTLD | anything | 3 | | 350 | | except NS | | | 351 | CandidateTLD | NS | 0 | return | 352 | | | | server in | 353 | | | | answer | 354 | | | | section | 355 | | | | RDATA | 356 | TestName | anything | 3 | | 357 | | except NS | | | 358 | TestName | NS | 0 | return | 359 | | | | server in | 360 | | | | answer | 361 | | | | section | 362 | | | | RDATA | 363 | TestName.CandidateTLD | NS | 0 | return | 364 | | | | server in | 365 | | | | answer | 366 | | | | section | 367 | | | | RDATA | 368 | TestName.CandidateTLD | anything | 3 | | 369 | | except NS | | | 370 | *.TestName.CandidateTLD | ANY | 3 | Queries to | 371 | | | | be | 372 | | | | measured | 373 | *.controlname.ExistingTLD | ANY | 3 | Queries to | 374 | | | | be | 375 | | | | measured | 376 | *.TestName | ANY | 3 | Queries to | 377 | | | | be | 378 | | | | measured | 379 +-----------------------------+------------+-----------+------------+ 381 4. Evaluation 383 [TODO align with above] 385 To evaluate the results, it is only necessary to compare the number 386 of resolution attempts of the test names against the resolution 387 attempts of the control names. If the test name is not in wide 388 private use, then a lookups for the name unique identifier in each 389 name space will arrive nearly as often and at the same time (modulo 390 the difference in the recursive nameserver following the delegation 391 chain) at the instrumented name server. 393 If the test name is in widespread private use without a search list, 394 or is otherwise resolved locally, then we should expect that lookups 395 inside the test namespace will happen less often than lookups inside 396 the control namespace. If there is no search list in use, then the 397 test QNAMEs of the "b" form will arrive less often than those of "a" 398 form and "c" form. If there is a search list in use, then the "a" 399 form will also not arrive at the authoritative server. If the 400 CandidateTLD is in a search list, we can expect to see duplicated 401 queries of the "b" form on the authoritative server (because the "a" 402 form gets the search list appended). 404 5. A Basis for Acceptable Behaviour 406 We assume that there will always be some "stray" queries to the DNS: 407 queries for names that have a TLD-label that does not exist in the 408 root-zone, and which were not intended to be sent to the global DNS. 409 Therefore, it is necessary to establish some baseline level of these 410 "noise" queries, and then use that to evaluate whether some proposed 411 new name for the DNS presents a problem. 413 Because of the historic prominence of the .com TLD, it may be 414 supposed that .com is, like the root itself, a special zone in which 415 unusual behaviour might be expected. Therefore, names inside the 416 .com name space are a poor guide for "normal" behaviour, and it 417 should not be used for making these sorts of evaluations. The best 418 guide will likely come from using TLDs that are themselves 419 statistically normal. 421 In addition, overwhelming conservatism suggests that using 422 comparisons with the TLD that is queried least often provides a great 423 margin of safety. As of this writing, a string that is queried less 424 often than that least-queried TLD seems likely not to be in 425 widespread real use, and therefore comparisons with that least- 426 queried TLD are a good conservative choice when evaluating. 428 6. Possible Experiment Extension 430 A bias to the measurement is introduced if in certain environments 431 lists of existing TLDs are used in access lists of, for instance, 432 firewalls. In that case queries for the QNAME 433 -b.TestName.CandidateTLD might be blocked. To calibrate 434 that behavior an additional non-existent TLD could be delegated for 435 the duration of the experiment: 437 the QNAME is -d.TestName.RandomTLD 439 Whereby RandomTLD is a short TLD with the same properties as the 440 candidate TLD. e.g. if the CandidateTLD is U-Label then the 441 RandomTLD is a U-Label from the same script. 443 If the measurement servers receive queries where the QNAME is neither 444 -d.TestName.RandomTLD nor 445 -b.TestName.CandidateTLD then it is likely that all non- 446 delegated domains are blocked. An alternative way of interpreting 447 this is that the queries where the QNAME is 448 -d.TestName.RandomTLD that arrive at the measurement 449 servers provide a baseline for the transparency of the querying 450 environment for non-delegated TLDs. 452 7. Security Considerations 454 The delegation of the Proposed TLD (CandidateTLD) and control TLD 455 (TestName) comes with some risk of interference with existing 456 deployments. The risks for name collision for the TestName is under 457 the control of the experimenter and can be minimized by taking random 458 strings without semantic value. 460 The risk of name collision with the CandidateTLD is minimized reduced 461 by having the experiment's server returning RCODE=3. Under the 462 assumption of regular DNS implementations that response is 463 indistinguishable from a direct root-response for applications that 464 receive such answer from a stub resolver. The authors have no reason 465 to believe that there are DNS implementations that would hand the 466 applications a different response if a delegation is part of the 467 resolution process. 469 The authors would advise against signing the various delegated 470 domains, as the introduction of DNSSEC is likely to bias the 471 experiment. At the root domain and ExistingTLDs, regular signing 472 practices, including the inclusion of an NSEC or NSEC3 RR proving the 473 non-existence of a DS record should continue. 475 The experiment can be biased by 3rd parties through sending queries 476 that have properties like the ones specified herein. The 477 experimentor SHOULD carefully control and record the 478 values used in the experiment and discard non-expected and non-unique 479 queries that arrive at the nameserver. 481 8. References 483 [NETBIOS] IBM Corporation, "LAN Technical Reference: 802.2 and 484 NetBIOS APIs ", Doc. number SC30-3587-01, April 1996. 486 [RFC0822] Crocker, D.H., "Standard for the format of ARPA Internet 487 text messages", STD 11, RFC 822, August 1982. 489 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 490 With Widely Deployed DNS Software", RFC 1535, October 491 1993. 493 [RFC3379] Pinkas, D. and R. Housley, "Delegated Path Validation and 494 Delegated Path Discovery Protocol Requirements", RFC 3379, 495 September 2002. 497 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 498 April 2011. 500 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 501 RFC 6761, February 2013. 503 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 504 February 2013. 506 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 507 Top Level Domain Queries at the Root Level of the Domain 508 Name System", 11 2010, . 511 [namecollision] 512 Interisle Consulting Group, "Name Collision in the DNS", 513 August 2013. 515 Appendix A. Acknowledgements 517 This draft is a follow-up of, an borrows heavily from, our earlier 518 (abbandonded) work on "A Procedure for Cautious Delegation of a DNS 519 Names". Discussion of that document in various hallways lead to 520 inspiration for this document and we want to thank those that gave us 521 feed-back. 523 The idea of using different names to trigger events in a DNS server 524 is due to Geoff Huston. 526 Authors' Addresses 528 Olaf Kolkman 529 NLnet Labs 530 Science Park 400 531 Amsterdam, 1098 XH 532 The Netherlands 534 Email: olaf@NLnetLabs.nl 536 Andrew Sullivan 537 Dyn, Inc. 538 150 Dow St 539 Manchester, NH 03101 540 U.S.A. 542 Email: asullivan@dyn.com 543 Warren Kumari 544 Google, Inc. 545 1600 Amphitheatre Pkwy 546 Mountain View, CA 94043 547 U.S.A. 549 Email: warren@kumari.net