idnits 2.17.1 draft-ietf-dnsop-kskroll-sentinel-08.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 24, 2018) is 2225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP G. Huston 3 Internet-Draft J. Damas 4 Intended status: Standards Track APNIC 5 Expires: September 25, 2018 W. Kumari 6 Google 7 March 24, 2018 9 A Root Key Trust Anchor Sentinel for DNSSEC 10 draft-ietf-dnsop-kskroll-sentinel-08 12 Abstract 14 The DNS Security Extensions (DNSSEC) were developed to provide origin 15 authentication and integrity protection for DNS data by using digital 16 signatures. These digital signatures can be verified by building a 17 chain of trust starting from a trust anchor and proceeding down to a 18 particular node in the DNS. This document specifies a mechanism that 19 will allow an end user and third parties to determine the trusted key 20 state for the root key of the resolvers that handle that user's DNS 21 queries. Note that this method is only applicable for determing 22 which keys are in the trust store for the root key. 24 There is an example / toy implementation of this at http://www.ksk- 25 test.net . 27 [ This document is being collaborated on in Github at: 28 https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most 29 recent version of the document, open issues, etc should all be 30 available here. The authors (gratefully) accept pull requests. Text 31 in square brackets will be removed before publication. ] 33 [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-", "kskroll-sentinel-not-ta-"; older versions of this 35 document used "_is-ta-", "_not-ta-". Also note 36 that the format of the tag-index is now zero-filled decimal. 37 Apolgies to those who have began implmenting.] 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 25, 2018. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Protocol Walkthrough Example . . . . . . . . . . . . . . . . 4 76 3. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 7 77 3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7 78 3.2. Special processing . . . . . . . . . . . . . . . . . . . 8 79 4. Processing Sentinel Results . . . . . . . . . . . . . . . . . 8 80 5. Sentinel Test Result Considerations . . . . . . . . . . . . . 10 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 11.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 94 [RFC4035] were developed to provide origin authentication and 95 integrity protection for DNS data by using digital signatures. 96 DNSSEC uses Key Tags to efficiently match signatures to the keys from 97 which they are generated. The Key Tag is a 16-bit value computed 98 from the RDATA portion of a DNSKEY RR using a formula similar to a 99 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 100 value is equal to the Key Tag of the DNSKEY RR that validates the 101 signature. 103 This document specifies how validating resolvers can respond to 104 certain queries in a manner that allows a querier to deduce whether a 105 particular key for the root has been loaded into that resolver's 106 trusted key store. In particular, this response mechanism can be 107 used to determine whether a certain root zone KSK is ready to be used 108 as a trusted key within the context of a key roll by this resolver. 110 There are two primary use cases for this mechanism: 112 o Users want to know whether the resolvers they use are ready for an 113 upcoming root KSK rollover 115 o Researchers want to perform Internet-wide studies about the 116 percentage of users who will be ready for an upcoming root KSK 117 rollover 119 The mechanism described in this document meets both of these use 120 cases. This new mechanism is OPTIONAL to implement and use, although 121 for reasons of supporting broad-based measurement techniques, it is 122 strongly preferred that configurations of DNSSEC-validating resolvers 123 enabled this mechanism by default, allowing for local configuration 124 directives to disable this mechanism if desired. 126 The sentinel test described in this document determines whether a 127 user's browser or operating system looking up the special names that 128 are used in this protocol would be able to validate using the root 129 KSK indicated by the special names. The protocol uses the DNS 130 SERVFAIL response code (RCODE 2) for this purpose because that is the 131 response code that is returned by resolvers when DNSSEC validation 132 fails. If a browser or operating system has multiple resolvers 133 configured, and those resolvers have different properties (for 134 example, one performs DNSSEC validation and one does not), the 135 sentinel mechanism might search among the different resolvers, or 136 might not, depending on how the browser or operating system is 137 configured. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. 145 2. Protocol Walkthrough Example 147 [Ed note: This is currently towards the front of the document; we 148 will make it an appendix at publication time, but until then it is 149 worth having up front, as it makes the rest of the document much 150 easier to understand ] 152 This section provides a non-normative example of how the sentinel 153 mechanism could be used, and what each participant does. It is 154 provided in a conversational tone to be easier to follow. 156 Alice is in charge of the DNS root KSK (Key Signing Key), and would 157 like to roll / replace the key with a new one. She publishes the new 158 KSK, but would like to be able to predict / measure what the impact 159 will be before removing/revoking the old key. The current KSK has a 160 Key Tag of 11112, the new KSK has a Key Tag of 02323. Users want to 161 verify that their resolver will not break after Alice rolls the root 162 KSK key (that is, starts signing with just the KSK whose Key Tag is 163 02323). 165 Bob, Charlie, Dave, Ed are all users. They use the DNS recursive 166 resolvers supplied by their ISPs. They would like to confirm that 167 their ISPs have picked up the new KSK. Bob's ISP does not perform 168 validation. Charlie's ISP does validate, but the resolvers have not 169 yet been upgraded to support this mechanism. Dave and Ed's resolvers 170 have been upgraded to support this mechanism; Dave's resolver has the 171 new KSK, Ed's resolver hasn't managed to install the 02323 KSK in its 172 trust store yet. 174 Geoff is a researcher, and would like to both provide a means for 175 Bob, Charlie, Dave and Ed to be able to perform tests, and also would 176 like to be able to perform Internet-wide measurements of what the 177 impact will be (and report this back to Alice). 179 Geoff sets an authoritative DNS server for example.com, and also a 180 webserver (www.example.com). He adds three address records to 181 example.com: 183 invalid.example.com. IN AAAA 2001:db8::1 185 root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1 187 root-key-sentinel-not-ta-02323.example.com. IN AAAA 2001:db8::1 189 Note that the use of "example.com" names and the addresses here are 190 examples. In a real deployment, the domain names need to be under 191 control of the researcher, and the addresses must be real, reachable 192 addresses. 194 Geoff then DNSSEC signs the example.com zone, and intentionally makes 195 the invalid.example.com record invalid/bogus (for example, by editing 196 the signed zone and entering garbage for the signature). Geoff also 197 configures his webserver to listen on 2001:db8::1 and serve a 198 resource (for example, a 1x1 GIF, 1x1.gif) for all of these names. 199 The webserver also serves a webpage (www.example.com) which contains 200 links to these 3 resources (http://invalid.example.com/1x1.gif, 201 http://root-key-sentinel-is-ta-02323.example.com/1x1.gif, 202 http://root-key-sentinel-not-ta-02323.example.com/1x1.gif). 204 Geoff then asks Bob, Charlie, Dave and Ed to browse to 205 www.example.com. Using the methods described in this document, the 206 users can figure out what their fate will be when the 11112 KSK is 207 removed. 209 Bob is not using a validating resolver. This means that he will be 210 able to resolve invalid.example.com (and fetch the 1x1 GIF) - this 211 tells him that the KSK roll does not affect him, and so he will be 212 OK. 214 Charlie's resolvers are validating, but they have not been upgraded 215 to support the KSK sentinel mechanism. Charlie will not be able to 216 fetch the http://invalid.example.com/1x1.gif resource (the 217 invalid.example.com record is bogus, and none of his resolvers will 218 resolve it). He is able to fetch both of the other resources - from 219 this he knows (see the logic below) that he is using legacy, 220 validating resolvers. The KSK sentinel method cannot provided him 221 with a definitive answer to the question of what root trust anchors 222 this resolver is using. 224 Dave's resolvers implement the sentinel method, and have picked up 225 the new KSK. For the same reason as Charlie, he cannot fetch the 226 "invalid" resource. His resolver resolves the root-key-sentinel-is- 227 ta-02323.example.com name normally (it contacts the example.com 228 authoritative servers, etc); as it supports the sentinel mechanism, 229 just before Dave's recursive server send the reply to Dave's stub, it 230 performs the KSK Sentinel check (see below). The QNAME starts with 231 "root-key-sentinel-is-ta-", and the recursive resolver does indeed 232 have a key with the Key Tag of 02323 in its root trust store. This 233 means that that this part of the KSK Sentinel check passes (it is 234 true that Key Tag 02323 is in the trust anchor store), and the 235 recursive resolver replies normally (with the answer provided by the 236 authoritative server). Dave's recursive resolver then resolves the 237 root-key-sentinel-not-ta-02323.example.com name. Once again, it 238 performs the normal resolution process, but because it implements KSK 239 Sentinel (and the QNAME starts with "root-key-sentinel-not-ta-"), 240 just before sending the reply, it performs the KSK Sentinel check. 241 As it has 02323 in it's trust anchor store, the answer to "is this 242 *not* a trust anchor" is false, and so the recursive resolver does 243 not reply with the answer from the authoritative server - instead, it 244 replies with a SERVFAIL (note that replying with SERVFAIL instead of 245 the original answer is the only mechanism that KSK Sentinel uses). 246 This means that Dave cannot fetch "invalid", he can fetch "root-key- 247 sentinel-is-ta-02323", but he cannot fetch "root-key-sentinel-not-ta- 248 02323". From this, Dave knows that he is behind an upgraded, 249 validating resolver, which has successfully installed the new, 02323 250 KSK. 252 Just like Charlie and Dave, Ed cannot fetch the "invalid" record. 253 This tells him that his resolvers are validating. When his 254 (upgraded) resolver performs the KSK Sentinel check for "root-key- 255 sentinel-is-ta-02323", it does *not* have the (new, 02323) KSK in 256 it's trust anchor store. This means check fails, and Ed's recursive 257 resolver converts the (valid) answer into a SERVFAIL error response. 258 It performs the same check for root-key-sentinel-not-ta- 259 02323.example.com; as it does not have the 02323 KSK, it is true that 260 this is not a trust anchor for it, and so it replies normally. This 261 means that Ed cannot fetch the "invalid" resource, he also cannot 262 fetch the "root-key-sentinel-is-ta-02323" resource, but he can fetch 263 the "root-key-sentinel-not-ta-02323" resource. This tells Ed that 264 his resolvers have not installed the new KSK. 266 Geoff would like to do a large scale test and provide the information 267 back to Alice. He uses some mechanism such as causing users to go to 268 a web page to cause a large number of users to attempt to resolve the 269 three resources, and then analyzes the results of the tests to 270 determine what percentage of users will be affected by the KSK 271 rollover event. 273 The above description is a simplified example - it is not anticipated 274 that Bob, Charlie, Dave and Ed will actually look for the absence or 275 presence of web resources; instead, the webpage that they load would 276 likely contain JavaScript (or similar) which displays the result of 277 the tests, sends the results to Geoff, or both. This sentinel 278 mechanism does not rely on the web: it can equally be used by trying 279 to resolve the names (for example, using the common "dig" command) 280 and checking which result in a SERVFAIL. 282 Note that the sentinel mechanism described here measures a very 283 different (and likely more useful) metric than [RFC8145]. RFC 8145 284 relies on resolvers reporting the list of keys that they have to root 285 servers. That reflects on how many resolvers will be impacted by a 286 KSK roll, but not what the user impact of the KSK roll will be. 288 3. Sentinel Mechanism in Resolvers 290 DNSSEC-Validating resolvers that implement this mechanism MUST 291 perform validation of responses in accordance with the DNSSEC 292 response validation specification [RFC4035]. 294 This sentinel mechanism makes use of two special labels: 296 o root-key-sentinel-is-ta- 298 o root-key-sentinel-not-ta- 300 Note that the is specified in the DNS label as unsigned 301 decimal integer (as described in [RFC4034], section 5.3), but zero- 302 padded to five digits (for example, a Key Tag 42 would be represented 303 in the label as 00042). 305 These labels trigger special processing in the resolver when 306 responses from authoritative servers are received. Labels containing 307 "root-key-sentinel-is-ta-" is used to answer the question 308 "Is this the Key Tag a trust anchor which the validating DNS resolver 309 is currently trusting?" Labels containing "root-key-sentinel-not-ta- 310 " is used to answer the question "Is this the Key Tag *not* 311 a trust anchor which the validating DNS resolver is currently 312 trusting?" 314 3.1. Preconditions 316 All of the following conditions must be met to trigger special 317 processing inside resolver code: 319 o The DNS response is DNSSEC validated and result of validation is 320 "Secure" 322 o The QTYPE is either A or AAAA (Query Type value 1 or 28) 324 o The OPCODE is QUERY 326 o The leftmost label of the QNAME is either "root-key-sentinel-is- 327 ta-" or "root-key-sentinel-not-ta-" 329 If any one of the preconditions is not met, the resolver MUST NOT 330 alter the DNS response based on the mechanism in this document. 332 3.2. Special processing 334 Responses which fullfill all of the preconditions in Section 3.1 335 require special processing, depending on leftmost label in the QNAME. 337 First, the resolver determines if the numerical value of is 338 equal to any of the Key Tags of an active root zone KSK which is 339 currently trusted by the local resolver and is stored in its store of 340 trusted keys. An active key is one which could currently be used for 341 validation (that is, a key that is not in either the AddPend or 342 Revoked state as described in [RFC5011]). 344 Second, the resolver alters the response being sent to the original 345 query based on both the left-most label and the presence of a key 346 with given Key Tag in the trust anchor store. Two labels and two 347 possible states of the keytag generate four possible combinations 348 summarized in the table: 350 Label | Key Tag is trusted | Key Tag is not trusted 351 ------------------------------------------------------------------ 352 is-ta | return original answer | return SERVFAIL 353 not-ta | return SERVFAIL | return original answer 355 Instruction "return SERVFAIL" means that the resolver MUST set 356 RCODE=SERVFAIL (value 2) and MUST empty the ANSWER section of the DNS 357 response, ignoring all other documents which specify content of the 358 ANSWER section. 360 4. Processing Sentinel Results 362 This proposed test that uses the sentinel detection mechanism 363 described in this document is based on the use of three DNS names 364 that have three distinct DNS resolution behaviours. The test is 365 intended to allow a user or a third party to determine the state of 366 their DNS resolution system, and, in particular, whether or not they 367 are using one or more validating DNS resolvers that use a particular 368 trust anchor for the root zone. 370 The critical aspect of the DNS names used in this mechanism is that 371 they contain the specified label for either the positive and negative 372 test as the left-most label in the query name. 374 The sentinel detection process uses a test with three query names: 376 o A query name containing the left-most label "root-key-sentinel-is- 377 ta-". This corresponds to a a validly-signed RRset in 378 the zone, so that responses associated with queried names in this 379 zone can be authenticated by a DNSSEC-validating resolver. Any 380 validly-signed DNS zone can be used for this test. 382 o A query name containing the left-most label "root-key-sentinel- 383 not-ta-". This is also a validly-signed name. Any 384 validly-signed DNS zone can be used for this test. 386 o A query name that is signed with a DNSSEC signature that cannot be 387 validated (such as if the corresponding RRset is not signed with a 388 valid RRSIG record). 390 The responses received from queries to resolve each of these names 391 would allow us to infer a trust key state of the resolution 392 environment. The techniques describes in this document rely on 393 (DNSSEC validating) resolvers responding with SERVFAIL to valid 394 answers. Note that a slew of other issues can also cause SERVFAIL 395 responses, and so the sentinel processing may sometimes result in 396 incorrect conclusions. 398 To describe this process of classification, we can classify resolvers 399 into four distinct behavior types, for which we will use the labels: 400 "Vnew", "Vold", "Vleg", and "nonV". These labels correspond to 401 resolver behaviour types as follows: 403 Vnew: A DNSSEC-Validating resolver that is configured to implement 404 this mechanism has loaded the nominated key into its local trusted 405 key store will respond with an A or AAAA RRset response for "root- 406 key-sentinel-is-ta" queries, SERVFAIL for "root-key-sentinel-not- 407 ta" queries and SERVFAIL for the invalidly signed name queries. 409 Vold: A DNSSEC-Validating resolver that is configured to implement 410 this mechanism that has not loaded the nominated key into its 411 local trusted key store will respond with an SERVFAIL for "root- 412 key-sentinel-is-ta" queries, an A or AAAA RRset response for 413 "root-key-sentinel-not-ta" queries and SERVFAIL for the invalidly 414 signed name queries. 416 Vleg: A DNSSEC-Validating resolver that does not implement this 417 mechanism will respond with an A or AAAA RRset response for "root- 418 key-sentinel-is-ta", an A or AAAA RRset response for "root-key- 419 sentinel-not-ta" and SERVFAIL for the invalid name. 421 nonV: A non-DNSSEC-Validating resolver will respond with an A or 422 AAAA record response for "root-key-sentinel-is-ta", an A record 423 response for "root-key-sentinel-not-ta" and an A or AAAA RRset 424 response for the invalid name. 426 Given the clear delineation amongst these three cases, if a client 427 directs these three queries to a simple resolver, the variation in 428 response to the three queries should allow the client to determine 429 the category of the resolver, and if it supports this mechanism, 430 whether or not it has a particular key in its trust anchor store. 432 Query 433 +----------+-----------+------------+ 434 | is-ta | not-ta | invalid | 435 +-------+----------+-----------+------------+ 436 | Vnew | A | SERVFAIL | SERVFAIL | 437 | Vold | SERVFAIL | A | SERVFAIL | 438 Type | Vleg | A | A | SERVFAIL | 439 | nonV | A | A | A | 440 +-------+----------+-----------+------------+ 442 A "Vnew" type says that the nominated key is trusted by the resolver 443 and has been loaded into its local trusted key stash. A "Vold" type 444 says that the nominated key is not yet trusted by the resolver in its 445 own right. A "Vleg" type does not give any information about the 446 trust anchors, and a "nonV" type indicates that the resolver does not 447 perform DNSSEC validation. 449 5. Sentinel Test Result Considerations 451 The description in the previous section describes a simple situation 452 where the test queries were being passed to a single recursive 453 resolver that directly queried authoritative name servers, including 454 the root servers. 456 There is also the common case where the end client's browser or 457 operating system is configured to use multiple resolvers. In these 458 cases, a SERVFAIL response from one resolver may cause the end client 459 to repeat the query against one of the other configured resolvers. 460 If the client's browser or operating system does not try the 461 additional resolvers, the sentinel test will effectively only be for 462 the first resolver. 464 If any of the client's resolvers are non-validating resolvers, the 465 tests will result in the client reporting that it has a non- 466 validating DNS environment ("nonV"), which is effectively the case. 468 If all of the client resolvers are DNSSEC-validating resolvers, but 469 some do not support this trusted key mechanism, then the result will 470 be indeterminate with respect to trusted key status ("Vleg"). 471 Simlarly, if all the client's resolvers support this mechanism, but 472 some have loaded the key into the trusted key stash and some have 473 not, then the result is indeterminate ("Vleg"). 475 There is also the common case of a recursive resolver using a 476 forwarder. 478 If the resolver is non-validating, and it has a single forwarder 479 clause, then the resolver will presumably mirror the capabilities of 480 the forwarder target resolver. If this non-validating resolver it 481 has multiple forwarders, then the above considerations will apply. 483 If the validating resolver has a forwarding configuration, and uses 484 the CD bit on all forwarded queries, then this resolver is acting in 485 a manner that is identical to a standalone resolver. The same 486 consideration applies if any one of the forwarder targets is a non- 487 validating resolver. Similarly, if all the forwarder targets do not 488 apply this trusted key mechanism, the same considerations apply. 490 A more complex case is where all of the following conditions all 491 hold: 493 o Both the validating resolver and the forwarder target resolver 494 support this trusted key sentinel mechanism 496 o The local resolver's queries do not have the CD bit set 498 o The trusted key state differs between the forwarding resolver and 499 the forwarder target resolver 501 In such a case, either the outcome is indeterminate validating 502 ("Vleg"), or a case of mixed signals (SERVFAIL in all three 503 responses), which is similarly an indeterminate response with respect 504 to the trusted key state. 506 Please note that SERVFAIL might be cached according to [RFC2308] 507 section 7 for up to 5 minutes and a positive answer for up to its 508 TTL. 510 6. Security Considerations 512 This document describes a mechanism to allow users and third parties 513 to determine the trust state of root zone key signing keys in the DNS 514 resolution system that they use. 516 The mechanism does not require resolvers to set otherwise 517 unauthenticated responses to be marked as authenticated, and does not 518 alter the security properties of DNSSEC with respect to the 519 interpretation of the authenticity of responses that are so marked. 521 The mechanism does not require any further significant processing of 522 DNS responses, and queries of the form described in this document do 523 not impose any additional load that could be exploited in an attack 524 over the the normal DNSSEC validation processing load. 526 7. Privacy Considerations 528 The mechansim in this document enables third parties (with either 529 good or bad intentions) to learn something about the security 530 configuration of recursive name servers. That is, someone who can 531 cause an Internet user to make specific DNS queries (e.g. via web- 532 based advertisements or javascript in web pages), can then determine 533 which trust anchors are configured in the user's resolver. 535 8. IANA Considerations 537 [Note to IANA, to be removed prior to publication: there are no IANA 538 considerations stated in this version of the document.] 540 9. Acknowledgements 542 This document has borrowed extensively from [RFC8145] for the 543 introductory text, and the authors would like to acknowledge and 544 thank the authors of that document both for some text excerpts and 545 for the more general stimulation of thoughts about monitoring the 546 progress of a roll of the KSK of the root zone of the DNS. 548 The authors would like to thank Joe Abley, Mehmet Akcin, Mark 549 Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David 550 Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes 551 Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis, 552 George Michaelson, Benno Overeinder, Matthew Pounsett, Andreas 553 Schulze, Mukund Sivaraman, Petr Spacek, Andrew Sullivan, Paul Vixie, 554 Duane Wessels and Paul Wouters for their helpful feedback. 556 The authors would like to especially call out Paul Hoffman and Duane 557 Wessels for providing comments in the form of a pull request. Petr 558 Spacek implemented early versions of this technique into the Knot 559 resolver, identified a number of places where it wasn't clear, and 560 provided very helpful text to address this. 562 10. Change Log 564 RFC Editor: Please remove this section! 566 Note that this document is being worked on in GitHub - see Abstract. 567 The below is mainly large changes, and is not authoritative. 569 From -08 to -07: 571 o Changed title from "A Sentinel for Detecting Trusted Keys in 572 DNSSEC" to "A Root Key Trust Anchor Sentinel for DNSSEC". 574 o Changed magic string from "kskroll-sentinel-" to "root-key- 575 sentinel-" -- this time for sure, Rocky! 577 From -07 to -06: 579 o Addressed GitHub PR #14: Clarifications regarding caching and 580 SERVFAIL responses 582 o Addressed GitHub PR #12, #13: Clarify situation with multiple 583 resolvers, Fix editorial nits. 585 From -05 to -06: 587 o Paul improved my merging of Petr's text to make it more readable. 588 Minor change, but this is just before the cut-off, so I wanted it 589 maximally readable. 591 From -04 to -05: 593 o Incorporated Duane's #10 595 o Integrated Petr Spacek's Issue - https://github.com/APNIC-Labs/ 596 draft-kskroll-sentinel/issues/9 (note that commit-log incorrectly 597 referred to Duane's PR as number 9, it is actually 10). 599 From -03 to -04: 601 o Addressed GitHub pull requests #4, #5, #6, #7 #8. 603 o Added Duane's privacy concerns 605 o Makes the use cases clearer 607 o Fixed some A/AAAA stuff 609 o Changed the example numbers 611 o Made it clear that names and addresses must be real 613 From -02 to -03: 615 o Integrated / published comments from Paul in GitHub PR #2 - 616 https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/2 618 o Made the keytag be decimal, not hex (thread / consensus in 619 https://mailarchive.ietf.org/arch/msg/dnsop/ 620 Kg7AtDhFRNw31He8n0_bMr9hBuE ) 622 From -01 to 02: 624 o Removed Address Record definition. 626 o Clarified that many things can cause SERVFAIL. 628 o Made examples FQDN. 630 o Fixed a number of typos. 632 o Had accidentally said that Charlie was using a non-validating 633 resolver in example. 635 o [ TODO(WK): Doc says keytags are hex, is this really what the WG 636 wants? ] 638 o And active key is one that can be used *now* (not e.g AddPend) 640 From -00 to 01: 642 o Added a conversational description of how the system is intended 643 to work. 645 o Clarification that this is for the root. 647 o Changed the label template from _is-ta- to kskroll- 648 sentinel-is-ta-. This is because BIND (at least) will 649 not allow records which start with an underscore to have address 650 records (CNAMEs, yes, A/AAAA no). Some browsers / operating 651 systems also will not fetch resources from names which start with 652 an underscore. 654 11. References 656 11.1. Normative References 658 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 659 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 660 . 662 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 663 Rose, "DNS Security Introduction and Requirements", RFC 664 4033, DOI 10.17487/RFC4033, March 2005, . 667 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 668 Rose, "Resource Records for the DNS Security Extensions", 669 RFC 4034, DOI 10.17487/RFC4034, March 2005, 670 . 672 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 673 Rose, "Protocol Modifications for the DNS Security 674 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 675 . 677 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 678 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 679 September 2007, . 681 11.2. Informative References 683 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 684 Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC 685 8145, DOI 10.17487/RFC8145, April 2017, . 688 Authors' Addresses 690 Geoff Huston 692 Email: gih@apnic.net 693 URI: http://www.apnic.net 695 Joao Silva Damas 697 Email: joao@apnic.net 698 URI: http://www.apnic.net 700 Warren Kumari 702 Email: warren@kumari.net