idnits 2.17.00 (12 Aug 2021) /tmp/idnits788/draft-kolkman-root-test-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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2013) is 3136 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- No issues found here. Summary: 2 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 G. Huston 3 Internet-Draft APNIC 4 Intended status: Experimental Protocol O. Kolkman 5 Expires: April 20, 2014 NLnet Labs 6 A. Sullivan 7 Dyn, Inc. 8 W. Kumari 9 Google, Inc. 10 G. Michaelson 11 APNIC 12 October 19, 2013 14 Using Test Delegations from the Root Prior to Full Allocation and 15 Delegation 16 draft-kolkman-root-test-delegation-01 18 Abstract 20 The delegation of certain strings as generic Top Level Domains 21 (gTLDs) will cause stability and security issues if such strings have 22 been used in private environments prior to their delegation. Test 23 delegations can be used to enable empirical research on the extent of 24 the possible collision prior to actual allocation and delegation of 25 any label in the root zone. This document describes one such 26 approach to an empirical testing framework. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 20, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 61 1.1. Scire est mensurare . . . . . . . . . . . . . . . . . . . 3 62 2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4 63 3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 4 65 3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction and Motivation 75 [[The authors are aware that this version of the document is not 76 fully consistent. However they would value feedback on whether the 77 idea is worth further study. 79 A mail list to discuss this draft is collisions@lists.dns-oarc.net.]] 81 While certain special names have been reserved for internal or 82 private use [RFC6761], there is evidence [SAC45] that various sites 83 connected to the Internet have used other names for internal 84 purposes. In fact, the Multicast DNS specification [RFC6762] advises 85 not to use .local for private use and observes: "the following top- 86 level domains have been used on private internal networks without the 87 problems caused by trying to reuse ".local." for this purpose: 89 .intranet 90 .internal. 91 .private. 92 .corp. 93 .home. 94 .lan." 95 In the event such names are delegated for use in the public DNS, 96 there will be inevitable consequences for sites that have used those 97 names. Some of those consequences have security implications, with 98 the potential for leakage of credentials and HTTP cookies 99 ([RFC6265]). Responsible administration of the public namespace 100 therefore requires great care in permitting public delegation of any 101 name when there is good reason to suppose it is in widespread use as 102 a private namespace, even though such private namespaces are (from 103 the point of view of the DNS) irregular, even if common. 105 One form of name collision involves network domains that use selected 106 names as local-use top level domains, as noted in [RFC6762]. In the 107 case where the same label is delegated in the global DNS as a gTLD, 108 then hosts in the local domain will be unable to resolve domain names 109 in the context of the gTLD. This state of name occlusion is further 110 compounded by a number of scenarios where the resolution of a name is 111 performed across multiple name scope domains. This may happen with a 112 mobile host, or even with applications, such as, for example, mail 113 delivery (in the case where multiple MTAs who are listed as mail 114 servers for a domain reside in different name scope domains, some of 115 which have this name collision between the domain and locally defined 116 pseudo-TLDs). 118 Name collision opens up the potential for misdirection, where the 119 named remote point being contacted by the application may not 120 necessarily be the intended service point for the transaction. When 121 a host leaves the intranet environment, the host's applications may 122 anticipate that the DNS names associated with a label return an RCODE 123 3 (NXDOMAIN) response, but may encounter an unanticipated response 124 when the gTLD is deployed with a colliding name. Similarly, a host 125 that has an association with a named service point within the gTLD 126 may encounter unanticipated responses when the host is placed into an 127 intranet environment where the same name exist as a locally-scoped 128 pseudo-TLD. 130 There is a subtle form of interaction of names when the same name is 131 placed on a local name search list. Certain name resolver libraries 132 first query the original name, and if the query returns an NXDOMAIN, 133 then they apply the local search list to the original name. When 134 this process occurs in the context of a visible gTLD name colliding 135 with the local name there is the possibility of the name resolving in 136 the context of the gTLD, which then bypasses the application of the 137 local search list. 139 1.1. Scire est mensurare 141 The local use of undelegated top-level domain names is troublesome 142 because it may produce different user experiences depending on the 143 locally used name, the names placed in a local search list and the 144 location of a given host, and the host's name resolution behaviour. 146 Prudent operation of the root zone requires that deployment of new 147 names in the root should not cause widespread untoward effects for 148 users of the DNS, particularly when those users are relying on name 149 resolution outcomes that have always been part of the name resolution 150 behaviour up unto this point. 152 What is useful in this context is a mechanism to test whether a 153 particular delegation from the root zone presents a conflict with 154 widespread local use. This memo presents a methodology for making 155 such a determination. 157 The methodology considered here depends on temporary delegation of 158 the top-level domains in question, and the use of a domain under an 159 existing TLD in order to capture and compare queries generated by a 160 large number of querying sources under the control of the experiment. 162 2. Terms and Conventions Used in this Memo 164 The mechanism outlined here is intended to complement the analysis 165 already performed in "Name Collision in the DNS" [namecollision]. We 166 therefore use the terms defined in section 1.1 of [namecollision] 167 whenever appropriate. 169 Note that the evaluation methodology outlined here is intended to be 170 complementary input to a risk analysis e.g. as found in 171 [namecollision]; risk tradeofs are likely to include other factors 172 than the effects measured herewith. 174 3. Principle of Operation 176 The goal of the experiment is to assess whether there is significant 177 existing use of a given candidate string ("CandidateTLD"). 179 We propose the use of a software test that is executed by a large 180 number of end hosts drawn from across the entire Internet. The 181 execution of this test will cause the end host to attempt to retrieve 182 a small set of URLs. This will trigger a set of DNS queries to 183 resolve the domain name part of each URL, and subsequent HTTP queries 184 to retrieve the object in the case that the DNS name is successfully 185 resolved to an IP address. Both the DNS queries and the HTTP 186 requests are answered by dedicated servers that analyse the received 187 responses and match them to the original set of queries that were 188 used by the end host. This will allow us to infer whether the lost 189 is located in an context where there is name collision with the 190 CandidateTLD. In this section we describe the query generation, data- 191 collection, and analysis. 193 This methodology is based on earlier work by APNIC [Method]. 195 3.1. Measurements Servers and Zones 196 In addition to the use of CandidateTLD, the methodology uses an 197 additional name, delegated from a 'common' existing TLD, 198 ("TestName.ExistingTLD") to the experiment's server. 200 The experiment's name server is authoritative for CandidateTLD and 201 TestName.ExistingTLD. The name server will respond to an A and AAAA 202 query for any name within "TestName.CandidateTLD" with the IPV4 or 203 IPv6 address of the experiment's HTTP server. The name server will 204 respond to queries for any other name within CandidateTLD with RCODE 205 3 (Name Error or NXDOMAIN). The name server will respond to A and 206 AAAA queries in TestName.ExistingTLD with the IPv4 or IPv6 address of 207 the experiment's HTTP server. 209 The experiment's HTTP server will respond with a "200 OK" for a 210 request for the object "1x1.png" in TestName.CandidateTLD and in 211 TestName.ExistingTLD. The server will respond with "404 Not Found" 212 for any other object name. 214 3.2. Query Generation 216 The TestName is a synthetic name with no intentional semantic meaning 217 ,that is generated in such a way to reduce the likliehood of 218 collision with any existing delegated name. It is suggested that it 219 be generated by using the hex encoding of a randomly selected integer 220 value between 1,000,000,000 and 2,000,000,000. The name must not be 221 already delegated from the root or in the ExistingTLD. 223 Each query set constitutes one "measurement". A "measurement" is 224 identified by a measurement identifier (, syntactically a 225 valid hostname) that is uniquely generated for each instance of a 226 measurement. This ensures that when the domain name is resolved, and 227 when the named object is retrieved there is no occlusion of the 228 interaction with the experiment's services because of local name or 229 web object caches. The set uses the following URLs: 231 A: http://-a.TestName.CandidateTLD/1x1.png? 232 -a 234 B: http://-a.TestName.ExistingTLD/1x1.png? 235 -b 237 C: http://results.TestName.ExistingTLD/1x1.png? 238 ?za=&zb= 240 The A URL is intended to test if CandidateTLD is a locally used name. 241 In other words, if local use of CandidateTLD occludes visibility of 242 CandidateTLD as a gTLD. The DNS query for 243 -a.TestName.CandidateTLD will only be received by the 244 authoritative name server for this name if there is no local name 245 resolution function that uses the CandidateTLD name as a locally 246 defined pseudo-top level domain. 248 The B URL is intended to function as the control test for the 249 experiment, and the use of ExistingTLD in B is intended to operate as 250 a name that does not collide with a local use context. 252 As the experiment uses the absence of a fetch of the A URL to infer 253 the name resolution behaviour of the location where the measurement 254 is being performed, it is necessary to ensure that the measurement 255 code has run to completion. The measurement code starts a timer at 256 the start of its execution. Upon expiration of the timer, or when 257 both the A and B objects have been successfully retrieved, the code 258 will schedule the retrieval of the C URL. The arguments to the C URL 259 include the client-side measurement of the elapsed time to retrieve 260 the A and B URLs. 262 3.3. Sampling 264 One way to perform this measurement is to embed the measurement in 265 web content, using a scripting language. When the web content is 266 loaded the script is activated, and the measurement sequence is 267 performed. 269 One way to distribute this content to clients to perform the test is 270 via an online (ad) campaign. If the measurement script is enclosed 271 within the ad itself, then there is no reason for the campaign 272 actually to cause users to click though in order to perform the test. 273 Behavior of this sort is trivially achievable with a number of 274 available online advertising systems. 276 It is also necessary to spread the deliver of the ad to a very broad 277 spectrum of clients, uso the as should be presented across all time 278 zones, across all language bases, and across all geographic regions. 280 4. Evaluation 282 To evaluate the results, we take those measurements that return the C 283 URL. The use of the C URL ensures that we use measurement results 284 where the ExistingTLD name is not being locally occluded. We count 285 the number of experiments of each of the possible combinations of 286 retrieving the A and B URLs. These combinations are: 288 Not A and Not B: This result contributes to experimental 289 uncertainty. (We know that ExistingTLD is not locally 290 occluded, so the failure to retrieve B is due to other factors 291 that are not being examined in the context of this 292 measurement.) 294 A and Not B: This result indicates that the client is able to 295 resolve names in the CandidateTLD in the context of the global 296 DNS, but the inability to retrieve the B URL contributes to 297 experimental uncertainty. (The same reasoning about the 298 ExistingTLD and local occlusion applies to this case). 300 Not A and B: This result is an indicator that the client's use of 301 CandidateTLD is probably being occluded by some form of local 302 use. 304 A and B: This result indicates that the client is able to resolve 305 names in the CandidateTLD in the context of the global DNS. 307 If the CandidateTLD is in widespread private use then we would see 308 the count of "Not A and B" be far in excess of the level of 309 experimental uncertainty, then we can conclude that there are locales 310 where the CandidateTLD is being used in local context. Analysis of 311 the source IP addresses of the clients that fetch "Not A and B", and 312 the BGP Origin AS of these addresses and their geolocation may 313 indicate if such local use is clustered in a particular network or 314 group or networks, or clustered in a particular geography or language 315 region. 317 5. Security Considerations 319 The delegation of the Proposed TLD (CandidateTLD) comes with some 320 risk of interference with existing deployments. In the case where a 321 local system queries a name, and that query returns a NXDOMAIN 322 response, then local system then queries further name forms where 323 each entry on a local name search list is appended to the original 324 name in turn, searching for a name response that is not NXDOMAIN. 325 The delegation of CandidateTLD for this experiment may interfere this 326 this behaviour. 328 However, two observations mitigate this concern. The first is that 329 this situation of potential collision arises in the case where the 330 local system is querying for the CandidateTLD name as a "dotless" 331 name (as the only delegated subdomain in the CandidateTLD zone is 332 TestName, which is intended to have no semantic meaning in any 333 language). The second observation is that for such "dotless" names, 334 the currently widely deployed name resolver libraries no not 335 initially query the "dotless" domain name then apply the search list 336 is the first query results in an RCODE 3 response. Many name 337 resolver libraries do not query for "dotless" domain names at all, 338 while those libraries that have been observed to perform such queries 339 (Windows XP, Linux, FreeBSD) perform them after using the local 340 search name list, rather then before. 342 6. References 344 [Method] APNIC, "APNIC Labs IPv6 Measurement System ", Doc. number 345 SC30-3587-01, May 2013. 347 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 348 April 2011. 350 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 351 RFC 6761, February 2013. 353 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 354 February 2013. 356 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 357 Top Level Domain Queries at the Root Level of the Domain 358 Name System", 11 2010, . 361 [namecollision] 362 Interisle Consulting Group, "Name Collision in the DNS", 363 August 2013. 365 Appendix A. Acknowledgements 367 This draft is a follow-up of, an borrows heavily from, our earlier 368 (abbandonded) work on "A Procedure for Cautious Delegation of a DNS 369 Names". Discussion of that document in various hallways lead to 370 inspiration for this document and we want to thank those that gave us 371 feed-back. 373 The idea of using different names to trigger events in a DNS server 374 is due to Geoff Huston. 376 Authors' Addresses 378 Geoff Huston 379 APNIC 380 6 Cordelia St 381 South Brisbane, QLD 4101 382 Australia 384 Email: gih@apnic.net 386 Olaf Kolkman 387 NLnet Labs 388 Science Park 400 389 Amsterdam, 1098 XH 390 The Netherlands 392 Email: olaf@NLnetLabs.nl 393 Andrew Sullivan 394 Dyn, Inc. 395 150 Dow St 396 Manchester, NH 03101 397 U.S.A. 399 Email: asullivan@dyn.com 401 Warren Kumari 402 Google, Inc. 403 1600 Amphitheatre Pkwy 404 Mountain View, CA 94043 405 U.S.A. 407 Email: warren@kumari.net 409 George Michaelson 410 APNIC 411 6 Cordelia St 412 South Brisbane, QLD 4101 413 Australia 415 Email: ggm@apnic.net