idnits 2.17.1 draft-fujiwara-dnsop-resolver-update-00.txt: -(417): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2181, but the abstract doesn't seem to directly say this. It does mention RFC2181 though, so this could be OK. -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 01, 2016) is 2732 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 7719 (Obsoleted by RFC 8499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Fujiwara 3 Internet-Draft JPRS 4 Updates: 1034, 2181 (if approved) November 01, 2016 5 Intended status: Standards Track 6 Expires: May 5, 2017 8 Updating Resolver Algorithm 9 draft-fujiwara-dnsop-resolver-update-00 11 Abstract 13 Parent side NS RRSet and glue records are all information to access 14 servers for child zone. However, they may be overwritten by child 15 zone data (zone apex NS RRSet and other A/AAAA RRSets). The 16 overwrite makes name resolution unstable and induces vulnerabilities. 17 RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it 18 is deemed that that all cached data (authoritative data, non- 19 authoritative data, referrals and glue records) are merged into one. 20 Resolvers may answer non-authoritative data, referrals and glue 21 records that should not be returned. This document proposes updating 22 resolver algorithm that separates the cache to "authoritative data 23 cache" and "delegation cache". The former is used to answer stub 24 resolvers, and the latter is used to iterate zones. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 5, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Traditional resolver algorithm . . . . . . . . . . . . . . . 3 63 3.1. Importance of parent side NS RRSet . . . . . . . . . . . 3 64 3.2. Recommendation of resolver's answer . . . . . . . . . . . 4 65 3.3. Traditional resolver algorithm . . . . . . . . . . . . . 5 66 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Updating of Resolver Algorithm . . . . . . . . . . . . . . . 6 68 5.1. Recommendations to resolvers . . . . . . . . . . . . . . 6 69 5.2. Update to resolver algorithm . . . . . . . . . . . . . . 6 70 5.3. Characteristics of the update . . . . . . . . . . . . . . 7 71 5.4. Issues of the update . . . . . . . . . . . . . . . . . . 8 72 6. Implementation Ideas . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 76 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 11.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Resolver algorithm is defined in [RFC1034] and updated by [RFC2181]. 85 The resolver algorithm seems to assume single cache that holds all 86 RRSets from received responses. [RFC2181] Section 5.4.1 Ranking data 87 specifies the trustworthiness order of RRSets. When a resolver 88 receives higher trustworthy data, the cached data is replaced by the 89 received data. 91 Parent side NS RRSet is very important because it creates new zone 92 and specifies how to access name servers for the created zone 93 described in Section 3.1. However, parent side NS RRSets and glue 94 records have least trustworthiness. The parent side NS RRSets and 95 glue records are replaced by authoritative data if resolvers receive 96 authoritative data described in Section 3.3. 98 The overwrite makes name resolution unstable and some vulnerabilities 99 described in Section 4. And it may break requirements of resolvers' 100 answers described in Section 3.2. 102 This document proposes updated resolver algorithm that separate 103 authoritative data cache that is answered to stub resolvers and 104 delegation cache that is used to iterate zones. Details are 105 described in Section 5 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 Many of the specialized terms used in this specification are defined 114 in DNS Terminology [RFC7719]. 116 3. Traditional resolver algorithm 118 [RFC1034] defines "zone cut", "delegation", "referral", "glue 119 records", "authoritative", and "resolver algorithm". 121 [RFC2181] clarified the resolver algorithm defined in [RFC1034]. 123 3.1. Importance of parent side NS RRSet 125 [RFC1034], [RFC2181] and [RFC7719] defines zone "cut", "delegation", 126 "referral", and parent side NS RRSet functions as follows. 128 "'cuts' in the name space can be made between any two adjacent nodes. 129 After all cuts are made, each group of connected name space is a 130 separate zone. The zone is said to be authoritative for all names in 131 the connected region." (Quoted from RFC 1034, Section 4.2) 133 "The RRs that describe cuts around the bottom of the zone are NS RRs 134 that name the servers for the subzones. Since the cuts are between 135 nodes, these RRs are NOT part of the authoritative data of the zone, 136 and should be exactly the same as the corresponding RRs in the top 137 node of the subzone." (Quoted from RFC 1034, section 4.2.1) 139 "That is, parent zones have all the information needed to access 140 servers for their children zones." (Quoted from RFC 1034, section 141 4.2.1) 142 "Resolvers must be able to access at least one name server and use 143 that name server's information to answer a query directly, or pursue 144 the query using referrals to other name servers." (Quoted from RFC 145 1034, Section 2.4) 147 "Delegation is the process by which a separate zone is created in the 148 name space beneath the apex of a given domain. Delegation happens 149 when an NS RRset is added in the parent zone for the child origin." 150 (Quoted from RFC 7719) 152 "This situation typically occurs when the glue address RRs have a 153 smaller TTL than the NS RRs marking delegation," (Quoted from RFC 154 1035, Section 7.2) 156 "The existence of a zone cut is indicated in the parent zone by the 157 existence of NS records specifying the origin of the child zone." 158 (Quoted from RFC 2181, Section 6) 160 As described above, parent side NS RRSet makes a new zone. Parent 161 side NS RRSet (referral) and glue records are all the information to 162 access servers for the child zone. 164 That is, resolvers SHOULD NOT use child side NS RRSet to iterate 165 zones. 167 3.2. Recommendation of resolver's answer 169 RFC 1034 describes resolver's answer as follows. 171 "The ideal answer is one from a server authoritative for the query 172 which either gives the required data or a name error. The data is 173 passed back to the user and entered in the cache for future use if 174 its TTL is greater than zero." (Quoted from RFC 1034, Section 5.3.3) 176 "The simplest mode for the client is recursive, since in this mode 177 the name server acts in the role of a resolver and returns either an 178 error or the answer, but never referrals." (Quoted from RFC 1034, 179 Section 4.3.1) 181 Recently, most of full-service resolver implementations answer only 182 authoritative data to stub resolvers. 184 As described above, recommendation of resolver's answer is "answer 185 only authoritative data." It does not break existing standards. 187 3.3. Traditional resolver algorithm 189 Resolver algorithm is defined in [RFC1034] Section 5.3.3. Resolvers 190 cache all RRSets during the iterations in their cache. When 191 resolvers receive new data, they will update their cache. The update 192 is explained using an example resolution of "www.example.com/A" in 193 "example.com" zone as follows. 195 When a resolver iterates "www.example.com/A" query, then one of root 196 servers responds "com" NS RRSet (referral) with glue records, one of 197 "com" servers responds "example.com" NS RRSet with glue records, and 198 one of "example.com" servers responds "www.example.com" A RRSet. 200 As a result, the resolver caches all RRSets during the iterations in 201 its cache. 203 After then, a resolver receives "example.com/NS" query, it retrieves 204 "example.com" NS authoritative data defined in zone apex of 205 "example.com" and it overwrites "example.com/NS" in the resolver's 206 cache as "trustworthiness" rule of [RFC2181]. 208 If the parent side "example.com" NS RRSet and the child side 209 "example.com" NS RRSet are different, next resolution result will be 210 changed because the resolver will send "www.example.com/A" query to 211 name servers that are specified by "example.com" NS RRSet defined in 212 zone apex. Glue records in the cache are also overwritten by 213 authoritative data, and then, IP addresses of name servers that the 214 resolver send to will be changed. 216 The other case, if one of "example.com" name servers responds 217 "www.example.com" A RRSet with "example.com" NS RRSet in authority 218 section (several existing authoritative server implementations 219 perform this) , "example.com" NS RRSet from "com" TLD servers 220 (referral) is overwritten by "example.com" NS data attached in the 221 authoritative answer from child zone. 223 The overwrite is specified by [RFC2181] Section 5.4.1 Ranking data. 224 "Referrals" is the ranking 7: "Data from the authority section of a 225 non-authoritative answer". And "example.com" NS RRSet attached in 226 the authoritative answer is the ranking 4: "Data from the authority 227 section of an authoritative answer". 229 4. Problem Statement 231 [RFC1034] section 4.2.1 states that "the parent side NS RRSet should 232 be exactly the same as the corresponding RRs in the top node of the 233 subzone". 235 However, people sets different NS RRSets with mistakes, or 236 intentionally. Name server configuration changes will make the 237 differences because the changes take time. 239 If the zone data of name server(s) specified by referrals and 240 specified by zone apex NS RRSet are different, name resolution 241 becomes unstable. The cache overwrite of NS RRSet may break 242 "Referrals and glue records are information to access servers for 243 child zones" specified by [RFC1034] section 4.2.1. 245 The overwrite by zone apex NS RRSet induced security vulnerabilities. 246 In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable" 247 [DUAN2012GHOST] was reported. The attack uses updates of NS RRSet 248 attached in authoritative answer. Assume a resolver caches and uses 249 zone apex NS RRSet, and the parent side NS RRSet is updated or 250 removed. The resolver send queries to name servers specified by zone 251 apex NS RRSet and update NS RRSet by the NS RRSet attached in the 252 authority section of the answer. Parent side NS RRSet specifies the 253 existence of delegation, however, resolvers may not check the 254 existence of the parent side NS RRSet and the domain name will remain 255 in the resolvers. 257 DNS software vendors fixed the problem to restrict the TTL of NS 258 RRSet not to exceed the cached TTL value of old NS RRSet when 259 replacing it. 261 5. Updating of Resolver Algorithm 263 5.1. Recommendations to resolvers 265 Resolvers MUST answer one of the following results: required data, 266 name error, or empty (NODATA) from a server that is authoritative for 267 the query, other name resolution errors (SERVFAIL, REFUSED), or no 268 answer. 270 Resolvers iterate queries using referrals with corresponding glue 271 records to other name servers. If referrals contain out-of-bailiwick 272 name server names, resolvers need to resolve address records of out- 273 of-bailiwick name servers. 275 Resolvers MUST NOT use glue records and referrals except iterating 276 delegations. Resolvers MUST NOT use zone apex NS RRSets to iterate. 278 5.2. Update to resolver algorithm 280 This document update RFC 1034 Section 5.3.3. Algorithm as follows. 282 Separate the cache into "authoritative data cache" and "delegation 283 cache". Pre-load root hint information (root NS RRSet and root 284 server addresses) into the delegation cache. 286 "Step 4.a." is changed as "if the response answers the question or 287 contains a name error, cache the data into authoritative cache as 288 well as returning it back to the client". 290 "Step 4.b." is changed as if the response contains a better 291 delegation to other servers, cache the delegation information into 292 delegation cache, and go to step 2". 294 The cache in "Step 1" is the authoritative data cache. 296 The cache used in "step 2" is the delegation cache. "Set up their 297 addresses using local data" is replaced as "Set up their addresses 298 using the delegation cache". 300 As a result, RFC 2181 Section 5.4.1 Ranking data becomes useless 301 because the overwrite will not happen. Pre-loaded zone files (or 302 zones retrieved from zone transfer) are treated as answers from 303 authoritative servers. They are treated as static authoritative 304 data, referrals, and glue records. Referrals and glue records in 305 pre-loaded zone files MUST NOT be answered to stub resolvers. They 306 MUST be used to iterate name servers only. 308 Root zone is special because it is not delegated. Root hint and 309 priming are exceptions because priming replaces pre-configured root 310 hint by root zone apex NS RRSet (authoritative data). 312 5.3. Characteristics of the update 314 This update does not change resolver algorithm described in RFC 1034 315 section 5.3.3, except updates of referrals. It separates 316 authoritative data (possible to answer) and referrals (used to 317 iterate DNS tree). It does not require no special ordering (e.g. 318 trustworthiness and ranking data). It offers more stability of name 319 resolution because the results of traditional name resolution will 320 flap if NS RRSets between the parent and the child are different. 322 This algorithm is similar to traditional algorithm when the cache is 323 empty. 325 The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035] 326 because DNSSEC validates authoritative data and does not validate 327 referrals. 329 The update does not effect to DNS Query Name Minimisation [RFC7816] 330 because answers from authoritative servers don't change. Delegation 331 cache and authoritative data cache separation will need small 332 implementation changes. 334 5.4. Issues of the update 336 This update makes impossible to control of TTL value of NS RRSet by 337 the child zone owner. However, overwrite of the referral does not 338 occur always and TTL control may increase queries to authoritative 339 servers. 341 6. Implementation Ideas 343 Some implementers already implemented similar algorithm to their 344 products. 346 7. IANA Considerations 348 {#:ianacons} 350 This document has no IANA actions. 352 8. Security Considerations 354 9. Acknowledgments 356 10. Change History 358 11. References 360 11.1. Normative References 362 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 363 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 364 . 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 372 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 373 . 375 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 376 Rose, "DNS Security Introduction and Requirements", 377 RFC 4033, DOI 10.17487/RFC4033, March 2005, 378 . 380 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 381 Rose, "Resource Records for the DNS Security Extensions", 382 RFC 4034, DOI 10.17487/RFC4034, March 2005, 383 . 385 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 386 Rose, "Protocol Modifications for the DNS Security 387 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 388 . 390 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 391 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 392 2015, . 394 11.2. Informative References 396 [DUAN2012GHOST] 397 D, H., Jiang, J., Liang, J., Li, K., Li, J., and J. Wu, 398 "Ghost domain names:Revoked yet still resolvable", 2012, 399 . 402 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 403 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 404 . 406 Author's Address 408 Kazunori Fujiwara 409 Japan Registry Services Co., Ltd. 410 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 411 Chiyoda-ku, Tokyo 101-0065 412 Japan 414 Phone: +81 3 5215 8451 415 Email: fujiwara@jprs.co.jp 417