idnits 2.17.1 draft-huque-dnsop-multi-provider-dnssec-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 (March 02, 2018) is 2246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 210, but not defined == Unused Reference: 'RFC4033' is defined on line 216, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 230, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 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 03, 2018 March 02, 2018 7 Multi Provider DNSSEC models 8 draft-huque-dnsop-multi-provider-dnssec-00 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 03, 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 models . . . . . . . . . . . . . . . . . . 3 56 2.2.1. Model 1 . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2.2. Model 2 . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2.3. Model 3 . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Inline Signing models . . . . . . . . . . . . . . . . . . 4 60 3. Signing Algorithm Considerations . . . . . . . . . . . . . . 4 61 4. Validating Resolver Behavior . . . . . . . . . . . . . . . . 5 62 5. Key Rollover Considerations . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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 deployment in such an environment. 78 2. Deployment Models 80 The two main models discussed are (1) where the zone owner runs a 81 master signing server and essentially treats the managed DNS 82 providers as secondary servers, the "Serve Only" model, and (2) where 83 the managed DNS providers each act like primary servers, signing data 84 received from the zone owner and serving it out to DNS queriers, the 85 "Sign and Serve" model. 87 2.1. Serve Only model 89 The most straightforward deployment model is one in which the zone 90 owner runs a primary master DNS server, and manages the signing of 91 zone data. The master server uses DNS zone transfer mechanisms (AXFR 92 /IXFR) to distribute the signed zone to multiple DNS providers. 94 This is also arguably the most secure model because the zone owner 95 holds the private signing keys. The managed DNS providers cannot 96 serve bogus data (either maliciously or because of compromise of 97 their systems) without detection by validating resolvers. 99 One notable limitation of this model is that it may not work with DNS 100 authoritative server configurations that use certain non-standardized 101 DNS features. Some of these features like DNS based Global Server 102 Load Balancing (GSLB), dynamic failover pools, etc. rely on querier 103 specific responses, or responses based on real-time state 104 examination, and so, the answer and corresponding signature has to be 105 determined at the authoritative server being queried, at the time of 106 the query, or both. 108 2.2. Sign and Serve models 110 In this category of models, multiple providers each independently 111 sign and serve the same zone. The zone owner typically uses 112 provider-specific APIs to update zone content at each of the 113 providers, and relies on the provider to perform signing of the data. 114 The main challenge here is to manage the contents of the DNSKEY and 115 DS RRset in such a way that validating resolvers always have a viable 116 path to authenticate the DNSSEC signature chain no matter which 117 provider they query and obtain responses from. 119 These models can support DNSSEC even for the non-standard features 120 mentioned previously, if the DNS providers have the capability of 121 signing the response data generated by those features. Since these 122 responses are often generated dynamically at query time, one method 123 is for the provider to perform online signing (also known as on-the- 124 fly signing). However, another possible approach is to pre-compute 125 all the possible response sets and associated signatures and then 126 algorithmically determine at query time which response set needs to 127 be returned. 129 In these models, the function of coordinating the DNSKEY or DS RRset 130 does not involve the providers communicating directly with each 131 other, which they are unlikely to do since they typically have a 132 contractual relationship only with the customer. 134 The following descriptions consider the case of two DNS providers, 135 but the model is generalizable to any number. 137 2.2.1. Model 1 139 o Customer holds the KSK and manages the DS record. 141 o Each provider has their own ZSK which is used to sign data 143 o Providers have an API that customer uses to query the ZSK public 144 key, and insert a combined DNSKEY RRset that includes both ZSKs 145 and the KSK, signed by the KSK. 147 o Key rollovers need coordinated customer participation to update 148 and re-sign the DNSKEY RRset. 150 2.2.2. Model 2 152 o Each provider has their own KSK and ZSK. 154 o Each provider also includes the ZSK of the other provider - 155 delivered to them by the customer via some API mechanism 157 o DNSKEY RRset is signed independently by each provider using their 158 own KSK. 160 o Customer manages the DS record that includes both KSKs. 162 o KSK rollovers need coordinated customer participation to update 163 the DS. 165 2.2.3. Model 3 167 Possible models in which KSK and/or ZSK key pairs are shared across 168 providers are not currently discussed. Preliminary discussion with 169 some providers has revealed that this is not a mode all of them are 170 comfortable with, as they do not want to share signing keys with 171 other parties. 173 2.3. Inline Signing models 175 In this model, the zone owner runs a master server but does not 176 perform zone signing, instead pushing out the zone (typically via 177 zone transfer mechanisms) to multiple providers, and relying on those 178 providers to sign the zone data before serving them out. This model 179 has to address the same set of requirements as the Sign-and-Serve 180 model regarding managing the DNSKEY and DS RRsets. However, assuming 181 standardized zone transfers mechanisms are being used to push out the 182 zone to the providers, it likely also has the limitation that non- 183 standardized DNS features cannot be supported or signed. This model 184 is not discussed further. 186 3. Signing Algorithm Considerations 188 [TBD: at the very least we have to consider whether any or all of 189 these schemes require algorithms to be the same or not, or benefit 190 from algorithms being the same. Current DNS specifications indicate 191 that if there are multiple algorithms in the DNSKEY RRset, then data 192 records need to be signed with at least one of each algorithm, (how 193 does that work with online signing?). Multiple signatures per record 194 set is a cost that probably few operators want to bear.] 196 4. Validating Resolver Behavior 198 TBD 200 5. Key Rollover Considerations 202 TBD 204 6. IANA Considerations 206 This document includes no request to IANA. 208 7. Security Considerations 210 [TBD] 212 8. References 214 8.1. Normative References 216 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 217 Rose, "DNS Security Introduction and Requirements", RFC 218 4033, March 2005. 220 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 221 Rose, "Resource Records for the DNS Security Extensions", 222 RFC 4034, March 2005. 224 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 225 Rose, "Protocol Modifications for the DNS Security 226 Extensions", RFC 4035, March 2005. 228 8.2. Informative References 230 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 231 Text on Security Considerations", BCP 72, RFC 3552, July 232 2003. 234 Authors' Addresses 236 Shumon Huque 237 Salesforce 239 Email: shuque@gmail.com 240 Pallavi Aras 241 Salesforce 243 Email: paras@salesforce.com