idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 248: '... It is RECOMMENDED that the provider...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2019) is 1733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 23, 2020 J. Dickinson 6 Sinodun 7 J. Vcelak 8 NS1 9 D. Blacka 10 Verisign 11 July 22, 2019 13 Multi Signer DNSSEC models 14 draft-ietf-dnsop-multi-provider-dnssec-03 16 Abstract 18 Many enterprises today employ the service of multiple DNS providers 19 to distribute their authoritative DNS service. Deploying DNSSEC in 20 such an environment may present some challenges depending on the 21 configuration and feature set in use. This document will present 22 several deployment models that may be suitable. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 23, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 59 2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Multiple Signer models . . . . . . . . . . . . . . . . . 3 61 2.1.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4 62 2.1.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4 63 3. Validating Resolver Behavior . . . . . . . . . . . . . . . . 5 64 4. Signing Algorithm Considerations . . . . . . . . . . . . . . 6 65 5. Authenticated Denial Considerations . . . . . . . . . . . . . 6 66 5.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7 68 6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7 69 6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 8 70 6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 8 71 7. Using Combined Signing Keys . . . . . . . . . . . . . . . . . 9 72 8. Use of CDS and CDNSKEY . . . . . . . . . . . . . . . . . . . 10 73 9. Key Management Mechanism Requirements . . . . . . . . . . . . 10 74 10. DNS Response Size Considerations . . . . . . . . . . . . . . 11 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 14.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction and Motivation 85 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 86 The source for this draft is maintained in GitHub at: 87 https://github.com/shuque/multi-provider-dnssec 89 Many enterprises today employ the service of multiple DNS providers 90 to distribute their authoritative DNS service. This allows the DNS 91 service to survive a complete failure of any single provider. 92 Additionally, enterprises or providers occasionally have requirements 93 that preclude standard zone transfer techniques [RFC1995] [RFC5936] : 94 either non-standardized DNS features are in use that are incompatible 95 with zone transfer, or operationally a provider must be able to 96 (re)sign DNS records using their own keys. This document outlines 97 some possible models of DNSSEC [RFC4033] [RFC4034] [RFC4035] 98 deployment in such an environment. 100 2. Deployment Models 102 If a zone owner is able to use standard zone transfer techniques, 103 then the presence of multiple providers does not present any need to 104 substantially modify normal deployment models. In these deployments 105 there is a single signing entity (which may be the zone owner, one of 106 the providers, or a separate entity), while the providers act as 107 secondary authoritative servers for the zone. 109 Occasionally, however, standard zone transfer techniques cannot be 110 used. This could be due to the use of non-standard DNS features, or 111 due to operational requirements of a given provider (e.g., a provider 112 that only supports "online signing".) In these scenarios, the 113 multiple providers each act like primary servers, independently 114 signing data received from the zone owner and serving it to DNS 115 queriers. This configuration presents some novel challenges and 116 requirements. 118 2.1. Multiple Signer models 120 In this category of models, multiple providers each independently 121 sign and serve the same zone. The zone owner typically uses 122 provider-specific APIs to update zone content at each of the 123 providers, and relies on the provider to perform signing of the data. 124 A key requirement here is to manage the contents of the DNSKEY and DS 125 RRset in such a way that validating resolvers always have a viable 126 path to authenticate the DNSSEC signature chain no matter which 127 provider is queried. This requirement is achieved by having each 128 provider import the public Zone Signing Keys (ZSKs) of all other 129 providers into their DNSKEY RRsets. 131 These models can support DNSSEC even for the non-standard features 132 mentioned previously, if the DNS providers have the capability of 133 signing the response data generated by those features. Since these 134 responses are often generated dynamically at query time, one method 135 is for the provider to perform online signing (also known as on-the- 136 fly signing). However, another possible approach is to pre-compute 137 all the possible response sets and associated signatures and then 138 algorithmically determine at query time which response set needs to 139 be returned. 141 In the models presented, the function of coordinating the DNSKEY or 142 DS RRset does not involve the providers communicating directly with 143 each other. Feedback from several commercial managed DNS providers 144 indicates that they may be unlikely to directly communicate since 145 they typically have a contractual relationship only with the zone 146 owner. However, if the parties involved are agreeable, it may be 147 possible to devise a protocol mechanism by which the providers 148 directly communicate to share keys. 150 The following descriptions consider the case of two DNS providers, 151 but the model is generalizable to any number. 153 2.1.1. Model 1: Common KSK, Unique ZSK per provider 155 o Zone owner holds the KSK, manages the DS record, and is 156 responsible for signing the DNSKEY RRset and distributing the 157 signed DNSKEY RRset to the providers. 159 o Each provider has their own ZSK which is used to sign data. 161 o Providers have an API that owner uses to query the ZSK public key, 162 and insert a combined DNSKEY RRset that includes both ZSKs and the 163 KSK, signed by the KSK. 165 o Note that even if the contents of the DNSKEY RRset don't change, 166 the Zone owner of course needs to periodically re-sign it as 167 signature expiration approaches. The provider API is also used to 168 thus periodically redistribute the refreshed DNSKEY RRset. 170 o Key rollovers need coordinated participation of the zone owner to 171 update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for 172 KSK). 174 2.1.2. Model 2: Unique KSK and ZSK per provider 176 o Each provider has their own KSK and ZSK. 178 o Each provider offers an API that the Zone Owner uses to import the 179 ZSK of the other provider into their DNSKEY RRset. 181 o DNSKEY RRset is signed independently by each provider using their 182 own KSK. 184 o Zone Owner manages the DS RRset that includes both KSKs. 186 o Key rollovers need coordinated participation of the zone owner to 187 update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK). 189 3. Validating Resolver Behavior 191 The central requirement for both of the Multiple Signer models 192 (Section 2.1) is to ensure that the ZSKs from all providers are 193 present in each provider's apex DNSKEY RRset, and is vouched for by 194 either the single KSK (in model 1) or each provider's KSK (in model 195 2.) If this is not done, the following situation can arise (assuming 196 two providers A and B): 198 o The validating resolver follows a referral (delegation) to the 199 zone in question. 201 o It retrieves the zone's DNSKEY RRset from one of provider A's 202 nameservers. 204 o At some point in time, the resolver attempts to resolve a name in 205 the zone, while the DNSKEY RRset received from provider A is still 206 viable in its cache. 208 o It queries one of provider B's nameservers to resolve the name, 209 and obtains a response that is signed by provider B's ZSK, which 210 it cannot authenticate because this ZSK is not present in its 211 cached DNSKEY RRset for the zone that it received from provider A. 213 o The resolver will not accept this response. It may still be able 214 to ultimately authenticate the name by querying other nameservers 215 for the zone until it elicits a response from one of provider A's 216 nameservers. But it has incurred the penalty of additional 217 roundtrips with other nameservers, with the corresponding latency 218 and processing costs. The exact number of additional roundtrips 219 depends on details of the resolver's nameserver selection 220 algorithm and the number of nameservers configured at provider B. 222 o It may also be the case that a resolver is unable to provide an 223 authenticated response because it gave up after a certain number 224 of retries or a certain amount of delay. Or that downstream 225 clients of the resolver that originated the query timed out 226 waiting for a response. 228 Zone owners will want to deploy a DNS service that responds as 229 efficiently as possible with validatable answers only, and hence it 230 is important that the DNSKEY RRset at each provider is maintained 231 with the active ZSKs of all participating providers. This ensures 232 that resolvers can validate a response no matter which provider's 233 nameservers it came from. 235 Details of how the DNSKEY RRset itself is validated differs. In 236 model 1 (Section 2.1.1), one unique KSK managed by the Zone Owner 237 signs an identical DNSKEY RRset deployed at each provider, and the 238 signed DS record in the parent zone refers to this KSK. In model 2 239 (Section 2.1.2), each provider has a distinct KSK and signs the 240 DNSKEY RRset with it. The Zone Owner deploys a DS RRset at the 241 parent zone that contains multiple DS records, each referring to a 242 distinct provider's KSK. Hence it does not matter which provider's 243 nameservers the resolver obtains the DNSKEY RRset from, the signed DS 244 record in each model can authenticate the associated KSK. 246 4. Signing Algorithm Considerations 248 It is RECOMMENDED that the providers use a common signing algorithm 249 (and common keysizes for algorithms that support variable key sizes). 250 This ensures that the multiple providers have identical security 251 postures and no provider is more vulnerable to cryptanalytic attack 252 than the others. 254 It may however be possible to deploy a configuration where different 255 providers use different signing algorithms. The main impediment is 256 that current DNSSEC specifications require that if there are multiple 257 algorithms in the DNSKEY RRset, then RRsets in the zone need to be 258 signed with at least one DNSKEY of each algorithm, as described in 259 RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781], 260 Section 4.1.4, also describes both a conservative and liberal 261 interpretation of this requirement. When validating DNS resolvers 262 follow the liberal approach, they do not expect that zone RRsets are 263 signed by every signing algorithm in the DNSKEY RRset, and responses 264 with single algorithm signatures can be validated corectly assuming a 265 valid chain of trust exists. In fact, testing by the .BR Top Level 266 domain for their recent algorithm rollover [BR-ROLLOVER], 267 demonstrates that the liberal approach does in fact work with current 268 resolvers deployed on the Internet. 270 5. Authenticated Denial Considerations 272 Authentiated denial of existence enables a resolver to validate that 273 a record does not exist. For this purpose, an authoritative server 274 presents, in a response to the resolver, NSEC (Section 3.1.3 of 275 [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3 276 method enhances NSEC by providing opt-out for signing insecure 277 delegations and also adds limited protection against zone enumeration 278 attacks. 280 An authoritative server response carrying records for authenticated 281 denial is always self-contained and the receiving resolver doesn't 282 need to send additional queries to complete the denial proof data. 283 For this reason, no rollover is needed when switching between NSEC 284 and NSEC3 for a signed zone. 286 Since authenticated denial responses are self-contained, NSEC and 287 NSEC3 can be used by different providers to serve the same zone. 288 Doing so however defeats the protection against zone enumeration 289 provided by NSEC3. A better configuration involves multiple 290 providers using different authenticated denial of existence 291 mechanisms that all provide zone enumeration defense, such as pre- 292 computed NSEC3, NSEC3 White Lies [RFC7129], NSEC Black Lies 293 [BLACKLIES], etc. Note however that having multiple providers 294 offering different authenticated denial mechanisms may impact how 295 effectively resolvers are able to make use of the caching of negative 296 responses. 298 5.1. Single Method 300 Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the 301 methods are not used at the same time by different servers). This 302 configuration is prefered because the behavior is well-defined and 303 it's closest to the current operational practice. 305 5.2. Mixing Methods 307 Compliant resolvers should be able to validate zone data when 308 different authoritative servers for the same zone respond with 309 different authentiated denial methods because this is normally 310 observed when NSEC and NSEC3 are being switched or when NSEC3PARAM is 311 updated. 313 Resolver software may be however designed to handle a single 314 transition between two authenticated denial configurations more 315 optimally than permanent setup with mixed authenticated denial 316 methods. This could make caching on the resolver side less efficient 317 and the authoritative servers may observe higher number of queries. 318 This aspect should be considered especially in context of Aggresive 319 Use of DNSSEC-Validated Cache [RFC8198]. 321 In case all providers cannot be configured for a matching 322 authentiated denial, it is advised to find lowest number of possible 323 configurations possible across all used providers. 325 Note that NSEC3 configuration on all providers with different 326 NSEC3PARAM values is considered a mixed setup. 328 6. Key Rollover Considerations 330 The Multiple Signer (Section 2.1) models introduce some new 331 requirements for DNSSEC key rollovers. Since this process 332 necessarily involves coordinated actions on the part of providers and 333 the Zone Owner, one reasonable strategy is for the Zone Owner to 334 initiate key rollover operations. But other operationally plausible 335 models may also suit, such as a DNS provider initiating a key 336 rollover and signaling their intent to the Zone Owner in some manner. 338 The descriptions in this section assume that KSK rollovers employ the 339 commonly used Double Signature KSK Rollover Method, and that ZSK 340 rollovers employ the Pre-Publish ZSK Rollover Method, as described in 341 detail in [RFC6781]. With minor modifications, they can also be 342 easily adapted to other models, such as Double DS KSK Rollover or 343 Double Signature ZSK rollover, if desired. 345 6.1. Model 1: Common KSK, Unique ZSK per provider 347 o Key Signing Key Rollover: In this model, the two managed DNS 348 providers share a common KSK which is held by the Zone Owner. To 349 initiate the rollover, the Zone Owner generates a new KSK and 350 obtains the DNSKEY RRset of each DNS provider using their 351 respective APIs. The new KSK is added to each provider's DNSKEY 352 RRset and the RRset is re-signed with both the new and the old 353 KSK. This new DNSKEY RRset is then transferred to each provider. 354 The Zone Owner then updates the DS RRset in the parent zone to 355 point to the new KSK, and after the necessary DS record TTL period 356 has expired, proceeds with updating the DNSKEY RRSet to remove the 357 old KSK. 359 o Zone Signing Key Rollover: In this model, each DNS provider has 360 separate Zone Signing Keys. Each provider can choose to roll 361 their ZSK independently by co-ordinating with the Zone Owner. 362 Provider A would generate a new ZSK and communicate their intent 363 to perform a rollover (note that Provider A cannot immediately 364 insert this new ZSK into their DNSKEY RRset because the RRset has 365 to be signed by the Zone Owner). The Zone Owner obtains the new 366 ZSK from Provider A. It then obtains the current DNSKEY RRset 367 from each provider (including Provider A), inserts the new ZSK 368 into each DNSKEY RRset, re-signs the DNSKEY RRset, and sends it 369 back to each provider for deployment via their respective key 370 management APIs. Once the necessary time period is elapsed (i.e. 371 all zone data has been re-signed by the new ZSK and propagated to 372 all authoritative servers for the zone, plus the maximum zone TTL 373 value of any of the data in the zone signed by the old ZSK), 374 Provider A and the zone owner can initiate the next phase of 375 removing the old ZSK. 377 6.2. Model 2: Unique KSK and ZSK per provider 379 o Key Signing Key Rollover: In Model 2, each managed DNS provider 380 has their own KSK. A KSK roll for provider A does not require any 381 change in the DNSKEY RRset of provider B, but does require co- 382 ordination with the Zone Owner in order to get the DS record set 383 in the parent zone updated. The KSK roll starts with Provider A 384 generating a new KSK and including it in their DNSKEY RRSet. The 385 DNSKey RRset would then be signed by both the new and old KSK. 386 The new KSK is communicated to the Zone Owner, after which the 387 Zone Owner updates the DS RRset to replace the DS record for the 388 old KSK with a DS record for the new KSK. After the necessary DS 389 RRset TTL period has elapsed, the old KSK can be removed from 390 provider A's DNSKEY RRset. 392 o Zone Signing Key Rollover: In Model 2, each managed DNS provider 393 has their own ZSK. The ZSK roll for provider A would start with 394 them generating new ZSK and including it in their DNSKEY RRset and 395 re-signing the new DNSKEY RRset with their KSK. The new ZSK of 396 provider A would then be communicated to the Zone Owner, who will 397 initiate the process of importing this ZSK into the DNSKEY RRsets 398 of the other providers, using their respective APIs. Once the 399 necessary Pre-Publish key rollover time periods have elapsed, 400 provider A and the Zone Owner can initiate the process of removing 401 the old ZSK from the DNSKEY RRset of all providers. 403 7. Using Combined Signing Keys 405 A Combined Signing Key (CSK), is one in which the same key serves the 406 purpose of being both the secure entry point (SEP) key for the zone, 407 and also for signing all the zone data including the DNSKEY RRset 408 (i.e. there is no KSK/ZSK split). 410 Model 1 is not compatible with CSKs because the zone owner would then 411 hold the sole signing key, and providers would not be able to sign 412 their own zone data. 414 Model 2 can accommodate CSKs without issue. In this case, any or all 415 the providers could employ a CSK. The DS record in the parent zone 416 would reference the provider's CSK instead of KSK, and the public CSK 417 will need to be imported into the DNSKEY RRsets of all the other 418 providers. A CSK key rollover for such a provider would involve the 419 following: The provider generates a new CSK, installs the new CSK 420 into the DNSKEY RRset, and signs it with both the old and new CSK. 421 The new CSK is communicated to the Zone Owner. The Zone Owner 422 exports this CSK into the other provider's DNSKEY RRsets and replaces 423 the DS record referencing the old CSK with one referencing the new 424 one in the parent DS RRset. Once all the zone data has been re- 425 signed with the new CSK, the old CSK is removed from the DNSKEY 426 RRset, and the latter is re-signed with only the new CSK. Finally, 427 the old CSK is removed from the DNSKEY RRsets of the other providers. 429 8. Use of CDS and CDNSKEY 431 CDS and CDNSKEY records [RFC7344] [RFC8078] are used to facilitate 432 automated updates of DNSSEC secure entry point keys between parent 433 and child zones. Multi-signer DNSSEC configurations can support this 434 too. In Model 1, CDS/CDNSKEY changes are centralized at the zone 435 owner. However, the zone owner will still need to push down updated 436 signed CDNS/DNSKEY RRsets to the providers via the key management 437 mechanism. In Model 2, the key management mechanism needs to support 438 cross importation of the CDS/CDNSKEY records, so that a common view 439 of the RRset can be constructed at each provider, and is visible to 440 the parent zone attempting to update the DS RRset. 442 9. Key Management Mechanism Requirements 444 Managed DNS providers often have their own proprietary zone 445 configuration and data management APIs, typically utilizing HTTPS/ 446 REST interfaces. So, rather than outlining a new API for key 447 management here, we describe the specific functions that the provider 448 API needs to support in order to enable the multi-signer models. The 449 Zone owner is expected to use these API functions to perform key 450 management tasks. Other mechanisms that can offer these functions, 451 if supported by the providers, include the DNS UPDATE protocol 452 [RFC2136] and EPP [RFC5731]. 454 o The API must offer a way to query the current DNSKEY RRset of the 455 provider 457 o For model 1, the API must offer a way to import a signed DNSKEY 458 RRset and replace the current one at the provider. Additionally, 459 if CDS/CDNSKEY is supported, the API must also offer a way to 460 import a signed CDS/CDNSKEY RRset. 462 o For model 2, the API must offer a way to import a DNSKEY record 463 from an external provider into the current DNSKEY RRset. 464 Additionally, if CDS/CDNSKEY is supported, the API must offer a 465 mechanism to import individual CDS/CDNSKEY records from an 466 external provider. 468 In model 2, once initially bootstrapped with each others zone signing 469 keys via these API mechanisms, providers could, if desired, 470 periodically query each others DNSKEY RRsets and automatically import 471 or withdraw ZSKs in the keyset as key rollover events happen. 473 10. DNS Response Size Considerations 475 The Multi-Signer models described in this document result in larger 476 DNSKEY RRsets, so the DNSKEY response size will be larger. The 477 actual size depends on multiple factors: DNSKEY algorithm and keysize 478 choices, the number of providers, how many simultaneous key rollovers 479 are in progress etc. Newer elliptic curve algorithms produce keys 480 small enough that the responses will typically be far below the 481 common Internet path MTU, and thus operational issues related to IP 482 fragmentation or truncation and TCP fallback are unlikely to be 483 encountered. 485 11. IANA Considerations 487 This document includes no request to IANA. 489 12. Security Considerations 491 The Zone key import APIs required by these models need to be strongly 492 authenticated to prevent tampering of key material by malicious third 493 parties. Many providers today offer REST/HTTPS APIs that utilize a 494 number of authentication mechanisms (username/password, API keys 495 etc). If DNS protocol mechanisms like UPDATE are being used for key 496 insertion and deletion, they should similarly be strongly 497 authenticated, e.g. by employing Transaction Signatures (TSIG) 498 [RFC2845]. 500 13. Acknowledgments 502 The initial version of this document benefited from discussions with 503 and review from Duane Wessels. Additional helpful comments were 504 provided by Steve Crocker, Ulrich Wisser, Tony Finch, and Olafur 505 Gudmundsson. 507 14. References 509 14.1. Normative References 511 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 512 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 513 RFC 2136, DOI 10.17487/RFC2136, April 1997, 514 . 516 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 517 Wellington, "Secret Key Transaction Authentication for DNS 518 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 519 . 521 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 522 Rose, "DNS Security Introduction and Requirements", 523 RFC 4033, DOI 10.17487/RFC4033, March 2005, 524 . 526 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 527 Rose, "Resource Records for the DNS Security Extensions", 528 RFC 4034, DOI 10.17487/RFC4034, March 2005, 529 . 531 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 532 Rose, "Protocol Modifications for the DNS Security 533 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 534 . 536 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 537 Security (DNSSEC) Hashed Authenticated Denial of 538 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 539 . 541 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 542 Domain Name Mapping", STD 69, RFC 5731, 543 DOI 10.17487/RFC5731, August 2009, . 546 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 547 Operational Practices, Version 2", RFC 6781, 548 DOI 10.17487/RFC6781, December 2012, . 551 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 552 DNSSEC Delegation Trust Maintenance", RFC 7344, 553 DOI 10.17487/RFC7344, September 2014, . 556 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 557 the Parent via CDS/CDNSKEY", RFC 8078, 558 DOI 10.17487/RFC8078, March 2017, . 561 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 562 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 563 July 2017, . 565 14.2. Informative References 567 [BLACKLIES] 568 Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of 569 Existence or Black Lies", . 572 [BR-ROLLOVER] 573 Neves, F., ".br DNSSEC Algorithm Rollover Update", 574 in ICANN 62 DNSSEC Workshop, June 2018, 575 . 578 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 579 DOI 10.17487/RFC1995, August 1996, . 582 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 583 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 584 . 586 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 587 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 588 February 2014, . 590 Authors' Addresses 592 Shumon Huque 593 Salesforce 595 Email: shuque@gmail.com 597 Pallavi Aras 598 Salesforce 600 Email: paras@salesforce.com 602 John Dickinson 603 Sinodun 605 Email: jad@sinodun.com 606 Jan Vcelak 607 NS1 609 Email: jvcelak@ns1.com 611 David Blacka 612 Verisign 614 Email: davidb@verisign.com