idnits 2.17.1 draft-huque-dnsop-multi-provider-dnssec-02.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 (March 19, 2018) is 2230 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 323, but not defined == Unused Reference: 'RFC3552' is defined on line 356, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: September 20, 2018 J. Dickinson 6 Sinodun 7 J. Vcelak 8 NS1 9 March 19, 2018 11 Multi Provider DNSSEC models 12 draft-huque-dnsop-multi-provider-dnssec-02 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 September 20, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . 2 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. Validating Resolver Behavior . . . . . . . . . . . . . . . . 6 67 5. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction and Motivation 78 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 79 The source for this draft is maintained in GitHub at: https:// 80 github.com/shuque/multi-provider-dnssec 82 Many enterprises today employ the service of multiple DNS providers 83 to distribute their authoritative DNS service. Two providers are 84 fairly typical and this allows the DNS service to survive a complete 85 failure of any single provider. This document outlines some possible 86 models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an 87 environment. 89 2. Deployment Models 91 The two main models discussed are (1) where the zone owner runs a 92 master signing server and essentially treats the managed DNS 93 providers as secondary servers, the "Serve Only" model, and (2) where 94 the managed DNS providers each act like primary servers, signing data 95 received from the zone owner and serving it out to DNS queriers, the 96 "Sign and Serve" model. Inline signing and hybrid models are also 97 briefly mentioned. A large part of this document discusses the Sign 98 and Serve models, which present novel challenges. 100 2.1. Serve Only model 102 The most straightforward deployment model is one in which the zone 103 owner runs a primary master DNS server, and manages the signing of 104 zone data. The master server uses DNS zone transfer mechanisms (AXFR 105 /IXFR) [RFC5936] [RFC1995] to distribute the signed zone to multiple 106 DNS providers. 108 This is also arguably the most secure model because the zone owner 109 holds the private signing keys. The managed DNS providers cannot 110 serve bogus data (either maliciously or because of compromise of 111 their systems) without detection by validating resolvers. 113 One notable limitation of this model is that it may not work with DNS 114 authoritative server configurations that use certain non-standardized 115 DNS features. Some of these features like DNS based Global Server 116 Load Balancing (GSLB), dynamic failover pools, etc. rely on querier 117 specific responses, or responses based on real-time state 118 examination, and so, the answer and corresponding signature has to be 119 determined at the authoritative server being queried, at the time of 120 the query, or both. (If all possible answer sets for these features 121 are known in advance, it would be possible to pre-compute these 122 answer sets and signatures, but the DNS zone transfer protocol cannot 123 be used to distinguish or transfer such data sets, or the rules used 124 to select among the possible answers.) 126 2.2. Sign and Serve model 128 In this category of models, multiple providers each independently 129 sign and serve the same zone. The zone owner typically uses 130 provider-specific APIs to update zone content at each of the 131 providers, and relies on the provider to perform signing of the data. 132 A key requirement here is to manage the contents of the DNSKEY and DS 133 RRset in such a way that validating resolvers always have a viable 134 path to authenticate the DNSSEC signature chain no matter which 135 provider they query and obtain responses from. 137 These models can support DNSSEC even for the non-standard features 138 mentioned previously, if the DNS providers have the capability of 139 signing the response data generated by those features. Since these 140 responses are often generated dynamically at query time, one method 141 is for the provider to perform online signing (also known as on-the- 142 fly signing). However, another possible approach is to pre-compute 143 all the possible response sets and associated signatures and then 144 algorithmically determine at query time which response set needs to 145 be returned. 147 In the first two of these models, the function of coordinating the 148 DNSKEY or DS RRset does not involve the providers communicating 149 directly with each other, which they are unlikely to do since they 150 typically have a contractual relationship only with the zone owner. 152 The following descriptions consider the case of two DNS providers, 153 but the model is generalizable to any number. 155 2.2.1. Model 1: Common KSK, Unique ZSK per provider 157 o Zone owner holds the KSK, manages the DS record, and is 158 responsible for signing the DNSKEY RRset and distributing the 159 signed DNSKEY RRset to the providers. 161 o Each provider has their own ZSK which is used to sign data. 163 o Providers have an API that owner uses to query the ZSK public key, 164 and insert a combined DNSKEY RRset that includes both ZSKs and the 165 KSK, signed by the KSK. 167 o Key rollovers need coordinated participation of the zone owner to 168 update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for 169 KSK). 171 2.2.2. Model 2: Unique KSK and ZSK per provider 173 o Each provider has their own KSK and ZSK. 175 o Each provider offers an API that the Zone Owner uses to import the 176 ZSK of the other provider into their DNSKEY RRset. 178 o DNSKEY RRset is signed independently by each provider using their 179 own KSK. 181 o Zone Owner manages the DS RRset that includes both KSKs. 183 o Key rollovers need coordinated participation of the zone owner to 184 update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK). 186 2.2.3. Model 3: Shared KSK/ZSK Signing Keys 188 Other possible models could involve the KSK and/or ZSK signing keys 189 shared across providers. Preliminary discussion with several 190 providers has revealed that this is not a model they are comfortable 191 with, again because they want to be independently responsible for 192 securing the signing keys without involvement of other parties they 193 don't have contractual relationships with. A possible way to 194 mitigate this concern might be for the zone owner to operate a 195 networked Hardware Security Module (HSM) which houses the shared 196 signing keys and performs the signing operations. The signing 197 instructions and results are communicated over a secure network 198 channel between the provider and HSM. This could work, but may also 199 pose performance bottlenecks, particularly for providers that perform 200 on-the-fly signing. Due to open questions about the operational 201 viability of this model, it is not discussed further. 203 2.3. Inline Signing model 205 In this model, the zone owner runs a master server but does not 206 perform zone signing, instead pushing out the zone (typically via 207 zone transfer mechanisms) to multiple providers, and relying on those 208 providers to sign the zone data before serving them out. This model 209 has to address the same set of requirements as the Sign-and-Serve 210 model regarding managing the DNSKEY and DS RRsets. However, assuming 211 standardized zone transfers mechanisms are being used to push out the 212 zone to the providers, it likely also has the limitation that non- 213 standardized DNS features cannot be supported or signed. This model 214 is not discussed further. 216 2.4. Hybrid model 218 In the hybrid model, the zone owner uses one provider as the primary, 219 operating in Sign and Serve mode. The other providers operate in 220 Serve Only mode, i.e., they are configured as secondary servers, 221 obtaining the signed zone from the primary provider using the DNS 222 zone transfer protocol. This model suffers from the same limitations 223 as the Serve-Only model. It additionally requires the signing keys 224 to be held by the primary provider. 226 3. Signing Algorithm Considerations 228 In the Serve Only and Hybrid models, one entity (the Zone Owner in 229 the former, and the primary provider in the latter) performs the 230 signing and hence chooses the signing algorithm to be deployed. The 231 more interesting case is the Sign and Serve model (Section 2.2), 232 where multiple providers independently sign zone data. 234 Ideally, the providers should be using a common signing algorithm 235 (and common keysizes for algorithms that support variable key sizes). 236 This ensures that the multiple providers have identical security 237 postures and no provider is more vulnerable to cryptanalytic attack 238 than the others. 240 It may however be possible to deploy a configuration where different 241 providers use different signing algorithms. The main impediment is 242 that current DNSSEC specifications require that if there are multiple 243 algorithms in the DNSKEY RRset, then RRsets in the zone need to be 244 signed with at least one DNSKEY of each algorithm, as described in 245 RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781], 246 Section 4.1.4, also describes both a conservative and liberal 247 interpretation of this requirement. When validating DNS resolvers 248 follow the liberal approach, they do not expect that zone RRsets are 249 signed by every signing algorithm in the DNSKEY RRset, and responses 250 with single algorithm signatures can be validated corectly assuming a 251 valid chain of trust exists. [TODO: investigate resolver 252 implementations to see what they actually do.] 254 4. Validating Resolver Behavior 256 From the point of view of the Validating Resolver, the Sign and Serve 257 models (Section 2.2), that employ multiple providers signing the same 258 zone data with distinct keys, are the most interesting. In these 259 models, for each provider, the Zone Signing Keys of the other 260 providers are imported into the DNSKEY RRset and the DNSKEY RRset is 261 re-signed. If this is not done, the following situation can arise 262 (assuming two providers A and B): 264 o The validating resolver follows a referral (delegation) to the 265 zone in question. 267 o It retrieves the zone's DNSKEY RRset from one of provider A's 268 nameservers. 270 o At some point in time, the resolver attempts to resolve a name in 271 the zone, while the DNSKEY RRset received from provider A is still 272 viable in its cache. 274 o It queries one of provider B's nameservers to resolve the name, 275 and obtains a response that is signed by provider B's ZSK, which 276 it cannot authenticate because this ZSK is not present in its 277 cached DNSKEY RRset for the zone that it received from provider A. 279 o The resolver will not accept this response. It may still be able 280 to ultimately authenticate the name by querying other nameservers 281 for the zone until it elicits a response from one of provider A's 282 nameservers. But it has incurred the penalty of additional 283 roundtrips with other nameservers, with the corresponding latency 284 and processing costs. The exact number of additional roundtrips 285 depends on details of the resolver's nameserver selection 286 algorithm and the number of nameservers configured at provider B. 288 o It may also be the case that a resolver is unable to provide an 289 authenticated response because it gave up after a certain number 290 of retries or a certain amount of delay. Or that downstream 291 clients of the resolver that originated the query timed out 292 waiting for a response. 294 Zone owners will want to deploy a DNS service that responds as 295 efficiently as possible with validatable answers only, and hence it 296 is important that the DNSKEY RRset at each provider is maintained 297 with the active ZSKs of all participating providers. This ensures 298 that resolvers can validate a response no matter which provider's 299 nameservers it came from. 301 Details of how the DNSKEY RRset itself is validated differs. In Sign 302 and Serve model 1 (Section 2.2.1), one unique KSK managed by the Zone 303 Owner signs an identical DNSKEY RRset deployed at each provider, and 304 the signed DS record in the parent zone refers to this KSK. In Sign 305 and Serve model 2 (Section 2.2.2), each provider has a distinct KSK 306 and signs the DNSKEY RRset with it. The Zone Owner deploys a DS 307 RRset at the parent zone that contains multiple DS records, each 308 referring to a distinct provider's KSK. Hence it does not matter 309 which provider's nameservers the resolver obtains the DNSKEY RRset 310 from, the signed DS record in each model can authenticate the 311 associated KSK. 313 5. Key Rollover Considerations 315 TBD 317 6. IANA Considerations 319 This document includes no request to IANA. 321 7. Security Considerations 323 [TBD] 325 8. Acknowledgments 327 This document benefited from discussions with and review from Duane 328 Wessels. 330 9. References 332 9.1. Normative References 334 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 335 DOI 10.17487/RFC1995, August 1996, . 338 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 339 Rose, "DNS Security Introduction and Requirements", RFC 340 4033, March 2005. 342 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 343 Rose, "Resource Records for the DNS Security Extensions", 344 RFC 4034, March 2005. 346 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 347 Rose, "Protocol Modifications for the DNS Security 348 Extensions", RFC 4035, March 2005. 350 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 351 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 352 . 354 9.2. Informative References 356 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 357 Text on Security Considerations", BCP 72, RFC 3552, July 358 2003. 360 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 361 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 362 RFC6781, December 2012, 363 . 365 Authors' Addresses 367 Shumon Huque 368 Salesforce 370 Email: shuque@gmail.com 371 Pallavi Aras 372 Salesforce 374 Email: paras@salesforce.com 376 John Dickinson 377 Sinodun 379 Email: jad@sinodun.com 381 Jan Vcelak 382 NS1 384 Email: jvcelak@ns1.com