idnits 2.17.1 draft-huque-dnsop-multi-provider-dnssec-03.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 (July 1, 2018) is 2098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 459, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft P. Aras 4 Intended status: Informational Salesforce 5 Expires: January 2, 2019 J. Dickinson 6 Sinodun 7 J. Vcelak 8 NS1 9 July 1, 2018 11 Multi Provider DNSSEC models 12 draft-huque-dnsop-multi-provider-dnssec-03 14 Abstract 16 Many enterprises today employ the service of multiple DNS providers 17 to distribute their authoritative DNS service. Deploying DNSSEC in 18 such an environment can have some challenges depending on the 19 configuration and feature set in use. This document will present 20 several deployment models that may be suitable. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 2, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 57 2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Serve Only model . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Sign and Serve model . . . . . . . . . . . . . . . . . . 3 60 2.2.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4 61 2.2.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4 62 2.2.3. Model 3: Shared KSK/ZSK Signing Keys . . . . . . . . 5 63 2.3. Inline Signing model . . . . . . . . . . . . . . . . . . 5 64 2.4. Hybrid model . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Signing Algorithm Considerations . . . . . . . . . . . . . . 5 66 4. Authenticated Denial Considerations . . . . . . . . . . . . . 6 67 4.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7 69 5. Validating Resolver Behavior . . . . . . . . . . . . . . . . 7 70 6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 8 71 6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 9 72 6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 10.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction and Motivation 83 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 84 The source for this draft is maintained in GitHub at: 85 https://github.com/shuque/multi-provider-dnssec 87 Many enterprises today employ the service of multiple DNS providers 88 to distribute their authoritative DNS service. Two providers are 89 fairly typical and this allows the DNS service to survive a complete 90 failure of any single provider. This document outlines some possible 91 models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an 92 environment. 94 2. Deployment Models 96 The two main models discussed are (1) where the zone owner runs a 97 master signing server and essentially treats the managed DNS 98 providers as secondary servers, the "Serve Only" model, and (2) where 99 the managed DNS providers each act like primary servers, signing data 100 received from the zone owner and serving it out to DNS queriers, the 101 "Sign and Serve" model. Inline signing and hybrid models are also 102 briefly mentioned. A large part of this document discusses the Sign 103 and Serve models, which present novel challenges and requirements. 105 2.1. Serve Only model 107 The most straightforward deployment model is one in which the zone 108 owner runs a primary master DNS server, and manages the signing of 109 zone data. The master server uses DNS zone transfer mechanisms 110 (AXFR/IXFR) [RFC5936] [RFC1995] to distribute the signed zone to 111 multiple DNS providers. 113 This is also arguably the most secure model because the zone owner 114 holds the private signing keys. The managed DNS providers cannot 115 serve bogus data (either maliciously or because of compromise of 116 their systems) without detection by validating resolvers. 118 One notable limitation of this model is that it may not work with DNS 119 authoritative server configurations that use certain non-standardized 120 DNS features. Some of these features like DNS based Global Server 121 Load Balancing (GSLB), dynamic failover pools, etc. rely on querier 122 specific responses, or responses based on real-time state 123 examination, and so, the answer and corresponding signature has to be 124 determined at the authoritative server being queried, at the time of 125 the query, or both. (If all possible answer sets for these features 126 are known in advance, it would be possible to pre-compute these 127 answer sets and signatures, but the DNS zone transfer protocol cannot 128 be used to distinguish or transfer such data sets, or the rules used 129 to select among the possible answers.) 131 2.2. Sign and Serve model 133 In this category of models, multiple providers each independently 134 sign and serve the same zone. The zone owner typically uses 135 provider-specific APIs to update zone content at each of the 136 providers, and relies on the provider to perform signing of the data. 137 A key requirement here is to manage the contents of the DNSKEY and DS 138 RRset in such a way that validating resolvers always have a viable 139 path to authenticate the DNSSEC signature chain no matter which 140 provider they query and obtain responses from. This requirement is 141 achieved by having each provider import the Zone Signing Keys of all 142 other providers into their DNSKEY RRsets. 144 These models can support DNSSEC even for the non-standard features 145 mentioned previously, if the DNS providers have the capability of 146 signing the response data generated by those features. Since these 147 responses are often generated dynamically at query time, one method 148 is for the provider to perform online signing (also known as on-the- 149 fly signing). However, another possible approach is to pre-compute 150 all the possible response sets and associated signatures and then 151 algorithmically determine at query time which response set needs to 152 be returned. 154 In the first two of these models, the function of coordinating the 155 DNSKEY or DS RRset does not involve the providers communicating 156 directly with each other, which they are unlikely to do since they 157 typically have a contractual relationship only with the zone owner. 159 The following descriptions consider the case of two DNS providers, 160 but the model is generalizable to any number. 162 2.2.1. Model 1: Common KSK, Unique ZSK per provider 164 o Zone owner holds the KSK, manages the DS record, and is 165 responsible for signing the DNSKEY RRset and distributing the 166 signed DNSKEY RRset to the providers. 168 o Each provider has their own ZSK which is used to sign data. 170 o Providers have an API that owner uses to query the ZSK public key, 171 and insert a combined DNSKEY RRset that includes both ZSKs and the 172 KSK, signed by the KSK. 174 o Key rollovers need coordinated participation of the zone owner to 175 update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for 176 KSK). 178 2.2.2. Model 2: Unique KSK and ZSK per provider 180 o Each provider has their own KSK and ZSK. 182 o Each provider offers an API that the Zone Owner uses to import the 183 ZSK of the other provider into their DNSKEY RRset. 185 o DNSKEY RRset is signed independently by each provider using their 186 own KSK. 188 o Zone Owner manages the DS RRset that includes both KSKs. 190 o Key rollovers need coordinated participation of the zone owner to 191 update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK). 193 2.2.3. Model 3: Shared KSK/ZSK Signing Keys 195 Other possible models could involve the KSK and/or ZSK signing keys 196 shared across providers. Preliminary discussion with several 197 providers has revealed that this is not a model they are comfortable 198 with, again because they want to be independently responsible for 199 securing the signing keys without involvement of other parties they 200 don't have contractual relationships with. A possible way to 201 mitigate this concern might be for the zone owner to operate a 202 networked Hardware Security Module (HSM) which houses the shared 203 signing keys and performs the signing operations. The signing 204 instructions and results are communicated over a secure network 205 channel between the provider and HSM. This could work, but may also 206 pose performance bottlenecks, particularly for providers that perform 207 on-the-fly signing. Due to open questions about the operational 208 viability of this model, it is not discussed further. 210 2.3. Inline Signing model 212 In this model, the zone owner runs a master server but does not 213 perform zone signing, instead pushing out the zone (typically via 214 zone transfer mechanisms) to multiple providers, and relying on those 215 providers to sign the zone data before serving them out. This model 216 has to address the same set of requirements as the Sign-and-Serve 217 model regarding managing the DNSKEY and DS RRsets. However, assuming 218 standardized zone transfers mechanisms are being used to push out the 219 zone to the providers, it likely also has the limitation that non- 220 standardized DNS features cannot be supported or signed. This model 221 is not discussed further. 223 2.4. Hybrid model 225 In the hybrid model, the zone owner uses one provider as the primary, 226 operating in Sign and Serve mode. The other providers operate in 227 Serve Only mode, i.e., they are configured as secondary servers, 228 obtaining the signed zone from the primary provider using the DNS 229 zone transfer protocol. This model suffers from the same limitations 230 as the Serve-Only model. It additionally requires the signing keys 231 to be held by the primary provider. 233 3. Signing Algorithm Considerations 235 In the Serve Only and Hybrid models, one entity (the Zone Owner in 236 the former, and the primary provider in the latter) performs the 237 signing and hence chooses the signing algorithm to be deployed. The 238 more interesting case is the Sign and Serve model (Section 2.2), 239 where multiple providers independently sign zone data. 241 Ideally, the providers should be using a common signing algorithm 242 (and common keysizes for algorithms that support variable key sizes). 243 This ensures that the multiple providers have identical security 244 postures and no provider is more vulnerable to cryptanalytic attack 245 than the others. 247 It may however be possible to deploy a configuration where different 248 providers use different signing algorithms. The main impediment is 249 that current DNSSEC specifications require that if there are multiple 250 algorithms in the DNSKEY RRset, then RRsets in the zone need to be 251 signed with at least one DNSKEY of each algorithm, as described in 252 RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781], 253 Section 4.1.4, also describes both a conservative and liberal 254 interpretation of this requirement. When validating DNS resolvers 255 follow the liberal approach, they do not expect that zone RRsets are 256 signed by every signing algorithm in the DNSKEY RRset, and responses 257 with single algorithm signatures can be validated corectly assuming a 258 valid chain of trust exists. In fact, testing by the .BR Top Level 259 domain for their planned algorithm rollover [BR-ROLLOVER], 260 demonstrates that the liberal approach works. 262 4. Authenticated Denial Considerations 264 Authentiated denial of existence enables a resolver to validate that 265 a record does not exist. For this purpose, an authoritative server 266 presents in a response to the resolver special NSEC (Section 3.1.3 of 267 [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3 268 method enhances NSEC by providing opt-out for signing insecure 269 delegations and also adds limited protection against zone enumeration 270 attacks. 272 An authoritative server response carrying records for authenticated 273 denial is always self-contained and the receiving resolver doesn't 274 need to send additional queries to complete the denial proof data. 275 For this reason, no rollover is needed when switching between NSEC 276 and NSEC3 for a signed zone. 278 Since authenticated denial responses are self-contained, NSEC and 279 NSEC3 can be used by different providers to serve the same zone. 280 Doing so however defeats the protection against zone enumeration 281 provided by NSEC3. A better configuration involves multiple 282 providers using different authenticated denial of existence 283 mechanisms that all provide zone enumeration defense, such as pre- 284 computed NSEC3, NSEC3 White Lies [RFC7129], NSEC Black Lies 285 [BLACKLIES], etc. Note however that having multiple providers 286 offering different authenticated denial mechanisms may impact how 287 effectively resolvers are able to make use of the caching of negative 288 responses. 290 4.1. Single Method 292 Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the 293 methods are not used at the same time by different servers). This 294 configuration is prefered because the behavior is well-defined and 295 it's closest to the current operational practice. 297 4.2. Mixing Methods 299 Compliant resolvers should be able to serve zones when different 300 authoritative servers for the same zone respond with different 301 authentiated denial methods because this is normally observed when 302 NSEC and NSEC3 are being switched or when NSEC3PARAM is updated. 304 Resolver software may be however designed to handle a single 305 transition between two authenticated denial configurations more 306 optimally than permanent setup with mixed authenticated denial 307 methods. This could make caching on the resolver side less efficient 308 and the authoritative servers may observe higher number of queries. 309 This aspect should be considered especially in context of Aggresive 310 Use of DNSSEC-Validated Cache [RFC8198]. 312 In case all providers cannot be configured for a matching 313 authentiated denial, it is advised to find lowest number of possible 314 configurations possible across all used providers. 316 Note that NSEC3 configuration on all providers with different 317 NSEC3PARAM values is considered a mixed setup. 319 5. Validating Resolver Behavior 321 From the point of view of the Validating Resolver, the Sign and Serve 322 models (Section 2.2), that employ multiple providers signing the same 323 zone data with distinct keys, are the most interesting. In these 324 models, for each provider, the Zone Signing Keys of the other 325 providers are imported into the DNSKEY RRset and the DNSKEY RRset is 326 re-signed. If this is not done, the following situation can arise 327 (assuming two providers A and B): 329 o The validating resolver follows a referral (delegation) to the 330 zone in question. 332 o It retrieves the zone's DNSKEY RRset from one of provider A's 333 nameservers. 335 o At some point in time, the resolver attempts to resolve a name in 336 the zone, while the DNSKEY RRset received from provider A is still 337 viable in its cache. 339 o It queries one of provider B's nameservers to resolve the name, 340 and obtains a response that is signed by provider B's ZSK, which 341 it cannot authenticate because this ZSK is not present in its 342 cached DNSKEY RRset for the zone that it received from provider A. 344 o The resolver will not accept this response. It may still be able 345 to ultimately authenticate the name by querying other nameservers 346 for the zone until it elicits a response from one of provider A's 347 nameservers. But it has incurred the penalty of additional 348 roundtrips with other nameservers, with the corresponding latency 349 and processing costs. The exact number of additional roundtrips 350 depends on details of the resolver's nameserver selection 351 algorithm and the number of nameservers configured at provider B. 353 o It may also be the case that a resolver is unable to provide an 354 authenticated response because it gave up after a certain number 355 of retries or a certain amount of delay. Or that downstream 356 clients of the resolver that originated the query timed out 357 waiting for a response. 359 Zone owners will want to deploy a DNS service that responds as 360 efficiently as possible with validatable answers only, and hence it 361 is important that the DNSKEY RRset at each provider is maintained 362 with the active ZSKs of all participating providers. This ensures 363 that resolvers can validate a response no matter which provider's 364 nameservers it came from. 366 Details of how the DNSKEY RRset itself is validated differs. In Sign 367 and Serve model 1 (Section 2.2.1), one unique KSK managed by the Zone 368 Owner signs an identical DNSKEY RRset deployed at each provider, and 369 the signed DS record in the parent zone refers to this KSK. In Sign 370 and Serve model 2 (Section 2.2.2), each provider has a distinct KSK 371 and signs the DNSKEY RRset with it. The Zone Owner deploys a DS 372 RRset at the parent zone that contains multiple DS records, each 373 referring to a distinct provider's KSK. Hence it does not matter 374 which provider's nameservers the resolver obtains the DNSKEY RRset 375 from, the signed DS record in each model can authenticate the 376 associated KSK. 378 6. Key Rollover Considerations 380 The Sign-and-Serve (Section 2.2) models introduce some new 381 requirements for DNSSEC key rollovers. Since this process 382 necessarily involves co-ordinated actions on the part of providers 383 and the Zone Owner, one reasonable strategy is for the Zone Owner to 384 initiate key rollover operations. But other operationally plausible 385 models may also suit, such as a DNS provider initiating a key 386 rollover and signaling their intent to the Zone Owner in some manner. 388 The descriptions in this section assume that KSK rollovers employ the 389 commonly used Double Signature KSK Rollover Method, and that ZSK 390 rollovers employ the Pre-Publish ZSK Rollover Method, as described in 391 detail in [RFC6781]. With minor modifications, they can also be 392 easily adapted to other models, such as Double DS KSK Rollover or 393 Double Signature ZSK rollover, if desired. 395 6.1. Model 1: Common KSK, Unique ZSK per provider 397 o Key Signing Key Rollover: In this model, the two managed DNS 398 providers share a common KSK which is held by the Zone Owner. To 399 initiate the rollover, the Zone Owner generates a new KSK and 400 obtains the DNSKEY RRset of each DNS provider using their 401 respective APIs. The new KSK is added to each provider's DNSKEY 402 RRset and the RRset is re-signed with both the new and the old 403 KSK. This new DNSKEY RRset is then transferred to each provider. 404 The Zone Owner then updates the DS RRset in the parent zone to 405 point to the new KSK, and after the necessary DS record TTL period 406 has expired, proceeds with updating the DNSKEY RRSet to remove the 407 old KSK. 409 o Zone Signing Key Rollover: In this model, each DNS provider has 410 separate Zone Signing Keys. Each provider can choose to roll 411 their ZSK independently by co-ordinating with the Zone Owner. 412 Provider A would generate a new ZSK and communicate their intent 413 to perform a rollover (note that Provider A cannot immediately 414 insert this new ZSK into their DNSKEY RRset because the RRset has 415 to be signed by the Zone Owner). The Zone Owner obtains the new 416 ZSK from Provider A. It then obtains the current DNSKEY RRset 417 from each provider (including Provider A), inserts the new ZSK 418 into each DNSKEY RRset, re-signs the DNSKEY RRset, and sends it 419 back to each provider for deployment via their respective key 420 management APIs. Once the necessary time period is elapsed (i.e. 421 all zone data has been re-signed by the new ZSK and propagated to 422 all authoritative servers for the zone, plus the maximum zone TTL 423 value of any of the data in the zone signed by the old ZSK), 424 Provider A and the zone owner can initiate the next phase of 425 removing the old ZSK. 427 6.2. Model 2: Unique KSK and ZSK per provider 429 o Key Signing Key Rollover: In Model 2, each managed DNS provider 430 has their own KSK. A KSK roll for provider A does not require any 431 change in the DNSKEY RRset of provider B, but does require co- 432 ordination with the Zone Owner in order to get the DS record set 433 in the parent zone updated. The KSK roll starts with Provider A 434 generating a new KSK and including it in their DNSKEY RRSet. The 435 DNSKey RRset would then be signed by both the new and old KSK. 436 The new KSK is communicated to the Zone Owner, after which the 437 Zone Owner updates the DS RRset to replace the DS record for the 438 old KSK with a DS record for the new ZSK. After the necessary DS 439 RRset TTL period has elapsed, the old KSK can be removed from 440 provider A's DNSKEY RRset. 442 o Zone Signing Key Rollover: In Model 2, each managed DNS provider 443 has their own ZSK. The ZSK roll for provider A would start with 444 them generating new ZSK and including it in their DNSKEY RRset and 445 re-signing the new DNSKEY RRset with their KSK. The new ZSK of 446 provider A would then be communicated to the Zone Owner, who will 447 initiate the process of importing this ZSK into the DNSKEY RRsets 448 of the other providers, using their respective APIs. Once the 449 necessary Pre-Publish key rollover time periods have elapsed, 450 provider A and the Zone Owner can initiate the process of removing 451 the old ZSK from the DNSKEY RRset of all providers. 453 7. IANA Considerations 455 This document includes no request to IANA. 457 8. Security Considerations 459 [TBD] 461 9. Acknowledgments 463 This document benefited from discussions with and review from Duane 464 Wessels and David Blacka. 466 10. References 468 10.1. Normative References 470 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 471 DOI 10.17487/RFC1995, August 1996, . 474 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 475 Rose, "DNS Security Introduction and Requirements", 476 RFC 4033, DOI 10.17487/RFC4033, March 2005, 477 . 479 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 480 Rose, "Resource Records for the DNS Security Extensions", 481 RFC 4034, DOI 10.17487/RFC4034, March 2005, 482 . 484 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 485 Rose, "Protocol Modifications for the DNS Security 486 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 487 . 489 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 490 Security (DNSSEC) Hashed Authenticated Denial of 491 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 492 . 494 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 495 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 496 . 498 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 499 Operational Practices, Version 2", RFC 6781, 500 DOI 10.17487/RFC6781, December 2012, . 503 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 504 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 505 July 2017, . 507 10.2. Informative References 509 [BLACKLIES] 510 Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of 511 Existence or Black Lies", . 514 [BR-ROLLOVER] 515 Neves, F., ".br DNSSEC Algorithm Rollover Update", 516 in ICANN 62 DNSSEC Workshop, June 2018, 517 . 520 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 521 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 522 February 2014, . 524 Authors' Addresses 526 Shumon Huque 527 Salesforce 529 Email: shuque@gmail.com 531 Pallavi Aras 532 Salesforce 534 Email: paras@salesforce.com 536 John Dickinson 537 Sinodun 539 Email: jad@sinodun.com 541 Jan Vcelak 542 NS1 544 Email: jvcelak@ns1.com