idnits 2.17.1 draft-mglt-dnsop-search-list-processing-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2014) is 3658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-16) exists of draft-ietf-dane-ops-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP D. Migault (Ed) 3 Internet-Draft Orange 4 Intended status: Standards Track April 11, 2014 5 Expires: October 13, 2014 7 DNS Search List Processing 8 draft-mglt-dnsop-search-list-processing-00.txt 10 Abstract 12 Domain Names can be Qualified or Unqualified Domain Names. Qualified 13 Domain Names are resolved over the public DNS infrastructure, whereas 14 Unqualified Domain Names are resolved using search lists. How search 15 lists are generated and interpreted varies from one application to 16 another and from one operating system to another. This makes 17 Unqualified Domain Name resolution unpredictable, non deterministic, 18 and as such neither reliable nor stable. 20 In addition, there is neither clear rules to define whether a name is 21 a Qualified or an Unqualified Domain Name. This also contributes in 22 making the naming resolution unreliable, as the resolution of a given 23 name can result in different responses. 25 As a consequence, most resolution systems currently end with a "try 26 and error" strategy. More specifically, according to some system 27 dependent heuristics, a resolver initiates an Unqualified (resp. 28 Qualified) Domain Name resolution, and, in case of a NXDOMAIN 29 response, fails back in a Qualified (resp. Unqualified) Domain Name 30 resolution. Such strategies were acceptable as the probability of 31 collision between domains within search list and those published in 32 the public DNS infrastructure remains low. In the context of the 33 generalization of Top Level Domain, this assumption is not acceptable 34 anymore, resulting in an unreliable and unstable naming resolution. 36 This document describes how search list should be generated and 37 interpreted. Then, it describes how resolvers distinguish between 38 Qualified and Unqualified Domain Names as well as how to resolve 39 them. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on October 13, 2014. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2.1. Qualified and Unqualified Domain Names . . . . . . . . . 3 78 2.2. Domain Names Collision . . . . . . . . . . . . . . . . . 4 79 2.3. Structure of the Document . . . . . . . . . . . . . . . . 4 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Search List Generation . . . . . . . . . . . . . . . . . . . 5 82 5. Search List Interpretation . . . . . . . . . . . . . . . . . 7 83 6. Distinction of Unqualified and Qualified Domain Names . . . . 7 84 7. Resolution of Unqualified and Qualified Domain Names . . . . 7 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 90 11.2. Informational References . . . . . . . . . . . . . . . . 10 91 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 11 92 Appendix B. TLDs with A/AAAA . . . . . . . . . . . . . . . . . . 11 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 95 1. Requirements notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 2.1. Qualified and Unqualified Domain Names 105 Until recently, the root zone had only a restricted number of well 106 known Top-Level Domain (TLDs). These TLDs had a specific format of a 107 few letters (generally two or three), and had remained almost 108 unchanged for a long time. Simultaneously, end users and 109 applications used for convenience Unqualified Domain Names for local 110 scope resolutions. More specifically, suppose "host1.example" wants 111 to establish a communication with "foo.example". As both host belong 112 to the same Domain "example", simply specifying "foo" should be 113 sufficient. The mechanism to auto-complete "foo" with "foo.example" 114 is performed using search list mechanisms. In most cases, the use of 115 Unqualified Domain Names was used in a local scope context, that is 116 to say, when "example" was used for convenience, but not registered 117 in the public DNS infrastructure. 119 As a result, there are two ways to express the names of the nodes 120 within a Domain: A Fully Qualified Domain Name ("host2.example") and 121 an Unqualified Domain Name ("host2"). Each of these names requires a 122 different resolving mechanisms. Fully Qualified Domain Names (FQDN) 123 are resolved on the public DNS infrastructure and Unqualified Domain 124 Names are resolved using search lists. 126 As there are different ways to express a name, a resolver may assume 127 the name is a Qualified (resp. Unqualified) Domain Name when in fact 128 the name is an Unqualified (resp. Qualified) Domain Name. In our 129 example, this would lead to a resolution of "foo." over the public 130 DNS infrastructure. If "foo" is being registered in the root zone, 131 then "foo.example." and "foo." will most likely not provide the same 132 responses. The confusion between Unqualified and Qualified Domain 133 Names makes naming resolution unstable and unreliable. 135 To indicate a name is a Fully Qualified Domain Name, one should end 136 it with a dot, however, this has never been accurately be used, and 137 the last dot is most of the time omitted. As a result it has always 138 been confusing to distinguish between Qualified Domain Names and 139 Fully Qualified Domain Names. 141 2.2. Domain Names Collision 143 Even though it has always been confusing, since the number of TLD was 144 very limited, collision would not happen as "foo" differs from 145 existing TLDs. As a result, evaluating "foo" as Fully Qualified 146 Domain Name, would result in resolving "foo." over the public DNS. 147 When the NXDOMAIN response is received, the resolver understands the 148 name is an Unqualified, and use the search list. Overall the impact 149 was quite limited. 151 Similarly, a company may use multiple Domains for its local scope 152 Domain, and provisions its devices with the search list "example 153 example.com". All devices, and network administrators have always 154 considered that the resolution of "foo.example" is either of local 155 scope or fails. As a result, if "foo.example" cannot be resolved, 156 "foo.example.com" is resolved instead. As "example" was not part of 157 the root zone, network administrators have never considered that 158 "foo.example" could actually been resolved on the public DNS 159 infrastructure and provide a response that is different from the one 160 the private Domain. In the context of gTLDs, "example" is likely to 161 be registered in the root zone, and this by another administrative 162 entity than the company using "example" for its private network. 164 As the probability of collision was rather small, multiple ways have 165 been implemented to handle the resolution of names including the way 166 to handle search lists -- as with the implicit expansion mechanism. 167 All of these non standard mechanisms provides a variety of ways a 168 resolution is performed which differs from application to application 169 and from operating systems to operating systems. The collision 170 between private domain names and public domain name makes naming 171 resolution unstable and unreliable. 173 2.3. Structure of the Document 175 With the introduction of generic TLDs (gTLDs), one cannot assume 176 anymore the probability of collision can be ignored. In order to 177 guarantee the stability and reliability of the naming resolution, 178 this document defines in Section 4 how search lists MUST be generated 179 and in Section 5 how search lists MUST be interpreted. Section 6 180 defines how Qualified and Unqualified Domain Names MUST be 181 distinguished and Section 7 defines how resolution for each category 182 of Domain Name MUST be proceeded. 184 The expected outcome of such rules are 1) a more reliable and stable 185 naming resolution and 2) a resolution process that is not impacted by 186 the introduction of new gTLDs. 188 This document is largely based on [SAC064] 190 3. Terminology 192 - Qualified Domain Names or Fully Qualified Domain Name (FQDN) or 193 Absolute Domain Name, is a domain name as defined in [RFC1035] 194 that specifies its exact location in the DNS tree hierarchy, 195 including the public top-level domain and the root zone. By 196 convention, most operating systems treat domain names that include 197 the terminating "." as an FQDN. For example, 198 www.corporation.example.com. specifies an FQDN. 200 - Unqualified Domain Names is a Domain Name that is not expected to 201 be resolved in the public DNS. In other words, such names is not 202 a FQDN. It is usually an internally used domain name (such as 203 "www.corporation") that only becomes an absolute domain name once 204 expanded as a result of search list processing. The ambiguity of 205 such domains is to define whether it is a FQDN or an Unqualified 206 Multi-label Domain Name. If "example.com" is in the search list 207 and if corporation becomes a gTLD, "www.corporation" can be 208 resolved on the public DNS and "www.corporation.example.com" can 209 also be resolved. 211 - Multi-label Domain Name or Relative Multi-label Domain Name, is a 212 domain name that consists of more than one label. 214 - Single Label Domain Name or Dotless Domain Name in some contexts, 215 is a domain name that consists of a single label that is 63 216 characters or less, starts with a letter, ends with a letter or 217 digit, and has as interior characters only letters, digits, and 218 hyphen as defined by [RFC1035]. 220 - Generic Top Level Domain (gTLD) is a top level domain. If the 221 list of these top level domain has been quite stable over the 222 years, this list of top level is not any more restricted. As a 223 result, resolving a name cannot be based anymore on the existence 224 or non-existence of the top level domain as it may evolves over 225 time. 227 - Domain part of a FQDN, is everything after the first dot. 229 4. Search List Generation 231 A search lists is an ordered lists of Domains. When a naming 232 resolution involves a search list for a given name, a resolution is 233 performed for each Domain. Suppose "D1.example.com", "D2.foo", 234 "D3.foo" is a search list and "X" is the name to be resolved. Then, 235 the resolver attempts to resolve successively "X.D1.example.com", 236 "X.D2.foo" and "X.D3.foo" until a response is provided. 238 To guarantee a reliable and stable way to resolve names, one must 239 also determine a deterministic way to build the search list as well 240 as a deterministic way to handle the search list. To our knowledge 241 the search list may be populated by: 243 - 1) An explicit manual search list configuration by the end user. 244 Typically this means the user has manually edit the /etc/ 245 resolv.conf file on a Linux platform, or the suffix field in 246 various applications. 248 - 2) The Domain part of the FQDN assigned to the host. More 249 specifically, the FQDN assigned to the host consists in a Domain 250 appended to a hostname. With DHCPv4 [RFC2131] the Domain is 251 assigned using the DHCP Domain Name Option [RFC2132]. With DHCPv6 252 [RFC3315], the Domain is derived from the DHCPv6 Client FQDN 253 Option [RFC4704]. 255 - 3) A search list assigned to the host via the DHCPv4 Domain Search 256 Option [RFC3397] or the DHCPv6 Domain Search Option [RFC3646]. 258 - 4) Implicit expansion of the search list which consists in 259 expanding the search prefix "corporation.example.com" into the 260 list "corporation.example.com" "example.com" "com". 262 In order to make systems end up with the same search list, here are 263 our recommendations: 265 - 1) If the search list results from a manual configuration, then 266 DHCP Options MUST NOT automatically affect the search list. More 267 specifically, Domain Name derived from DHCPv4 Domain Name Option 268 [RFC2132] or DHCPv6 Client FQDN Option [RFC4704] and DHCP Domain 269 Search Option [RFC3397], [RFC3646] are ignored for the concerned 270 of search list generation. This follows the recommendations of 271 [RFC3397] and [RFC3646]. 273 - 2) If the search list is not manually configured, then DHCP 274 Options MAY be considered. DHCP Domain Search Option [RFC3397], 275 [RFC3646] are considered. If considered, the search list is only 276 defined by these options and only these options. 278 - 3) In the absence of DHCP Domain Search Options, the search list 279 is derived from the Domain that is the DHCPv4 Domain Name Option 280 [RFC2132] or DHCPv6 Client FQDN Option [RFC4704]. If so, the 281 search list is only constituted of the Domain name of the host. 283 - 4) If none of these options are provided, then the search list is 284 empty and resolution are directly performed over the public DNS. 286 5. Search List Interpretation 288 Here is our recommendations to make search list be handled in the 289 same way across systems: 291 - 1) Implicit expansion of search domain name MUST NOT be performed. 292 In fact implicit expansion exposes the resolver to security flaws 293 as described in [RFC1535] and [RFC1536]. As a consequence of not 294 using implicit expansion of search list, search list MUST be 295 explicitly expressed. Suppose a resolver is expected to resolve a 296 hostname within "paris.corporation.example.com" and then 297 "corporation.example.com". In this case, the associated search 298 list MUST be "paris.corporation.example.com" 299 "corporation.example.com" and MUST NOT be 300 "paris.corporation.example.com". Avoiding implicit expansion 301 addresses the [RFC1535] requirements of indicating the BOUNDARIES 302 of the local scope. Note that indicating explicitly the search 303 list does not significantly increase the size of the DHCP Domain 304 Search Option if the option follows the compression method of 305 domain name encoding in section 4.1.1 of [RFC1035]. However, if 306 the Option length exceeds 255 bytes, [RFC3396] describes how to 307 use long options. 309 6. Distinction of Unqualified and Qualified Domain Names 311 This section defines how the resolver unequivocally considers a name 312 is an Unqualified Domain Name or a Fully Qualified Domain Name. This 313 distinction leads to different resolution process described in 314 Section 7. 316 Any name - that is to say a Single-Label Domain Name or a Multi-Label 317 Domain Names - ending with a dot "." is considered as a Fully 318 Qualified Domain as defined in [RFC1035] and [RFC1535]. 320 A Single-Label Domain Name not ending with a dot is considered as an 321 Unqualified Domain Name as recommended by [RFC3397] and [RFC3646]. 323 A Multi-Label Domain Names is considered as a Qualified Domain Name 324 as recommended by [RFC3397] and [RFC3646]. 326 7. Resolution of Unqualified and Qualified Domain Names 328 This section defines how the resolver MUST proceed for a resolution 329 for Qualified Domain Names and Unqualified Domain Names. 331 For Qualified Domain Names, the resolver MUST proceed to the 332 resolution over the DNS public infrastructure. If the resolution 333 fails, returning a NXDOMAIN, no attempt SHOULD be done to resolve it 334 as an Unqualified Domain Name. 336 For Unqualified Domain Names, the resolver MUST proceed to the 337 resolution using search list. If the resolution fails, returning a 338 NXDOMAIN, no attempt SHOULD be done to resolve it as an Qualified 339 Domain Name. 341 Rules defined above to differentiate Unqualified and Qualified Domain 342 Names are similar as in [RFC3397] and [RFC3646]. However, the 343 resolution process described in this document differs as we do not 344 permit fall backs to resolution on Qualified or Unqualified Domain 345 Names. In fact, [RFC3397] and [RFC3646] defines the resolution as a 346 best guess whether the name is an Unqualified (resp. Qualified) 347 Domain Name. Then, if the resolution fails with an NXDOMAIN, 348 response, the resolver falls back and considers the name as a 349 Qualified (resp. Unqualified) Domain Name. 351 The main purpose at that time was to limit the number of round trips. 352 Processing resolution this way is not any more acceptable in a gTLD 353 context, as it affects the stability and reliability of the naming 354 resolution. Our primary goal in defining how resolution proceeds is 355 to guarantee resolution remains independent of the newly inserted or 356 removed TLD. More specifically, a name that is considered 357 Unqualified must be resolved using search lists, and if the 358 resolution fails, no fall back to Qualified name should be performed. 359 If fall backs are permitted, then the output of the resolution 360 depends on the content of the root zone. Similarly, if a name is 361 considered qualified, no fall back to unqualified should be done. 363 These rules do not make possible the resolution of TLD as Single- 364 Label Domain Name. In this case, the TLD to be resolved SHOULD 365 explicitly mention the resolution MUST be performed over the DNS 366 public infrastructure by appending a dot at the end. Appendix B 367 shows that some TLDs have already associated A/AAAA records. 369 8. IANA Considerations 371 There are no IANA consideration for this document. 373 9. Security Considerations 375 The whole document is about security, more especially naming 376 reliability and stability. 378 The document defines rules to handle search list so a naming 379 resolution remains stable over time. This is done in different ways. 380 First by defining how search lists are generated, and how search 381 lists are interpreted by resolver. Then we designates rules to 382 define in a deterministic manner whether a name to be resolved SHOULD 383 be considered as a Qualified Domain Name or as a Unqualified Domain 384 Name. Each kind of Domain name has its associated resolution 385 process, and we do not permit resolution fall backs. 387 These rules are intended to address the flaws described in [RFC1535] 388 and [RFC1536]. The reason for the late fixing is the gTLD program of 389 the ICANN that make now possible to insert new TLDs in the root zone. 391 As these rules are not currently deployed, most devices will not have 392 clearly defined boundaries between Qualified and Unqualified 393 resolutions. In addition, fall backs resolution between these two 394 categories will happen and MUST be address by administrator before 395 any new gTLD. 397 DNSSEC [RFC4033], [RFC4034] and [RFC4035] is not designed to 398 distinguish Qualified and Unqualified Domain Names. In fact DNSSEC 399 has been designed to provide a proof of integrity and a proof of 400 ownership. In the case of name collision, if "foo." is in the signed 401 root zone and "foo.example.com" is also signed with DNSSEC, then 402 DNSSEC validates both names. DNSSEC can however help to distinguish 403 between "foo." and "foo.exmaple.com" if the application knows the Key 404 Signing Key (KSK) associated to the expected Domain "example.com". 405 In other words, the KSK will be considered as the Trust Anchor for 406 the requested names. 408 DANE [I-D.ietf-dane-ops] uses DNSSEC to provide the cryptographic 409 material, used by the above application or transport layer. If the 410 applications know the certificate or the key used by the layers 411 above, then DANE can be used to distinguish between the expected 412 Names, and the one returned by the resolver. 414 10. Acknowledgment 416 11. References 418 11.1. Normative References 420 [RFC1035] Mockapetris, P., "Domain names - implementation and 421 specification", STD 13, RFC 1035, November 1987. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 427 2131, March 1997. 429 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 430 Extensions", RFC 2132, March 1997. 432 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 433 and M. Carney, "Dynamic Host Configuration Protocol for 434 IPv6 (DHCPv6)", RFC 3315, July 2003. 436 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 437 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 438 November 2002. 440 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 441 Protocol (DHCP) Domain Search Option", RFC 3397, November 442 2002. 444 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 445 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 446 December 2003. 448 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 449 Rose, "DNS Security Introduction and Requirements", RFC 450 4033, March 2005. 452 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 453 Rose, "Resource Records for the DNS Security Extensions", 454 RFC 4034, March 2005. 456 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 457 Rose, "Protocol Modifications for the DNS Security 458 Extensions", RFC 4035, March 2005. 460 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 461 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 462 Option", RFC 4704, October 2006. 464 11.2. Informational References 466 [I-D.ietf-dane-ops] 467 Dukhovni, V. and W. Hardaker, "DANE TLSA implementation 468 and operational guidance", draft-ietf-dane-ops-03 (work in 469 progress), February 2014. 471 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 472 With Widely Deployed DNS Software", RFC 1535, October 473 1993. 475 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 476 Miller, "Common DNS Implementation Errors and Suggested 477 Fixes", RFC 1536, October 1993. 479 [SAC064] "SAC064: SSAC Advisory on DNS "Search List" Processing", 480 An Advisory from the ICANN Security and Stability Advisory 481 Committee, URL: http://www.icann.org/en/groups/ssac/ 482 documents/sac-064-en.pdf, February 2014. 484 Appendix A. Document Change Log 486 [draft-mglt-dnsop-search-list-processing-00.txt]: First version 487 published. 489 Appendix B. TLDs with A/AAAA 491 This section provides a small command line that tests which TLD has 492 an A or a AAAA RRset. 494 wget http://data.iana.org/TLD/tlds-alpha-by-domain.txt 495 for i in `cat tlds-alpha-by-domain.txt`; 496 do 497 a=`dig +short -t A $i.`; 498 aaaa=`dig +short -t AAAA $i.`; 499 if [ "${a}" != "" ] || [ "${aaaa}" != "" ]; 500 then 501 echo $i - A:${a}, AAAA:${aaaa}; 502 fi; 503 sleep 1; 504 done 506 Figure 1: Command Line to test TLD with A/AAAA 508 AC - A:193.223.78.210, AAAA: 509 AI - A:209.59.119.34, AAAA: 510 CM - A:195.24.205.60, AAAA: 511 DK - A:193.163.102.24, AAAA:2a01:630:0:40:b1a:b1a:2011:1 512 GG - A:87.117.196.80, AAAA: 513 IO - A:193.223.78.212, AAAA: 514 JE - A:87.117.196.80, AAAA: 515 PN - A:80.68.93.100, AAAA: 516 SH - A:193.223.78.211, AAAA: 517 TK - A:217.119.57.22, AAAA: 518 TM - A:193.223.78.213, AAAA: 519 TO - A:216.74.32.107, AAAA: 520 UZ - A:91.212.89.8, AAAA: 521 WS - A:64.70.19.33, AAAA: 523 Figure 2: output 525 Author's Address 527 Daniel Migault 528 Orange 529 38 rue du General Leclerc 530 92794 Issy-les-Moulineaux Cedex 9 531 France 533 Phone: +33 1 45 29 60 52 534 Email: daniel.migault@orange.com