idnits 2.17.1 draft-huque-dnsop-multi-provider-dnssec-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 : ---------------------------------------------------------------------------- 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 03, 2018) is 2245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 266, but not defined == Unused Reference: 'RFC3552' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC6781' is defined on line 290, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 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 04, 2018 March 03, 2018 7 Multi Provider DNSSEC models 8 draft-huque-dnsop-multi-provider-dnssec-01 10 Abstract 12 Many enterprises today employ the service of multiple DNS providers 13 to distribute their authoritative DNS service. Deploying DNSSEC in 14 such an environment can have some challenges depending on the 15 configuration and feature set in use. This document will present 16 several deployment models that may be suitable. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 04, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 53 2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 2 54 2.1. Serve Only model . . . . . . . . . . . . . . . . . . . . 2 55 2.2. Sign and Serve model . . . . . . . . . . . . . . . . . . 3 56 2.2.1. Model 1 . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2.2. Model 2 . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2.3. Other Models . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Inline Signing model . . . . . . . . . . . . . . . . . . 4 60 3. Signing Algorithm Considerations . . . . . . . . . . . . . . 5 61 4. Validating Resolver Behavior . . . . . . . . . . . . . . . . 5 62 5. Key Rollover Considerations . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction and Motivation 72 Many enterprises today employ the service of multiple DNS providers 73 to distribute their authoritative DNS service. Two providers are 74 fairly typical and this allows the DNS service to survive a complete 75 failure of any single provider. This document outlines some possible 76 models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an 77 environment. 79 2. Deployment Models 81 The two main models discussed are (1) where the zone owner runs a 82 master signing server and essentially treats the managed DNS 83 providers as secondary servers, the "Serve Only" model, and (2) where 84 the managed DNS providers each act like primary servers, signing data 85 received from the zone owner and serving it out to DNS queriers, the 86 "Sign and Serve" model. 88 2.1. Serve Only model 90 The most straightforward deployment model is one in which the zone 91 owner runs a primary master DNS server, and manages the signing of 92 zone data. The master server uses DNS zone transfer mechanisms (AXFR 93 /IXFR) to distribute the signed zone to multiple DNS providers. 95 This is also arguably the most secure model because the zone owner 96 holds the private signing keys. The managed DNS providers cannot 97 serve bogus data (either maliciously or because of compromise of 98 their systems) without detection by validating resolvers. 100 One notable limitation of this model is that it may not work with DNS 101 authoritative server configurations that use certain non-standardized 102 DNS features. Some of these features like DNS based Global Server 103 Load Balancing (GSLB), dynamic failover pools, etc. rely on querier 104 specific responses, or responses based on real-time state 105 examination, and so, the answer and corresponding signature has to be 106 determined at the authoritative server being queried, at the time of 107 the query, or both. (If all possible answer sets for these features 108 are known in advance, it would be possible to pre-compute these 109 answer sets and signatures, but the DNS zone transfer protocol cannot 110 be used to distinguish or transfer such data sets, or the rules used 111 to select among the possible answers.) 113 2.2. Sign and Serve model 115 In this category of models, multiple providers each independently 116 sign and serve the same zone. The zone owner typically uses 117 provider-specific APIs to update zone content at each of the 118 providers, and relies on the provider to perform signing of the data. 119 A key requirement here is to manage the contents of the DNSKEY and DS 120 RRset in such a way that validating resolvers always have a viable 121 path to authenticate the DNSSEC signature chain no matter which 122 provider they query and obtain responses from. 124 These models can support DNSSEC even for the non-standard features 125 mentioned previously, if the DNS providers have the capability of 126 signing the response data generated by those features. Since these 127 responses are often generated dynamically at query time, one method 128 is for the provider to perform online signing (also known as on-the- 129 fly signing). However, another possible approach is to pre-compute 130 all the possible response sets and associated signatures and then 131 algorithmically determine at query time which response set needs to 132 be returned. 134 In these models, the function of coordinating the DNSKEY or DS RRset 135 does not involve the providers communicating directly with each 136 other, which they are unlikely to do since they typically have a 137 contractual relationship only with the zone owner. 139 The following descriptions consider the case of two DNS providers, 140 but the model is generalizable to any number. 142 2.2.1. Model 1 144 o Zone owner holds the KSK and manages the DS record. 146 o Each provider has their own ZSK which is used to sign data. 148 o Providers have an API that owner uses to query the ZSK. public 149 key, and insert a combined DNSKEY RRset that includes both ZSKs 150 and the KSK, signed by the KSK. 152 o Key rollovers need coordinated participation of the zone owner to 153 update and re-sign the DNSKEY RRset. 155 2.2.2. Model 2 157 o Each provider has their own KSK and ZSK. 159 o Each provider also includes the ZSK of the other provider - 160 delivered to them by the zone owner via some API mechanism. 162 o DNSKEY RRset is signed independently by each provider using their 163 own KSK. 165 o Zone owner manages the DS RRset that includes both KSKs. 167 o KSK rollovers need coordinated participation of the zone owner to 168 update the DS RRset. 170 2.2.3. Other Models 172 Possible models in which KSK and/or ZSK key pairs are shared across 173 providers are not currently discussed. Preliminary discussion with 174 some providers has revealed that this is not a mode all of them are 175 comfortable with, as they do not want to share signing keys with 176 other parties. 178 2.3. Inline Signing model 180 In this model, the zone owner runs a master server but does not 181 perform zone signing, instead pushing out the zone (typically via 182 zone transfer mechanisms) to multiple providers, and relying on those 183 providers to sign the zone data before serving them out. This model 184 has to address the same set of requirements as the Sign-and-Serve 185 model regarding managing the DNSKEY and DS RRsets. However, assuming 186 standardized zone transfers mechanisms are being used to push out the 187 zone to the providers, it likely also has the limitation that non- 188 standardized DNS features cannot be supported or signed. This model 189 is not discussed further. 191 3. Signing Algorithm Considerations 193 [TBD: at the very least we have to note whether any or all of these 194 schemes require algorithms to be the same or not, or benefit from 195 algorithms being the same. Current DNS specifications indicate that 196 if there are multiple algorithms in the DNSKEY RRset, then data 197 records need to be signed with at least one of each algorithm, (how 198 does that work with online signing?). Multiple signatures per record 199 set is a cost that probably few operators want to bear.] 201 4. Validating Resolver Behavior 203 From the point of view of the Validating Resolver, the Sign and Serve 204 models (Section 2.2), that employ multiple providers signing the same 205 zone data with distinct keys, are the most interesting. In these 206 models, for each provider, the Zone Signing Keys of the other 207 providers are imported into the DNSKEY RRset and the DNSKEY RRset is 208 re-signed. If this is not done, the following situation can arise 209 (assuming two providers A and B): 211 o The validating resolver follows a referral (delegation) to the 212 zone in question. 214 o It retrieves the zone's DNSKEY RRset from one of provider A's 215 nameservers. 217 o At some point in time, the resolver attempts to resolve a name in 218 the zone, while the DNSKEY RRset received from provider A is still 219 viable in its cache. 221 o It queries one of provider B's nameservers to resolve the name, 222 and obtains a response that is signed by provider B's ZSK, which 223 it cannot authenticate because this ZSK is not present in its 224 cached DNSKEY RRset for the zone that it received from provider A. 226 o The resolver will not accept this response. It may still be able 227 to ultimately authenticate the name by querying other nameservers 228 for the zone until it elicits a response from one of provider A's 229 nameservers. But it has incurred the penalty of additional 230 roundtrips with other nameservers, with the corresponding latency 231 and processing costs. The exact number of additional roundtrips 232 depends on details of the resolver's nameserver selection 233 algorithm and the number of nameservers configured at provider B. 235 o Zone owners will want to deploy a DNS service that responds as 236 efficiently as possible with validatable answers, and hence it is 237 important that the DNSKEY RRset is maintained with the ZSKs of all 238 participating providers. 240 As long as the DNSKEY RRset at each provider contains the active ZSKs 241 of all the providers, resolvers can validate a response no matter 242 which provider's nameservers it came from. 244 Details of how the DNSKEY RRset itself is validated differs. In Sign 245 and Serve model 1 (Section 2.2.1), one unique KSK managed by the Zone 246 Owner signs an identical DNSKEY RRset deployed at each provider, and 247 the signed DS record in the parent zone refers to this KSK. In Sign 248 and Serve model 2 (Section 2.2.2), each provider has a distinct KSK 249 and signs the DNSKEY RRset with it. The Zone Owner deploys a DS 250 RRset at the parent zone that contains multiple DS records, each 251 referring to a distinct provider's KSK. Hence it does not matter 252 which provider's nameservers the resolver obtains the DNSKEY RRset 253 from, the signed DS record in each model can authenticate the 254 associated KSK. 256 5. Key Rollover Considerations 258 TBD 260 6. IANA Considerations 262 This document includes no request to IANA. 264 7. Security Considerations 266 [TBD] 268 8. References 270 8.1. Normative References 272 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 273 Rose, "DNS Security Introduction and Requirements", RFC 274 4033, March 2005. 276 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 277 Rose, "Resource Records for the DNS Security Extensions", 278 RFC 4034, March 2005. 280 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 281 Rose, "Protocol Modifications for the DNS Security 282 Extensions", RFC 4035, March 2005. 284 8.2. Informative References 286 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 287 Text on Security Considerations", BCP 72, RFC 3552, July 288 2003. 290 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 291 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 292 RFC6781, December 2012, 293 . 295 Authors' Addresses 297 Shumon Huque 298 Salesforce 300 Email: shuque@gmail.com 302 Pallavi Aras 303 Salesforce 305 Email: paras@salesforce.com