idnits 2.17.1 draft-ietf-dnsop-dnssec-validator-requirements-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 == Line 185 has weird spacing: '...lidator the e...' == Line 188 has weird spacing: '...idation valid...' == Line 191 has weird spacing: '...a Store a mod...' == Line 276 has weird spacing: '... Engine follo...' == Line 307 has weird spacing: '...dations which...' == (4 more instances...) -- The document date (13 May 2022) is 711 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-ns-revalidation-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational D. York 5 Expires: 14 November 2022 ISOC 6 13 May 2022 8 Recommendations for DNSSEC Resolvers Operators 9 draft-ietf-dnsop-dnssec-validator-requirements-01 11 Abstract 13 The DNS Security Extensions (DNSSEC) define a process for validating 14 received data and assert them authentic and complete as opposed to 15 forged. 17 This document clarifies the scope and responsibilities of DNSSEC 18 Resolver Operators (DRO) as well as operational recommendations that 19 DNSSEC validators operators SHOULD put in place in order to implement 20 sufficient trust that makes DNSSEC validation output accurate. The 21 recommendations described in this document include, provisioning 22 mechanisms as well as monitoring and management mechanisms. 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 https://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 14 November 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. DNSSEC Validator Description . . . . . . . . . . . . . . . . 5 61 5. Recommendations Categories . . . . . . . . . . . . . . . . . 7 62 6. Time deviation and absence of Real Time Clock 63 Recommendations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Trust Anchor Related Recommendations . . . . . . . . . . . . 8 65 7.1. Trust Anchor Configuration . . . . . . . . . . . . . . . 9 66 7.1.1. Definition of the Trust model . . . . . . . . . . . . 10 67 7.1.2. Trust Model Bootstrapping . . . . . . . . . . . . . . 11 68 7.1.3. Configuration Generation . . . . . . . . . . . . . . 12 69 7.1.4. DNSSEC Resolver Instantiation . . . . . . . . . . . . 12 70 7.2. Trust Anchor Update . . . . . . . . . . . . . . . . . . . 12 71 7.2.1. Automated Updates to DNSSEC Trust Anchors . . . . . . 13 72 7.2.2. Automated Trust Anchor Check . . . . . . . . . . . . 13 73 8. Negative Trust Anchors Related Recommendations . . . . . . . 15 74 9. ZSK / KSK (non TA) Related Recommendations . . . . . . . . . 16 75 10. DNSKEY Related Recommendations . . . . . . . . . . . . . . . 18 76 10.1. Automated Reporting . . . . . . . . . . . . . . . . . . 18 77 10.2. Interactions with the cached RRsets . . . . . . . . . . 18 78 11. Cryptography Deprecation Recommendations . . . . . . . . . . 19 79 12. Invalid Reporting Recommendations . . . . . . . . . . . . . . 19 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 83 16. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 21 84 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 17.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 17.2. Informative References . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Requirements Notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 2. Introduction 99 The purpose of DNSSEC Resolver Operator (DRO) is to enable DNSSEC 100 validation in their resolvers. 102 By validating with DNSSEC a received Resource Record Set (RRset), the 103 resolver provides a high level of confidentiality that the 104 information carried by the RRset is effectively the one published by 105 the legitimate owner of the RRset. The act of DNSSEC validation 106 [RFC4033][RFC4035] can be broken into two part: A _Signature 107 Validation_ which binds the RRset to a private key as well as _Trust_ 108 in the owner of the private being the legitimate owner. 110 Signature Validation consists in checking the cryptographic signature 111 of a RRset and involves among other parameters a DNSKEY Resource 112 Record (RR) and RRSIG RR and the RRset itself. The signature 113 validation process results in designating the owner of RRset as the 114 owner of the corresponding private part of the public key contained 115 in the DNSKEY RR. Cryptography provides a high level of confidence 116 in the binding to the private key. In that sense, a rogue RRset 117 likely results from the private key being exposed or guessed - as 118 opposed to signature or key collisions for example. As such differ 119 the confidence into the Trust to designate which DNSKEY RR is 120 legitimate. 122 Trust implicitly assumes the private keys used to signed are not 123 shared and as such can be associated their respective owners. The 124 purpose of Trust is to put significant confidence into designating 125 the legitimate DNSKEY RR - which also characterizes the corresponding 126 private key. Such trust is provided by a Trust Anchor (TA), and the 127 chain of trust established between the TA and the DNSKEY RR. The 128 chain of trust is obtained by recursively validating the DNSKEY RRs. 130 As a result, such trust results from the trust placed in the TA as 131 well as the delegation mechanism provided by DNSSEC and the Signature 132 Validation. As TAs need to be managed over time, the trust also 133 concerns the management procedure of the TA. This is the main 134 concern of this document. 136 Data's authenticity and integrity is tied to the operator of the key 137 that generates the signature. It is conceivable that a validator 138 could "know" the keys of each data source, but this is not practical 139 at large scale. To counter this, DNSSEC relied on securely chaining 140 keys in a manner isomorphic to the way names are delegated. Keys for 141 a name will "vouch for" keys at a name delegated via the signing of a 142 DS resource record set. 144 Using keys to vouch for keys, recursively, works when a manageable 145 set of key to name associations are determined to be "trusted" - and 146 are called trust anchors. In DNSSEC, a validator needs one or more 147 Trust Anchors from which to grow chains of verified keys. 149 With operational experience, a twist has emerged. More often, to 150 date, failed validation is due to operator error or software bug 151 [ENT] and not an attempt to forge data. In general badly signed 152 RRsets or zone badly delegated are out of scope of the DRO's 153 responsibility. However, the DRO may reflect this operational error 154 with a temporary solution designated as Negative Trust Anchors (NTA) 155 [RFC7646]. A NTA instructs a validator to ignore the presence of 156 keys for a name, reacting as if the name is unsigned. 158 Once accurately validated the RRset is assumed to be accurately 159 validated and trusted during the time indicated by its TTL. 161 The responsibilities of a DRO are limited to the management of TAs as 162 well as providing the necessary infrastructure to perform the 163 signature validation, e.g. appropriated libraries and time. More 164 specifically, badly signed zones or insertion of malicious DNSKEY 165 fall out of the DRO's responsibilities. Even though these threats 166 fall out of these responsibilities, a DRO may collaborate with 167 authoritative servers to limit the damage of their operational 168 errors. 170 This document is focused on operational recommendations that DRO 171 SHOULD put in place in order to implement sufficient trust that makes 172 DNSSEC validation output accurate. The recommendations described in 173 this document include, provisioning mechanisms as well as monitoring 174 and management mechanisms. 176 The mechanisms provided are designed in accordance of the DNSSEC 177 trust model as to meet the current operations of DNSSEC. Such trust 178 model is briefly recapped in Section 4 so operators understand the 179 limits and motivations for such mechanisms. 181 3. Terminology 183 This document uses the following terminology: 185 DNSSEC validator the entity that performs DNSSEC resolution and 186 performs signature validation. 188 Accurate validation validation that avoids false positives and 189 catches true negatives. 191 Trust Anchor Data Store a module (of code) implementing functions 192 related to the trust anchors used by the validator. This is 193 essentially a database allowing access, monitoring of, and changes 194 to trust anchors. 196 DNSSEC Resolver Operator (DRO) The operator providing DNSSEC 197 validation service and managing DNSSEC validators 199 4. DNSSEC Validator Description 201 This is a conceptual block diagram of the elements involved with 202 DNSSEC validation. This is not meant to be an architecture for code, 203 this is meant to be a framework for discussion and explanation. 205 +-------------+ +---------------+ 206 | | | | 207 | Time Source | | Cryptographic | 208 | | | Libraries | 209 | | | | 210 +-------------+ +---------------+ 211 | | 212 v v 213 +--------------------------------+ +--------------+ 214 | | | | 215 | |<--| Trust Anchor | 216 | DNSSEC Validation Engine | | Manager & | 217 | |-->| Storage | 218 | | | | 219 +--------------------------------+ +--------------+ 220 ^ | ^ | 221 | v | | 222 +-------------+ +---------------+ | 223 | | | | | 224 | DNS Caches | | DNS Messages |<---------+ 225 | | | | 226 +-------------+ +---------------+ 228 { title="DNSSEC Validator Description" } 230 Time Source The wall clock time provides the DNSSEC Validation 231 Engine the current time. Time is among other used to validate the 232 RRSIG Signature and Inception Fields to provide some protection 233 against replay attacks. 235 Cryptograhic Libraries The code performing mathematical functions 236 provides the DNSSEC Validation Engine the ability to check the 237 Signature Field that contains the cryptographic signature covering 238 the RRSIG RDATA. 240 DNS Message DNS responses are used to carry the information from the 241 DNS system. The receiver of the DNS message can be any kind of 242 application including DNS-related application such as in the case 243 of automated Trust Anchor update performed by the Trust Anchor 244 Manager & Storage. The DNSSEC Validator Engine accurately 245 validates the DNS responses before caching them in the DNS Cache 246 and forwarding them to the DNS receiver. In case of validation 247 failure, an error is returned and the information may be 248 negatively cached. 250 DNS Caches Include positive and negative caches. The DNSSEC 251 Validation Engine fills DNS Caches with the results of a 252 validation (positive data, negative failures). The DNSSEC trust 253 model considers that once a RRset has been accurately validated by 254 the DNSSEC Validator Engine, the RRset is considered trusted (or 255 untrusted) for its associated TTL. DNS Caches contain RRsets that 256 may contain information requested by the application (RRset of 257 type AAAA for example) as well as RRset necessary to accurately 258 validate the RRsets (RRsets of type DNSKEY or RRSIG for example). 259 It also worth noticing that RRset validated with DNSSEC or RRset 260 that are not validated with DNSSEC fill the DNS Cache with the 261 same level of trust. 263 Trust Anchor Manager The database of trust anchors associated to 264 database management processes. This function provides the DNSSEC 265 Validation Engine Trust Anchor information when needed. When TA 266 needs to be updated, the Trust Anchor Manager is also responsible 267 to handle the updating procedure. This includes sending DNS 268 Messages as well as treating appropriately the DNS responses that 269 have been accurately validated by the DNSSEC Validator Engine. 271 This will require the DNSSEC Validator to update Trust Anchor 272 information, whether via methods like Automated Updates of DNSSEC 273 Trust Anchors [RFC5011], management of Negative Trust Anchors, or 274 other, possibly not yet defined, means. 276 DNSSEC Validation Engine follows local policy to approve data. The 277 approved data is returned to the requesting application as well as 278 in the DNS Caches. While the cryptographic computation of the 279 RRSIG signature may be the most visible step, the RRSIG record 280 also contains other information intended to help the validator 281 perform its work, in some cases "sane value" checks are performed. 282 For instance, the original TTL (needed to prepare the RR set for 283 validation) ought to be equal to or higher than the received TTL. 285 Not shown - Name Server Process Management interfaces to elements, 286 handling of Checking Disabled request, responses, as well as all API 287 requests made of the name server. 289 5. Recommendations Categories 291 DRO needs to be able to enable DNSSEC validation with sufficient 292 confidence they will not be held responsible in case their resolver 293 does not validate the DNSSEC response. The minimization of these 294 risks is provided by setting automated procedures, when a resolver is 295 started or while it is operating, as well as some on-demand 296 operations that enable the DRO to perform a specific operation. The 297 recommendations do not come with the same level of requirements and 298 some are likely to be required. Other are optional and may be 299 followed by more advanced DROs. 301 The recommendations are voluntary restrictive to prevent side effects 302 of interventions that will be hard to predict, debug and understand. 304 The RECOMMENDATIONS in this document are subdivided into the 305 following categories: 307 Start-up recommendations which describes RECOMMENDED operations the 308 DRO is expected to perform when the resolver is started. These 309 operations typically includes health check of the infrastructure 310 the resolver is instantiated on as well as configuration check. 312 Run time recommendations which describes RECOMMENDED operations the 313 DRO is expected to perform on its running resolvers. These 314 operations typically include health checks of the infrastructure 315 as well as the resolvers. 317 On demand recommendations which describes the RECOMMENDED operations 318 a DRO may perform. This includes the ability to operate health 319 check at a given time as well as specific operations such as 320 flushing the cache. The reason the document mentions these 321 recommendations is to enable DROs to have the appropriates tools 322 as well as to restrict their potential interventions. 324 6. Time deviation and absence of Real Time Clock Recommendations 326 With M2M communication some devices are not expected to embed Real 327 Time Clock (Raspberry Pi is one example of such devices). When these 328 devices are re-plugged the initial time is set to January 1 1970. 329 Other devices that have clocks that may suffer from time deviation. 330 These devices cannot rely on their time estimation to perform DNSSEC 331 validation. 333 Time synchronization may be performed manually, but for the sake of 334 operations it is strongly RECOMMENDED to automate the time 335 synchronization on each resolver. 337 START-UP REC: 339 * DRO MUST provide means to update the time without relying on 340 DNSSEC when the DNSSEC validator is started. The resolver MUST 341 NOT start if the time synchronization does not succeed at start 342 time. 344 Note that updating time in order to be able to perform DNSSEC 345 validation may become a form of a chicken-and-egg problem when the 346 NTP server is designated by its FQDN. The update mechanisms must 347 consider the DNSSEC validator may not able to validate the DNSSEC 348 queries. In other words, the mechanisms may have to update the time 349 over an unsecure DNSSEC resolution. 351 RUN TIME REC: 353 * While operating, DRO MUST closely monitor time derivations of the 354 resolvers and maintain the time synchronized. 356 ON DEMAND REC: 358 * A DRO SHOULD be able to check and synchronize, on demand, the time 359 of the system of its resolver. 361 Note that time synchronization is a sensible operation and DRO MUST 362 update the time of the systems over an authenticated and secure 363 channel. 365 For all recommendations, it is strongly RECOMMENDED that 366 recommendations are supported by automated processes. 368 7. Trust Anchor Related Recommendations 370 A TA store maintains associations between domain names and keys 371 (whether stored as in a DNSKEY resource record or a DS resource 372 record) and domain names whose key are to be ignored (negative trust 373 anchors). The TA store is essentially a database, storing the 374 (positive) trust anchors. Management of the TA can be done manually 375 or in an automated way. Automatic management of the TA is 376 RECOMMENDED and can be subdivided into the following sub-categories: 378 1. Initial TA provisioning that is the ability, for a DRO, to 379 ensure a starting resolver is automatically provisioned with 380 an up-to-date configuration. This includes the TA associated 381 to the trust model established by the DRO. 383 2. TA update over time while the trust model may not evolve, the 384 cryptographic keys associated to the security entry points are 385 subject to change and thus TA needs to be updated over time. 386 A DRO needs to check TA updates properly. 388 3. TA reporting The reporting of the TA used by the resolver is 389 made to the DRO as well as the authoritative servers which are 390 hold responsible for making their zone validated by DNSSEC 391 resolvers. 393 This section is only considering TA and not NTA. The handling of NTA 394 is detailed in Section 8. 396 7.1. Trust Anchor Configuration 398 When a DRO starts a DNSSEC resolver, the DNSSEC resolver is 399 provisioned with the TAs as part of its configuration. As these TAs 400 change over time, the DRO MUST ensures resolvers are always 401 provisioned with up-to-date TAs and detect deprecated configuration. 403 To do so, the TA configuration is considered as a trusted model 404 instantiated as follows: 406 1. Trust model definition :The DRO defines the domain names that 407 constitutes security entry point (TA) - see Section 7.1.1 for 408 more details. 410 2. Trust model bootstrapping A bootstrapping procedure is applied 411 to each TA to retrieve their TA values - that is the 412 corresponding value of the key - in a trusted way. Such TA 413 MAY have a specific format not understood by the resolver - 414 see Section 7.1.2 for more details. 416 3. DNSSEC resolver configuration generation The TA with associated 417 values are formatted appropriately for the DNSSEC resolver 418 that will be instantiated. In many cases the appropriated 419 format is the DNS RRset format - see Section 7.1.3 for more 420 details. 422 4. DNSSEC resolver instantiation The DNSSEC resolver is started, 423 performs some checks before becoming operational, that is 424 checking comp ability between provisioned TAs and those found 425 online. These checks are implemented by the resolver and not 426 really in scope of the DRO - see Section 7.1.4 for more 427 details. 429 While these steps may require some some specific development for 430 complex trust model, no additional deployment is required when using 431 the default model where the root zone is defined as the only secure 432 entry point. In such case, the trusted model bootstrapping is 433 performed by software-update that relies on the code signing key of 434 the software provider. The software provider also provides the 435 configuration to the appropriated format and the checks at 436 instantiation - see Section 7.1.2.1. 438 7.1.1. Definition of the Trust model 440 The DRO defines its trust model by explicitly mentioning the domain 441 name that constitutes security entry point as well as domain name 442 that are known to be unsecured. 444 This document does not provide recommendations regarding the number 445 of TA a DRO needs to configure its DNSSEC resolver with. There are 446 many reasons a DRO may be willing to consider multiple TAs as opposed 447 to a single Root Zone Trust Anchor. In fact it is not always 448 possible to build a trusted delegation between the Root Zone and any 449 sub zone. This may happen, for example, if one of the upper zones 450 does not handle the secure delegation or improperly implement it. 451 Typically, a DS RRset may not be properly filled or its associated 452 signature cannot be validated. As the chain of trust between a zone 453 and the root zone may not be validated, the DNSSEC validation for the 454 zone requires a TA. Such DNS(SEC) resolutions may be critical for 455 infrastructure management. A company "Example" may, for example, 456 address all its devices under the domain example.com and may not want 457 disruption to happen if the .com delegation cannot be validated for 458 any reasons. Such companies may operate DNSSEC with a TA for the 459 zone example.com in addition to the regular DNSSEC delegation. 460 Similarly some domains may present different views such as a 461 "private" view and a "public view". These zones may have some 462 different content, and may use a different KSK for each view. 464 The domain name chosen as security entry point may overlap themselves 465 such as example.com and .com for example. The TA associated to a 466 domain name is determined by the longest match. However, the trust 467 model MUST at least ensure that any domain name in the DNS be related 468 to a TA. As the number of top level domains is evolving overtime, it 469 remains safe to keep the root zone as a security entry point in order 470 to cover the full domain name space. 472 The default trust model consists in the root zone as a security entry 473 point, and no zones being considered as unsecured. 475 7.1.2. Trust Model Bootstrapping 477 The purpose of the boostrapping step is clearly to securely retrieve 478 DNSKEY as well as DS RRsets with a valid and authentic RDATA to 479 implement the trust model (see Section 7.1.1). Authentic data 480 includes data that are up-to-date at the time these are requested, 481 provided with securely and verified. In particular the TA MUST NOT 482 be retrieved from a local source that is not known to be up to date. 483 This typically includes software or any local store of data for which 484 there is not a dedicated and automated updating system. Similarly, 485 TA MUST NOT be retrieved from untrusted communication such as a DNS 486 resolution that cannot be verified or validated. 488 The authenticity of the RDATA is usually based on the authentication 489 of the source which can take multiple forms, but the principle is 490 that a chain of signature ends up being validated by a trusted key. 491 For TA that are not the root zone KSK, DNSSEC may be used to retrieve 492 and validate the TA. Note that such means to validate the 493 authenticity, the TA as a subdomain mostly prevents potential 494 disruptions of the parent domains. In many cases, an alternative 495 trusted source will be preferred such as TLS which is likely to rely 496 on the Web PKI, or the signature of a file. 498 Although some bootstrapping mechanisms to securely retrieve publish 499 [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor 500 have been defined, it is believed these mechanisms should be extended 501 to other KSKs or Trust Anchors. Such bootstrapping process enables a 502 DRO to start a DNSSEC resolver from a configuration file, that 503 reflects the trust model of the DRO. 505 START-UP REC: 507 * DRO SHOULD only rely on TA associated with a bootstrapping 508 mechanism. 510 7.1.2.1. IANA Trust Anchor Bootstrapping 512 For validators that may be used on the global public Internet (with 513 "may be" referring to general purpose, general release code), 514 handling the IANA managed root zone KSK trust anchor is a 515 consideration. 517 The IANA managed root zone KSK is an operationally significant trust 518 point in the global public Internet. Attention to the trust anchor 519 for this point is paramount. Trust anchor management ought to 520 recognize that the majority of operators deploying DNSSEC validators 521 will need to explicitly or implicitly rely on this trust anchor. 522 Trust anchor management needs to recognize that there may be other 523 trust anchors of interest to operators. Besides deployments in 524 networks other than the global public Internet (hence a different 525 root), operators may want to configure other trust points. 527 The IANA managed root zone KSK is managed and published as described 528 in "DNSSEC Trust Anchor Publication for the Root Zone" [RFC7598]. 529 That document is written as specific to that trust point. Other 530 trust points may adopt the technique describe (or may use other 531 approaches). 533 This represents a consideration for implementations. On one hand, 534 operators will place special emphasis on how the root zone DNSSEC KSK 535 is managed. On the other hand, implementations ought to accommodate 536 trust anchors in a general manner, despite the odds that other trust 537 anchors will not be configured in a specific deployment. 539 Because of this, it is recommended that implementations make the root 540 zone trust anchor obvious to the operator while still enabling 541 configuration of general trust points. 543 7.1.3. Configuration Generation 545 The generation of a configuration file associated to the TA is 546 expected to be implementation independent. The necessity of tweaking 547 the data depending of the software implementer or eventually the 548 software version introduces a vector for configuration errors. 550 7.1.4. DNSSEC Resolver Instantiation 552 START-UP REC: 554 * DNS resolver MUST validate the TA before starting the DNSSEC 555 resolver, and a failure of TA validity check MUST prevent the 556 DNSSEC resolver to be started. Validation of the TA includes 557 coherence between out-out band values, values stored in the DNS as 558 well as corresponding DS RRsets. 560 7.2. Trust Anchor Update 562 Updating the TA reflects the evolution of the trust. It is important 563 to understand that this section does not consider the trust model to 564 be updated by the DRO. This has been defined in section Section 7.1. 565 Instead, it considers the evolution over time of the instantiation of 566 the trust model, that is the update of the values associated to the 567 TA. Such updates need to be operated in a reliable and trusted way. 569 The value associated to the TA may be updated over time which is part 570 of the maintenance of the configuration and needs to be performed by 571 the DNSSEC resolver without any intervention of the DRO. This is the 572 purpose of this section. 574 TA update is expected to be transparent to the DRO (see 575 Section 7.2.1. However, a DRO MAY wish to ensure its resolvers 576 operate according to the provisioned configurations and are updated 577 normally (see Section 7.2.2. This includes for a DRO the ability to 578 check which TA are in used as well as to resolve in collaboration of 579 authoritative servers and report the used TAs. 581 7.2.1. Automated Updates to DNSSEC Trust Anchors 583 Trust is inherently a matter of an operations policy. As such, a DRO 584 will need to be able to update the list of Trust Anchors. TA updates 585 are not expected to be handled manually. This introduces a 586 potentially huge vector for configuration errors, due to human 587 intervention as well as potential misunderstanding of ongoing 588 operations. 590 START-UP REC: 592 * DRO SHOULD enable "Automated Updates to DNSSEC Trust Anchors" 593 [RFC5011] [I-D.ietf-dnsop-rfc5011-security-considerations]. 595 7.2.2. Automated Trust Anchor Check 597 A DRO SHOULD regularly check the trust anchor used by the DNSSEC 598 resolver is up-to-date and that values used by the resolvers are 599 conform to the ones in the configuration (see Section 7.1). Such 600 check is designated as TA health check. 602 Note that retrieving in an automated way the value of the TA removes 603 old values from the configuration and ensures that resolvers are 604 always started with up-to-date values. In the case of a key roll 605 over, the resolver is moving from an old value to an up-to date 606 value. This up-to-date value does not need to survive reboot, and 607 there is no need to update the configuration file of the running 608 instances - configuration is updated by a separate process. To put 609 it in other words, the updated value of the TA is only expected to be 610 stored in the resolver's memory. Avoiding the configuration file to 611 be updated prevents old configuration file to survive to writing 612 error on read-only file systems. 614 The TA used by a resolver may be part of a configuration parameter as 615 well as part of an internal state of the resolver. It is NOT 616 RECOMMENDED a DRO accesses configuration or internal state of a 617 resolver as it may open the resolver to other vulnerabilities and 618 provides privileged access to a potential attacker. 620 START-UP REC: 622 * DRO SHOULD enable "Signaling Trust Anchor Knowledge in DNS 623 Security Extensions (DNSSEC)" [RFC8145] to provide visibility to 624 the TA used by the resolver. The TA can be queried using a DNSKEY 625 query. The channel MAY be protected and restricted to the DRO. 627 Note also that [RFC8145] does not only concern Trust Anchor but is 628 instead generic to DNSKEY RRsets. As a result, unless for the root 629 zone, it is not possible to determine if the KSK/ZSK or DS is a Trust 630 Anchor or a KSK/ZSK obtained from regular DNSSEC resolutions. 632 TA health check includes validating DNSKEY RRsets and associated DS 633 RRsets in the resolver, on the DNS authoritative servers as well as 634 those obtained out-of-band. TA health check results MUST be logged. 635 The check SHOULD evaluate if the mismatch resulted from an ongoing 636 normal roll over, a potential emergency key roll over, failed roll 637 over or any other envisioned cases. Conflicts are not inherently a 638 problem as some keys may be withheld from distribution via the DNS. 639 A failed key roll over or any other abnormal situation MUST trigger 640 an alarm. 642 RUN TIME REC: 644 * A DRO SHOULD regularly run TA health checks. 646 If the mismatch is due to a failed key roll-over, this SHOULD be 647 considered as a bug by the DRO. The DRO MUST restart the resolver 648 with updated TA. 650 ON DEMAND REC: 652 * A DRO SHOULD be able to check the status of a TA as defined in 653 Section 3 of [RFC7583]. 655 8. Negative Trust Anchors Related Recommendations 657 When the DNSSEC Resolver is not able to validate signatures because a 658 key or DS has been published with an error, the DNSSEC Operator MAY 659 temporarily disable the signature check for that key until the time 660 the error is addressed. This is performed using NTA[RFC7646]. NTA 661 represents the only permitted intervention in the resolving process 662 for a DRO. 664 NTA are considered as temporary fix for a known unsecured domain, 665 which is different from an TA that would not be trusted. The 666 designation of NTA might be misleading, but NTA are not expected to 667 be part of the trust model. This does not prevent a DRO to provision 668 NTA as a configuration parameters NTA. The management of the 669 configuration SHOULD be automated as described in Section 7.1. 671 Handling NTA is described in [RFC7646] and a DRO SHOULD follow these 672 guidelines. The intent of this section is to position these 673 guidelines toward the operational recommendations provided in this 674 document. 676 START-UP REC: 678 * DRO SHOULD be able to automatically configure NTA when starting 679 DNSSEC resolvers. 681 ON DEMAND REC: 683 * DRO SHOULD set automated procedures to determine the NTA of DNSSEC 684 resolvers. 686 * DRO SHOULD be able to handle NTA as defined in [RFC7646]. 688 Note that adding a Negative Trust Anchor only requires the domain 689 name to be specified. Note also that NTA can disable any sort of 690 DNSKEY and is not restricted to TA. 692 A failure in signaling validation is associated to a mismatch between 693 the key and the signature. DNSKEY/DS RRsets for TA have a higher 694 level of trust then regular KSK/ZSK. In addition, DRO are likely to 695 have specific communication channel with TA maintainer which eases 696 trouble shooting. 698 A signature validation failure is either an attack or a failure in 699 the signing operation on the authoritative servers. The DRO is 700 expected to confirm this off line before introducing the NTA. This 701 is likely to happen via a human confirmation. As a result here are 702 the following recommendations: 704 RUN TIME REC: 706 * DRO SHOULD monitor the number of signature failure associated to 707 each DNSKEY. These number are only hints and MUST NOT trigger 708 automated insertion of NTA. 710 * A DRO MAY collect additional information associated each DNSKEY 711 RRSets. This information may be useful to follow-up roll over 712 when these happen and evaluate when a key roll over is not 713 performed appropriately on the resolver side or on the 714 authoritative server. It would provide some means to the DRO to 715 take action with full knowledge without necessary asking for a 716 confirmation. In other cases it could prevent invalidation to 717 happen. These check may be performed for a limited subset of 718 domains or generalized. 720 9. ZSK / KSK (non TA) Related Recommendations 722 KSK / ZSK are not part of the DNSSEC validator configuration. Their 723 values in the DNS Caches may not reflect those published by the 724 authoritative servers or may be incoherent with the RRset in the DNS 725 Cache they are validating. However, such incoherence primary results 726 from error in the management of the authoritative servers. As a 727 result, it is not expected that the DNSSEC validator provides complex 728 management facilities to address these issues as this will modify the 729 DNS architecture and add complexity that is not proved to be 730 beneficial. As a result, recommendations always belong to the run 731 time or on demand recommendations. The main difference between TA 732 and KSK/ZSK is that the DRO does not necessarily have an out of band 733 mechanism to retrieve the RRsets. As a result, the DRO has less 734 information to determine and confirm what is happening. The default 735 recommendation is to let things go. 737 A number of reasons may result in inconsistencies between the RRsets 738 stored in the cache and those published by the authoritative server. 740 An emergency KSK / ZSK rollover may result in a new KSK / ZSK with 741 associated new RRSIG published in the authoritative zone, while 742 DNSSEC validator may still cache the old value of the ZSK / KSK. For 743 a RRset not cached, the DNSSEC validator performs a DNSSEC query to 744 the authoritative server that returns the RRset signed with the new 745 KSK / ZSK. The DNSSEC validator may not be able to retrieve the new 746 KSK / ZSK while being unable to validate the signature with the old 747 KSK / ZSK. This either results in a bogus resolution or in an 748 invalid signature check. Note that by comparing the Key Tag Fields, 749 the DNSSEC validator is able to notice the new KSK / ZSK used for 750 signing differs from the one used to generate the received generated 751 signature. However, the DNSSEC validator is not expected to retrieve 752 the new ZSK / KSK, as such behavior could be used by an attacker. 753 Instead, ZSK / KSK key roll over procedures are expected to avoid 754 such inconsistencies. 756 Similarly, a KSK / ZSK roll over may be performed normally, that is 757 as described in [RFC6781] and [RFC7583]. While the KSK / ZSK roll 758 over is performed, there is no obligation to flush the RRsets in the 759 cache that have been associated with the old key. In fact, these 760 RRsets may still be considered as trusted and be removed from the 761 cache as their TTL timeout. With very long TTL, these RRsets may 762 remain in the cache while the ZSK / KSK with a shorter TTL is no 763 longer published nor in the cache. In such situations, the purpose 764 of the KSK / ZSK used to validate the data is considered trusted at 765 the time it enters the cache, and such trust may remain after the KSK 766 / ZSK is being rolled over. Note also that even though the data may 767 not be associated to the KSK / ZSK that has been used to validate the 768 data, the link between the KSK / ZSK and the data is still stored in 769 the cache using the RRSIG. Note also that inconsistencies between 770 the ZSK / KSK stored in the cache and those published on the 771 authoritative server, may lead to inconsistencies to downstream 772 DNSSEC validators that rely on multiple cache over time. 774 Typically, a request for the KSK / ZSK may have been provided by a 775 cache that is storing the new published value, while the data and 776 associated signatures may be associated to the old KSK / ZSK. 778 Incoherence between RRsets and DNSKEYs is not the responsibility of 779 the DRO. Instead, it is the responsibility of authoritative server 780 publishing these data. This includes insuring the coherence between 781 TTLs and signature validation periods as well as small variations of 782 the resolvers clocks. Section 4.4.1 of [RFC6781] provides some 783 recommendations that can be implemented by the authoritative server 784 which puts the responsibility of failure of signature validation 785 under the responsibility of the authoritative server. A DRO MAY 786 however limit the risks for these inconsistencies to happen by 787 configuring the DNSSEC validator with generic rules that applies to 788 the validation process. Typically, the TTL associate to the DNSKEY 789 is an engagement from the authoritative server that the DNSKEY will 790 remain valid over this period. As this engagement supersedes the 791 validation of any RRSIG and by extension to any RRset in the zone, 792 this TTL value may be used as the maximum value for the TTL 793 associated to FQDNs in the zone. Section 8.1 of [RFC4033] mention 794 the ability by the resolver to set the upper bound of the TTL to the 795 remaining signature validity period. This would at least reduce 796 inconsistencies during regular KSK roll over. In addition, the 797 DNSSEC validator should also be able to provide a maximum values for 798 TTLs. These values MAY also consider the small inaccuracy of the 799 local clock. 801 RUN TIME REC: 803 * To limit the risks of incoherent data in the cache, it is 804 RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of 805 the DS, KSK and ZSK. RRsets TTL SHOULD NOT exceed the DS, KSK or 806 ZSK initial TTL value, that TTL SHOULD trigger delegation 807 revalidation as described in [I-D.ietf-dnsop-ns-revalidation]. 808 TTL SHOULD NOT exceed the signature validity. 810 10. DNSKEY Related Recommendations 812 This section considers the recommendations that are common to TA as 813 well as non TA DNSKEY RRsets. 815 10.1. Automated Reporting 817 A DRO MAY regularly report the Trust Anchor used to the authoritative 818 server. This would at least provide insight to the authoritative 819 server and provide some context before moving a key roll over 820 further. 822 The purpose of reporting the currently used Trust Anchor for a domain 823 name is to establish an informational channel between the resolver 824 and the authoritative server. This data may not directly be useful 825 for the DNSSEC Resolver, but instead to the authoritative server. In 826 return it is likely the authoritative server will take the 827 appropriate steps in operating the authoritative server and consider 828 this information. This results in the following recommendation: 830 RUNNING REC: 832 * A DRO SHOULD enable TA reporting to the authoritative server as 833 specified in "Signaling Trust Anchor Knowledge in DNS Security 834 Extensions (DNSSEC)" [RFC8145] 836 10.2. Interactions with the cached RRsets 838 The purpose of automated checks is to enable early detection of 839 failed operations, which provides enough time to the DRO to react 840 without any consequences. On the other hand, these checks MAY reveal 841 as well that a rogue TA has been placed and that the resolver is 842 corrupted. Similarly, a DRO may be informed by other channel a rogue 843 or unwilling DNSKEY has been emitted. 845 In such situation, the DRO SHOULD be able to remove the RRsets 846 validated by the rogue DNSKEY. 848 ON DEMAND REC: 850 * A DRO MUST be able to flush the cached data associated to a DNSKEY 852 11. Cryptography Deprecation Recommendations 854 As mentioned in [RFC8247] and [RFC8221] cryptography used one day is 855 expected over the time to be replaced by new and more robust 856 cryptographic mechanisms. In the case of DNSSEC signature protocols 857 are likely to be updated over time. In order to anticipate the 858 sunset of one of the signature scheme, a DNSSEC validator may be 859 willing to estimate the impact of deprecating one signature scheme. 861 Currently [RFC6975] provides the ability for a DNSSEC validator to 862 announce an authoritative server the supported signature schemes. 863 However, a DNSSEC validator is not able to determine other than by 864 requesting and monitoring DNSKEY RRsets as well as RRSIG. These 865 RRsets are received by enabling DNSSEC validation by default which is 866 obviously the case for DNSSEC validator. 868 To safely deprecate one signature scheme, the DNSSEC validator 869 operator is expected to follow the recommendation below: 871 RUN TIME REC: 873 * A DRO SHOULD regularly request and monitor the signature scheme 874 supported by an authoritative server. 876 * A DRO SHOULD report a "Unsupported DNSKEY Algorithm" as defined in 877 [RFC8914] when a deprecated algorithm is used for validation. 879 12. Invalid Reporting Recommendations 881 A DNSSEC validator receiving a DNS response cannot make the 882 difference between receiving an non-secure response versus an attack. 883 Dropping DNSSEC fields by a misconfigured middle boxes, such as DS, 884 RRRSIG is considered as an attack. A DNSSEC validator is expected to 885 perform secure DNS resolution and as such protects its stub client. 886 An invalid response may be the result of an attack or a 887 misconfiguration, and the DNSSEC validator may play an important role 888 in sharing this information with the authoritative server or domain 889 name owner. 891 RUN TIME REC: 893 * DRO SHOULD monitor and report DNSSEC validation error. Reporting 894 may take various means but the DRO SHOULD implement [RFC8914] to 895 inform the DNS client. 897 13. IANA Considerations 899 There are no IANA consideration for this document. 901 14. Security Considerations 903 The recommendations listed in this document have two goals. First 904 ensuring the DNSSEC validator has appropriated information to 905 appropriately perform DNSSEC validation. Second, monitoring the 906 necessary elements that would enable a DNSSEC validator operator to 907 ease a potential analysis. The recommendations provide very limited 908 ability for a DNSSEC validator operator to alter or directly 909 interfere on the validation process and the main purpose in providing 910 the recommendations was to let the protocol run as much as possible. 911 Providing inappropriate information can lead to misconfiguring the 912 DNSSEC validator, and thus disrupting the DNSSEC resolution service. 913 As a result, enabling the setting of configuration parameters by a 914 third party may open a wide surface of attacks. In addition, such 915 changes may lead to unexpected corner cases that would result in 916 making analysis and trouble shooting very hard. 918 As an appropriate time value is necessary to perform signature check, 919 an attacker may provide rogue time value to prevent the DNSSEC 920 validator to check signatures. 922 An attacker may also affect the resolution service by regularly 923 asking the DNSSEC validator to flush the KSK/ZSK from its cache. All 924 associated data will also be flushed. This generates additional 925 DNSSEC resolution and additional validations, as RRSet that were 926 cached require a DNSSEC resolution over the Internet. This affects 927 the resolution service by slowing down responses, and increases the 928 load on the DNSSEC validator. 930 An attacker may ask the DNSSEC validator to consider a rogue KSK/ZSK, 931 thus hijacking the DNS zone. Similarly, an attacker may inform the 932 DNSSEC validator not to trust a given KSK in order to prevent DNSSEC 933 validation to be performed. 935 An attacker (cf. Section 7) can advertise a "known insecure" KSK or 936 ZSK is "back to secure" to prevent signature check to be performed 937 correctly. 939 As a result, information considered by the DNSSEC validator should be 940 from a trusted party. This trust party should have been 941 authenticated, and the channel used to exchange the information 942 should also be protected and authenticated. 944 The software used for DNSSEC validator is not immune to bugs and may 945 become vulnerable independently of how it is operated. As a result a 946 DRO SHOULD NOT depend on a single implementation or version of a 947 given software and SHOULD instead run at least two independent pieces 948 of software. 950 15. Contributors 952 We would like to thank very much Edward Lewis without who the 953 document might probably not exist. 955 16. Acknowledgment 957 The need to address DNSSEC issues on the resolver occured during 958 multiple discussions including among others Ted Lemon, Ralph Weber, 959 Normen Kowalewski, Mikael Abrahamsson, Jim Gettys, Paul Wouters, Joe 960 Abley and Michael Richardson. 962 17. References 964 17.1. Normative References 966 [I-D.ietf-dnsop-ns-revalidation] 967 Huque, S., Vixie, P., and R. Dolmans, "Delegation 968 Revalidation by DNS Resolvers", Work in Progress, 969 Internet-Draft, draft-ietf-dnsop-ns-revalidation-02, 7 970 March 2022, . 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, 975 DOI 10.17487/RFC2119, March 1997, 976 . 978 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 979 Rose, "DNS Security Introduction and Requirements", 980 RFC 4033, DOI 10.17487/RFC4033, March 2005, 981 . 983 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 984 Rose, "Protocol Modifications for the DNS Security 985 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 986 . 988 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 989 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 990 September 2007, . 992 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 993 Operational Practices, Version 2", RFC 6781, 994 DOI 10.17487/RFC6781, December 2012, 995 . 997 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 998 Algorithm Understanding in DNS Security Extensions 999 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 1000 . 1002 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 1003 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 1004 DOI 10.17487/RFC7583, October 2015, 1005 . 1007 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 1008 and R. Weber, "Definition and Use of DNSSEC Negative Trust 1009 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 1010 . 1012 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 1013 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 1014 RFC 8145, DOI 10.17487/RFC8145, April 2017, 1015 . 1017 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1018 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1019 May 2017, . 1021 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 1022 Kivinen, "Cryptographic Algorithm Implementation 1023 Requirements and Usage Guidance for Encapsulating Security 1024 Payload (ESP) and Authentication Header (AH)", RFC 8221, 1025 DOI 10.17487/RFC8221, October 2017, 1026 . 1028 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 1029 "Algorithm Implementation Requirements and Usage Guidance 1030 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 1031 RFC 8247, DOI 10.17487/RFC8247, September 2017, 1032 . 1034 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1035 Lawrence, "Extended DNS Errors", RFC 8914, 1036 DOI 10.17487/RFC8914, October 2020, 1037 . 1039 17.2. Informative References 1041 [ENT] Levigneron, V., "ENT was here !!!", n.d., 1042 . 1046 [I-D.ietf-dnsop-rfc5011-security-considerations] 1047 Hardaker, W. and W. Kumari, "Security Considerations for 1048 RFC5011 Publishers", Work in Progress, Internet-Draft, 1049 draft-ietf-dnsop-rfc5011-security-considerations-13, 16 1050 July 2018, . 1053 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 1054 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 1055 Configuration of Softwire Address and Port-Mapped 1056 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 1057 . 1059 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 1060 "DNSSEC Trust Anchor Publication for the Root Zone", 1061 RFC 7958, DOI 10.17487/RFC7958, August 2016, 1062 . 1064 [UNBOUND-ANCHOR] 1065 "unbound-anchor - Unbound anchor utility", n.d., 1066 . 1069 Authors' Addresses 1071 Daniel Migault 1072 Ericsson 1073 8275 Trans Canada Route 1074 Saint Laurent, QC 4S 0B6 1075 Canada 1076 Email: daniel.migault@ericsson.com 1078 Dan York 1079 ISOC 1080 Email: york@isoc.org