< draft-ietf-dnsop-kskroll-sentinel-12.txt   draft-ietf-dnsop-kskroll-sentinel-13.txt >
DNSOP G. Huston DNSOP G. Huston
Internet-Draft J. Damas Internet-Draft J. Damas
Intended status: Standards Track APNIC Intended status: Standards Track APNIC
Expires: November 3, 2018 W. Kumari Expires: December 6, 2018 W. Kumari
Google Google
May 2, 2018 June 4, 2018
A Root Key Trust Anchor Sentinel for DNSSEC A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-12 draft-ietf-dnsop-kskroll-sentinel-13
Abstract Abstract
The DNS Security Extensions (DNSSEC) were developed to provide origin The DNS Security Extensions (DNSSEC) were developed to provide origin
authentication and integrity protection for DNS data by using digital authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be verified by building a signatures. These digital signatures can be verified by building a
chain of trust starting from a trust anchor and proceeding down to a chain of trust starting from a trust anchor and proceeding down to a
particular node in the DNS. This document specifies a mechanism that particular node in the DNS. This document specifies a mechanism that
will allow an end user and third parties to determine the trusted key will allow an end user and third parties to determine the trusted key
state for the root key of the resolvers that handle that user's DNS state for the root key of the resolvers that handle that user's DNS
queries. Note that this method is only applicable for determining queries. Note that this method is only applicable for determining
which keys are in the trust store for the root key. which keys are in the trust store for the root key.
There is an example / toy implementation of this at http://www.ksk-
test.net .
[ This document is being collaborated on in Github at: [ This document is being collaborated on in Github at:
https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most
recent version of the document, open issues, etc should all be recent version of the document, open issues, etc should all be
available here. The authors (gratefully) accept pull requests. Text available here. The authors (gratefully) accept pull requests. RFC
in square brackets will be removed before publication. ] Editor, please remove text in square brackets before publication. ]
[ NOTE: This version uses the labels "root-key-sentinel-is-ta-", and
"root-key-sentinel-not-ta-".; older versions of this document used
"kskroll-sentinel-is-ta-<key-tag>", "kskroll-sentinel-not-ta-<key-
tag>", and before that, "_is-ta-<key-tag>", "_not-ta-<key-tag>".
Also note that the format of the tag-index is now zero-filled
decimal. Apologies to those who have begun implementing earlier
versions of this specification.]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2018. This Internet-Draft will expire on December 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 4 2. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 4
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Special Processing . . . . . . . . . . . . . . . . . . . 5 2.2. Special Processing . . . . . . . . . . . . . . . . . . . 5
3. Processing Sentinel Results . . . . . . . . . . . . . . . . . 5 3. Sentinel Tests for a Single DNS Resolver . . . . . . . . . . 6
4. Sentinel Test Result Considerations . . . . . . . . . . . . . 7 3.1. Forwarders . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Sentinel Tests for a Set of Resolvers . . . . . . . . . . . . 9
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 4.1. Test Scenario and Objective . . . . . . . . . . . . . . . 9
7. Implementation Experience . . . . . . . . . . . . . . . . . . 9 4.2. Test Assumptions . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Implementation Experience . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Protocol Walkthrough Example . . . . . . . . . . . . 14 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Protocol Walkthrough Example . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and
[RFC4035] were developed to provide origin authentication and [RFC4035] were developed to provide origin authentication and
integrity protection for DNS data by using digital signatures. integrity protection for DNS data by using digital signatures.
DNSSEC uses Key Tags to efficiently match signatures to the keys from DNSSEC uses Key Tags to efficiently match signatures to the keys from
which they are generated. The Key Tag is a 16-bit value computed which they are generated. The Key Tag is a 16-bit value computed
from the RDATA portion of a DNSKEY RR using a formula found in "Key from the RDATA portion of a DNSKEY RR using a formula found in "Key
Tag Calculation" (Appendix B of "Resource Records for the DNS Tag Calculation" (Appendix B of "Resource Records for the DNS
Security Extensions" [RFC4034]), a formula similar to a ones- Security Extensions" [RFC4034]), a formula similar to a ones-
complement checksum. RRSIG RRs contain a Key Tag field whose value complement checksum. RRSIG RRs contain a Key Tag field whose value
is equal to the Key Tag of the DNSKEY RR that validates the is equal to the Key Tag of the DNSKEY RR that validates the
signature. signature.
This document specifies how validating resolvers can respond to This document specifies how security-aware DNS resolvers that perform
certain queries in a manner that allows a querier to deduce whether a validation of their responses can respond to certain queries in a
particular key for the root has been loaded into that resolver's manner that allows an agent performing the queries to deduce whether
trusted key store. In particular, this response mechanism can be a particular key for the root has been loaded into that resolver's
used to determine whether a certain root zone KSK is ready to be used trusted key store. This document also describes a procedure where a
as a trusted key, within the context of a planned root zone KSK key collection of resolvers can be tested to determine if at least one of
roll, by this resolver. these resolvers has loaded a given key into its trusted key store.
These tests can be used to determine whether a certain root zone KSK
is ready to be used as a trusted key, within the context of a planned
root zone KSK key roll.
There are two primary use cases for this mechanism: There are two primary use cases for this mechanism:
o Users want to know whether the resolvers they use are ready for an o Users may wish to ascertain whether their DNS resolution
upcoming root KSK rollover environment resolvers is ready for an upcoming root KSK rollover.
o Researchers want to perform Internet-wide studies about the o Researchers want to perform Internet-wide studies about the
percentage of users who will be ready for an upcoming root KSK proportion of users who will be negatively impacted an upcoming
rollover root KSK rollover.
The mechanism described in this document meets both of these use The mechanism described in this document meets both of these use
cases. This new mechanism is OPTIONAL to implement and use, although cases. This new mechanism is OPTIONAL to implement and use, although
for reasons of supporting broad-based measurement techniques, it is for reasons of supporting broad-based measurement techniques, it is
strongly preferred that configurations of DNSSEC-validating resolvers strongly preferred that configurations of DNSSEC-validating resolvers
enabled this mechanism by default, allowing for local configuration enabled this mechanism by default, allowing for local configuration
directives to disable this mechanism if desired. directives to disable this mechanism if desired.
The sentinel test described in this document determines whether a The KSK sentinel tests described in this document use a test
user's browser or operating system looking up the special names that comprising of a set of DNS queries to domain names that have special
are used in this protocol would be able to validate using the root values for the left-most label. The test relies on recursive
KSK indicated by the special names. The protocol uses the DNS resolvers supporting a mechanism that recognises this special name
SERVFAIL response code (RCODE 2) for this purpose because that is the pattern in queries, and under certain defined circumstances will
response code that is returned by resolvers when DNSSEC validation return a DNS SERVFAIL response code (RCODE 2), mimicking the response
fails. If a browser or operating system has multiple resolvers code that is returned by security-aware resolvers when DNSSEC
configured, and those resolvers have different properties (for validation fails.
If a browser or operating system is configured with multiple
resolvers, and those resolvers have different properties (for
example, one performs DNSSEC validation and one does not), the example, one performs DNSSEC validation and one does not), the
sentinel mechanism might search among the different resolvers, or sentinel test described in this document can still be used, but it
might not, depending on how the browser or operating system is makes a number of assumptions about DNS resolution behaviour that may
configured. not necessarily hold in all environments. If these assumptions do
not hold (such as, for example, requiring the stub resolver to query
the next recursive resolver in the locally configured set upon
receipt of a SERVFAIL response code) then this test may produce
indeterminate or inconsistent results. In some cases where these
assumptions do not hold, repeating the same test query set may
generate different results.
Note that the sentinel mechanism described here measures a very Note that the sentinel mechanism described here measures a very
different (and likely more useful) metric than [RFC8145]. RFC 8145 different (and likely more useful) metric than [RFC8145]. RFC 8145
relies on resolvers reporting towards the root servers a list of relies on resolvers reporting towards the root servers a list of
locally cached trust anchors for the root zone. Those reports can be locally cached trust anchors for the root zone. Those reports can be
used to infer how many resolvers may be impacted by a KSK roll, but used to infer how many resolvers may be impacted by a KSK roll, but
not what the user impact of the KSK roll will be. not what the user impact of the KSK roll will be.
1.1. Terminology 1.1. Terminology
skipping to change at page 4, line 37 skipping to change at page 4, line 41
o root-key-sentinel-is-ta-<key-tag> o root-key-sentinel-is-ta-<key-tag>
o root-key-sentinel-not-ta-<key-tag> o root-key-sentinel-not-ta-<key-tag>
Note that the <key-tag> is specified in the DNS label as unsigned Note that the <key-tag> is specified in the DNS label as unsigned
decimal integer (as described in [RFC4034], section 5.3), but zero- decimal integer (as described in [RFC4034], section 5.3), but zero-
padded to five digits (for example, a Key Tag value of 42 would be padded to five digits (for example, a Key Tag value of 42 would be
represented in the label as 00042). represented in the label as 00042).
These labels trigger special processing in the resolver when These labels trigger special processing in the validating DNS
responses from authoritative servers are received. Labels containing resolver when responses from authoritative servers are received.
"root-key-sentinel-is-ta-<key-tag>" is used to answer the question Labels containing "root-key-sentinel-is-ta-<key-tag>" is used to
"Is this the Key Tag of a Key which the validating DNS resolver is answer the question "Is this the Key Tag of a key which the
currently trusting as a trust anchor?" Labels containing "root-key- validating DNS resolver is currently trusting as a trust anchor?"
sentinel-not-ta-<key-tag>" is used to answer the question "Is this Labels containing "root-key-sentinel-not-ta-<key-tag>" is used to
the Key Tag of a Key which the validating DNS resolver is *not* answer the question "Is this the Key Tag of a key which the
currently trusting as a trust anchor?" validating DNS resolver is *not* currently trusting as a trust
anchor?"
2.1. Preconditions 2.1. Preconditions
All of the following conditions must be met to trigger special All of the following conditions must be met to trigger special
processing inside resolver code: processing inside resolver code:
o The DNS response is DNSSEC validated. o The DNS response is DNSSEC validated.
o The result of validation is "Secure". o The result of validation is "Secure".
o The Checking Disabled (CD) bit in the query is not set. o The Checking Disabled (CD) bit in the query is not set.
o The QTYPE is either A or AAAA (Query Type value 1 or 28) o The QTYPE is either A or AAAA (Query Type value 1 or 28).
o The OPCODE is QUERY o The OPCODE is QUERY.
o The leftmost label of the original QNAME (the name sent in the o The leftmost label of the original QNAME (the name sent in the
Question Section in the original query) is either "root-key- Question Section in the original query) is either "root-key-
sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>" sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>".
If any one of the preconditions is not met, the resolver MUST NOT If any one of the preconditions is not met, the resolver MUST NOT
alter the DNS response based on the mechanism in this document. alter the DNS response based on the mechanism in this document.
2.2. Special Processing 2.2. Special Processing
Responses which fulfil all of the preconditions in Section 2.1 Responses which fulfil all of the preconditions in Section 2.1
require special processing, depending on leftmost label in the QNAME. require special processing, depending on leftmost label in the QNAME.
First, the resolver determines if the numerical value of <key-tag> is First, the resolver determines if the numerical value of <key-tag> is
equal to any of the Key Tag values of an active root zone KSK which equal to any of the Key Tag values of an active root zone KSK which
is currently trusted by the local resolver and is stored in its store is currently trusted by the local resolver and is stored in its store
of trusted keys. An active root zone KSK is one which could of trusted keys. An active root zone KSK is one which could
currently be used for validation (that is, a Key that is not in currently be used for validation (that is, a key that is not in
either the AddPend or Revoked state as described in [RFC5011]). either the AddPend or Revoked state as described in [RFC5011]).
Second, the resolver alters the response being sent to the original Second, the resolver alters the response being sent to the original
query based on both the left-most label and the presence of a Key query based on both the left-most label and the presence of a key
with given Key Tag in the trust anchor store. Two labels and two with given Key Tag in the trust anchor store. Two labels and two
possible states of the corresponding Key generate four possible possible states of the corresponding key generate four possible
combinations summarized in the table: combinations summarized in the table:
Label | Key is trusted | Key is not trusted Label | Key is trusted | Key is not trusted
------------------------------------------------------------------ ------------------------------------------------------------------
is-ta | return original answer | return SERVFAIL is-ta | return original answer | return SERVFAIL
not-ta | return SERVFAIL | return original answer not-ta | return SERVFAIL | return original answer
Instruction "return SERVFAIL" means that the resolver MUST set Instruction "return SERVFAIL" means that the resolver MUST set
RCODE=SERVFAIL (value 2) and MUST empty the ANSWER section of the DNS RCODE=SERVFAIL (value 2) and the ANSWER section of the DNS response
response, ignoring all other documents which specify content of the MUST be empty, ignoring all other documents which specify content of
ANSWER section. the ANSWER section.
3. Processing Sentinel Results 3. Sentinel Tests for a Single DNS Resolver
This proposed test that uses the sentinel detection mechanism This section describes the use of the sentinel detection mechanism
described in this document is based on the use of three DNS names against a single DNS recursive resolver in order to determine whether
that have three distinct DNS resolution behaviours. The test is this resolver is using a particular trust anchor to validate DNSSEC-
intended to allow a user or a third party to determine the state of signed responses.
their DNS resolution system, and, in particular, whether or not they
are using one or more validating DNS resolvers that use a particular Note that the test in this section applies to a single DNS resolver.
trust anchor for the root zone. The test described in Section 4 applies instead to a collection of
DNS resolvers, as might be found in the DNS configuration of an end-
user environment.
The critical aspect of the DNS names used in this mechanism is that The critical aspect of the DNS names used in this mechanism is that
they contain the specified label for either the positive and negative they contain the specified label for either the positive and negative
test as the left-most label in the query name. test as the left-most label in the query name.
The sentinel detection process uses a test with three query names: The sentinel detection procedure can test a DNS resolver using three
queries:
o A query name containing the left-most label "root-key-sentinel-is- o A query name containing the left-most label "root-key-sentinel-is-
ta-<key-tag>". This corresponds to a a validly-signed RRset in ta-<key-tag>". This corresponds to a a validly-signed RRset in
the zone, so that responses associated with queried names in this the zone, so that responses associated with queried names in this
zone can be authenticated by a DNSSEC-validating resolver. Any zone can be authenticated by a DNSSEC-validating resolver. Any
validly-signed DNS zone can be used for this test. validly-signed DNS zone can be used for this test.
o A query name containing the left-most label "root-key-sentinel- o A query name containing the left-most label "root-key-sentinel-
not-ta-<key-tag>". This is also a validly-signed name. Any not-ta-<key-tag>". This is also a validly-signed name. Any
validly-signed DNS zone can be used for this test. validly-signed DNS zone can be used for this test.
o A query name that is signed with a DNSSEC signature that cannot be o A query name that is signed with a DNSSEC signature that cannot be
validated (described as a "bogus" RRset in Section 5 of [RFC4033], validated (described as a "bogus" RRset in Section 5 of [RFC4033],
when, for example, an RRset is not signed with a valid RRSIG when, for example, an RRset is not signed with a valid RRSIG
record). record).
The responses received from queries to resolve each of these names The responses received from queries to resolve each of these names
would allow us to infer a trust key state of the resolution can be evaluated to infer a trust key state of the DNS resolver.
environment. The techniques describes in this document rely on
(DNSSEC validating) resolvers responding with SERVFAIL to valid
answers. Note that a slew of other issues can also cause SERVFAIL
responses, and so the sentinel processing may sometimes result in
incorrect conclusions.
To describe this process of classification, we can classify resolvers An essential assumption here is that this technique relies on
into four distinct behavior types, for which we will use the labels: security-aware (DNSSEC validating) resolvers responding with a
"Vnew", "Vold", "Vleg", and "nonV". These labels correspond to SERVFAIL response code to queries where DNSSEC checking is requested
resolver behaviour types as follows: and the response cannot be validated. Note that a slew of other
issues can also cause SERVFAIL responses, and so the sentinel
processing may sometimes result in incorrect or indeterminate
conclusions.
Vnew: A DNSSEC-Validating resolver that is configured to implement To describe this process of classification, DNS resolvers are
this mechanism has loaded the nominated key into its local trusted classified by five distinct behavior types using the labels: "Vnew",
key store will respond with an A or AAAA RRset response for "root- "Vold", "Vind", "nonV", and "other". These labels correspond to
key-sentinel-is-ta" queries, SERVFAIL for "root-key-sentinel-not- resolver system behaviour types as follows:
ta" queries and SERVFAIL for the invalidly signed name queries.
Vold: A DNSSEC-Validating resolver that is configured to implement Vnew: A DNS resolver that is configured to implement this mechanism
this mechanism that has not loaded the nominated key into its and has loaded the nominated key into their local trusted key
local trusted key store will respond with an SERVFAIL for "root- stores will respond with an A or AAAA RRset response for the
key-sentinel-is-ta" queries, an A or AAAA RRset response for associated "root-key-sentinel-is-ta" queries, SERVFAIL for "root-
"root-key-sentinel-not-ta" queries and SERVFAIL for the invalidly key-sentinel-not-ta" queries and SERVFAIL for the signed name
signed name queries. queries that return "bogus" validation status.
Vleg: A DNSSEC-Validating resolver that does not implement this Vold: A DNS resolver that is configured to implement this mechanism
and has not loaded the nominated key into their local trusted key
stores will respond with an SERVFAIL for the associated "root-key-
sentinel-is-ta" queries, an A or AAAA RRset response for "root-
key-sentinel-not-ta" queries and SERVFAIL for the signed name
queries that return "bogus" validation status.
Vind: A DNS resolver that has is not configured to implement this
mechanism will respond with an A or AAAA RRset response for "root- mechanism will respond with an A or AAAA RRset response for "root-
key-sentinel-is-ta", an A or AAAA RRset response for "root-key- key-sentinel-is-ta", an A or AAAA RRset response for "root-key-
sentinel-not-ta" and SERVFAIL for the invalid name. sentinel-not-ta" and SERVFAIL for the name that returns "bogus"
validation status. This set of responses does not give any
information about the trust anchors used by this resolver.
nonV: A non-DNSSEC-Validating resolver will respond with an A or nonV: A non-security-aware DNS resolver will respond with an A or
AAAA record response for "root-key-sentinel-is-ta", an A record AAAA record response for "root-key-sentinel-is-ta", an A record
response for "root-key-sentinel-not-ta" and an A or AAAA RRset response for "root-key-sentinel-not-ta" and an A or AAAA RRset
response for the invalid name. response for the name that returns "bogus" validation status.
Given the clear delineation amongst these three cases, if a client other: There is the potential to admit other combinations of
directs these three queries to a simple resolver, the variation in responses to these three queries. While this may appear self-
response to the three queries should allow the client to determine contradictory, there are cases where such an outcome is possible.
the category of the resolver, and if it supports this mechanism, For example, in DNS resolver farms what appears to be a single DNS
whether or not it has a particular key in its trust anchor store. resolver that responds to queries passed to a single IP address is
in fact constructed as a a collection of slave resolvers, and the
query is passed to one of these internal resolver engines. If
these individual slave resolvers in the farm do not behave
identically, then other sets of results can be expected from these
three queries. In such a case, no determination about the
capabilities of this DNS resolver farm can be made.
Note that SERVFAIL might be cached according to Section 7 of
[RFC2308] for up to 5 minutes and a positive answer for up to its
TTL.
If a client directs these three queries to a single resolver, the
responses should allow the client to determine the capability of the
resolver, and if it supports this sentinel mechanism, whether or not
it has a particular key in its trust anchor store, as in the
following table:
Query Query
+----------+-----------+------------+ +----------+-----------+------------+
| is-ta | not-ta | invalid | | is-ta | not-ta | bogus |
+-------+----------+-----------+------------+ +-------+----------+-----------+------------+
| Vnew | A | SERVFAIL | SERVFAIL | | Vnew | A | SERVFAIL | SERVFAIL |
| Vold | SERVFAIL | A | SERVFAIL | | Vold | SERVFAIL | A | SERVFAIL |
Type | Vleg | A | A | SERVFAIL | Type | Vind | A | A | SERVFAIL |
| nonV | A | A | A | | nonV | A | A | A |
| other | * | * | * |
+-------+----------+-----------+------------+ +-------+----------+-----------+------------+
A "Vnew" type says that the nominated key is trusted by the resolver Vnew: The nominated key is trusted by the resolver.
and has been loaded into its local trusted key stash. A "Vold" type
says that the nominated key is not yet trusted by the resolver in its
own right. A "Vleg" type does not give any information about the
trust anchors, and a "nonV" type indicates that the resolver does not
perform DNSSEC validation.
4. Sentinel Test Result Considerations
The description in the previous section describes a simple situation Vold: The nominated key is not yet trusted by the resolver.
where the test queries were being passed to a single recursive
resolver that directly queried authoritative name servers, including
the root servers.
There is also the common case where the end client's browser or Vind: There is no information about the trust anchors of the
operating system is configured to use multiple resolvers. In these resolver.
cases, a SERVFAIL response from one resolver may cause the end client
to repeat the query against one of the other configured resolvers.
If the client's browser or operating system does not try the nonV: The resolver does not perform DNSSEC validation.
additional resolvers, the sentinel test will effectively only be for
the first resolver.
If any of the client's resolvers are non-validating resolvers, the other: The properties of the resolver cannot be analyzed by this
tests will result in the client reporting that it has a non- protocol.
validating DNS environment ("nonV"), which is effectively the case.
If all of the client resolvers are DNSSEC-validating resolvers, but 3.1. Forwarders
some do not support this trusted key mechanism, then the result will
be indeterminate with respect to trusted key status ("Vleg").
Similarly, if all the client's resolvers support this mechanism, but
some have loaded the key into the trusted key stash and some have
not, then the result is indeterminate ("Vleg").
There is also the common case of a recursive resolver using a There is also the common case of a recursive resolver using a
forwarder. forwarder.
If the resolver is non-validating, and it has a single forwarder If the resolver is non-validating, and it has a single forwarder,
clause, then the resolver will presumably mirror the capabilities of then the resolver will presumably mirror the capabilities of the
the forwarder target resolver. If this non-validating resolver it forwarder target resolver.
has multiple forwarders, then the above considerations will apply.
If the validating resolver has a forwarding configuration, and uses If the validating resolver has a forwarding configuration, and uses
the CD bit on all forwarded queries, then this resolver is acting in the CD bit on all forwarded queries, then this resolver is acting in
a manner that is identical to a standalone resolver. The same a manner that is identical to a standalone resolver.
consideration applies if any one of the forwarder targets is a non-
validating resolver. Similarly, if all the forwarder targets do not
apply this trusted key mechanism, the same considerations apply.
A more complex case is where all of the following conditions all A more complex case is where all of the following conditions hold:
hold:
o Both the validating resolver and the forwarder target resolver o Both the validating resolver and the forwarder target resolver
support this trusted key sentinel mechanism support this trusted key sentinel mechanism
o The local resolver's queries do not have the CD bit set o The local resolver's queries do not have the CD bit set
o The trusted key state differs between the forwarding resolver and o The trusted key state differs between the forwarding resolver and
the forwarder target resolver the forwarder target resolver
In such a case, either the outcome is indeterminate validating In such a case, either the outcome is indeterminate validating
("Vleg"), or a case of mixed signals (SERVFAIL in all three ("Vind"), or a case of mixed signals such as SERVFAIL in all three
responses), which is similarly an indeterminate response with respect responses, ("other") which is similarly an indeterminate response
to the trusted key state. with respect to the trusted key state.
Please note that SERVFAIL might be cached according to [RFC2308] 4. Sentinel Tests for a Set of Resolvers
section 7 for up to 5 minutes and a positive answer for up to its
TTL. The description in Section 3 describes a trust anchor test that can
be used in the simple situation where the test queries were being
passed to a single recursive resolver that directly queries
authoritative name servers.
However, the common end user scenario is where a user's local DNS
resolution environment is configured to use a set of recursive
resolvers. The single resolver test technique will not function
reliably in such cases, as a a SERVFAIL response from one resolver
may cause the local stub resolver to repeat the query against one of
the other configured resolvers and the results may be inconclusive.
In describing a test procedure that can be used in this environment
of a set of DNS resolvers there are some necessary changes to the
nature of the question that this test can answer, the assumptions
about the behaviour of the DNS resolution environment, and some
further observations about potential variability in the test
outcomes.
4.1. Test Scenario and Objective
This test is not intended to expose which trust anchors are used by
any single DNS resolver.
The test scenario is explicitly restricted to that of the KSK
environment where a current active KSK (called "KSK-current") is to
be replaced with a new KSK (called "KSK-new"). The test is designed
to be run between when KSK-new is introduced into the root zone and
when the root zone is signed with KSK-new.
The objective of the test is to determine if the user will be
negatively impacted by the KSK roll. A "negative impact" for the
user is defined such that all the configured resolvers are security-
aware resolvers that perform validation of DNSSEC-signed responses,
and none of these resolvers have loaded KSK-new into their local
trust anchor set. In this situation, it is anticipated that once the
KSK is rolled the entire set of the user's resolvers will not be able
to validate the contents of the root zone and the user is likely to
loose DNS service as a result of this inability to perform successful
DNSSEC validation.
4.2. Test Assumptions
There are a number of assumptions about the DNS environment used in
this test. Where these assumptions do not hold, the results of the
test will be indeterminate.
o When a recursive resolver returns SERVFAIL to the user's stub
resolver, the stub resolver will send the same query to the next
resolver in the locally configured resolver set. It will continue
to do this until it gets a non-SERVFAIL response or until it runs
out of resolvers to try.
o When the user's stub resolver passes a query to a resolver in the
configured resolver set, it will get a consistent answer over the
timeframe of the queries. This assumption implies that if the
same query is asked by the same stub resolver multiple times in
succession to the same recursive resolver, the recursive
resolver's response will be the same for each of these queries.
o All DNSSEC-validating resolvers have KSK-current in their local
trust anchor cache.
There is no current published measurement data that indicates to what
extent the first two assumptions listed here are valid, and how many
end users may be impacted by these assumptions. In particular, the
first assumption, that a consistent SERFAIL response will cause the
local stub DNS resolution environment to query all of its configured
recursive resolvers before concluding that the name cannot be
resolved, is a very critical assumption for this test.
4.3. Test Procedure
The sentinel detection process test a DNS resolution environment with
three query names:
o A query name that is signed with a DNSSEC signature that cannot be
validated (described as a "bogus" RRset in Section 5 of [RFC4033],
when, for example, an RRset is not signed with a valid RRSIG
record).
o A query name containing the left-most label "root-key-sentinel-
not-ta-<key-tag-of-KSK-current>". This name MUST be a validly-
signed. Any validly-signed DNS zone can be used for this test.
o A query name containing the left-most label "root-key-sentinel-is-
ta-<key-tag-of-KSK-new>". This name MUST be a validly-signed.
Any validly-signed DNS zone can be used for this test.
The responses received from queries to resolve each of these names
can be evaluated to infer a trust key state of the user's DNS
resolution environment.
The responses to these queries are described using a simplified
notation. Each query will either result in a SERFVAIL response
(denoted as "S"), indicating that all of the resolvers in the
recursive resolver set returned the SERVFAIL response code, or result
in a response with the desire RRset value (denoted as "A"). The
queries are ordered by the "invalid" name, the "not-ta" label, then
the "is-ta" label, and a triplet notation denotes a particular
response. For example, the triplet "(S S A)" denotes a SERVFAIL
response to the invalid query, a SERVFAIL response to the "not-ta"
query and a RRset response to the "is-ta" query.
The set of all possible responses to these three queries are:
(A * *): If any resolver returns an "A" response for the query for
the invalid name, then the resolver set contains at least one non-
validating DNS resolver, and the user will not be impacted by the
KSK roll.
(S A *): If any of the resolvers returns an "A" response the the
"not-ta" query, then at least one of the resolvers does not
recognise the sentinel mechanism, and the behaviour of the
collection of resolvers during the KSK roll cannot be reliably
determined.
(S S A): This case implies that all of the resolvers in the set
perform DNSSEC-validation, all of the resolvers are aware of the
sentinel mechanism, and at least one resolver has loaded KSK-new
as a local trust anchor. The user will not be impacted by the KSK
roll.
(S S S): This case implies that all of the resolvers in the set
perform DNSSEC-validation, all of the resolvers are aware of the
sentinel mechanism, and none of the resolvers has loaded KSK-new
as a local trust anchor. The user will be negatively impacted by
the KSK roll.
5. Security Considerations 5. Security Considerations
This document describes a mechanism to allow users and third parties This document describes a mechanism to allow users to determine the
to determine the trust state of root zone key signing keys in the DNS trust anchor state of root zone key signing keys in the DNS
resolution system that they use. resolution system that they use. If the user executes third party
code, then this information may also be available to the third party.
The mechanism does not require resolvers to set otherwise The mechanism does not require resolvers to set otherwise
unauthenticated responses to be marked as authenticated, and does not unauthenticated responses to be marked as authenticated, and does not
alter the security properties of DNSSEC with respect to the alter the security properties of DNSSEC with respect to the
interpretation of the authenticity of responses that are so marked. interpretation of the authenticity of responses that are so marked.
The mechanism does not require any further significant processing of The mechanism does not require any further significant processing of
DNS responses, and queries of the form described in this document do DNS responses, and queries of the form described in this document do
not impose any additional load that could be exploited in an attack not impose any additional load that could be exploited in an attack
over the the normal DNSSEC validation processing load. over the normal DNSSEC validation processing load.
6. Privacy Considerations 6. Privacy Considerations
The mechanism in this document enables third parties (with either The mechanism in this document enables third parties (with either
good or bad intentions) to learn something about the security good or bad intentions) to learn something about the security
configuration of recursive name servers. That is, someone who can configuration of recursive DNS resolvers. That is, someone who can
cause an Internet user to make specific DNS queries (e.g. via web- cause an Internet user to make specific DNS queries (e.g. via web-
based advertisements or javascript in web pages), can, under certain based advertisements or javascript in web pages), can, under certain
specific circumstances that includes additional knowledge of the specific circumstances that includes additional knowledge of the
resolvers that are invoked by the user, determine which trust anchors resolvers that are invoked by the user, determine which trust anchors
are configured in these resolvers. Without this additional are configured in these resolvers. Without this additional
knowledge, the third party can infer the aggregate capabilities of knowledge, the third party can infer the aggregate capabilities of
the user's DNS resolution environment, but cannot necessarily infer the user's DNS resolution environment, but cannot necessarily infer
the trust configuration of any recursive name server. the trust configuration of any recursive name server.
7. Implementation Experience 7. Implementation Experience
skipping to change at page 10, line 5 skipping to change at page 12, line 51
Ondrej Sury of ISC has reported to the DNSOP Working Group in April Ondrej Sury of ISC has reported to the DNSOP Working Group in April
2018 that this technique was peer-reviewed and merged into BIND 2018 that this technique was peer-reviewed and merged into BIND
master branch with the intent to backport the feature into older master branch with the intent to backport the feature into older
release branches. release branches.
Benno Overeinder of NLnet Labs reported to the DNSOP Working Group in Benno Overeinder of NLnet Labs reported to the DNSOP Working Group in
April 2018 an intention to support this technique in Unbound in the April 2018 an intention to support this technique in Unbound in the
near future. near future.
An implementation of the client side of this protocol is available
at: http://www.ksk-test.net
8. IANA Considerations 8. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA [Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.] considerations stated in this version of the document.]
9. Acknowledgements 9. Acknowledgements
This document has borrowed extensively from [RFC8145] for the This document has borrowed extensively from [RFC8145] for the
introductory text, and the authors would like to acknowledge and introductory text, and the authors would like to acknowledge and
thank the authors of that document both for some text excerpts and thank the authors of that document both for some text excerpts and
for the more general stimulation of thoughts about monitoring the for the more general stimulation of thoughts about monitoring the
progress of a roll of the KSK of the root zone of the DNS. progress of a roll of the KSK of the root zone of the DNS.
The authors would like to thank Joe Abley, Mehmet Akcin, Mark The authors would like to thank Joe Abley, Mehmet Akcin, Mark
Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David
Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes
Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis, Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis,
George Michaelson, Benno Overeinder, Matthew Pounsett, Andreas George Michaelson, Benno Overeinder, Matthew Pounsett, Andreas
Schulze, Mukund Sivaraman, Petr Spacek, Andrew Sullivan, Ondrej Sury, Schulze, Mukund Sivaraman, Petr Spacek, Job Snijders, Andrew
Paul Vixie, Duane Wessels and Paul Wouters for their helpful Sullivan, Ondrej Sury, Paul Vixie, Duane Wessels and Paul Wouters for
feedback. their helpful feedback.
The authors would like to especially call out Paul Hoffman and Duane The authors would like to especially call out Paul Hoffman and Duane
Wessels for providing comments in the form of a pull request. Wessels for providing comments in the form of a pull request.
10. Change Log 10. Change Log
RFC Editor: Please remove this section! RFC Editor: Please remove this section!
Note that this document is being worked on in GitHub - see Abstract. Note that this document is being worked on in GitHub - see Abstract.
The below is mainly large changes, and is not authoritative. The below is mainly large changes, and is not authoritative.
From -12 to -13:
o Merged Paul Hoffmans PR#19, PR#20.
o Moved toy ksk-test.net to implmentation section.
o Split the test procedures between the test of a single DNS
resolvers and the test of a collection of DNS resolvers as would
be found in an end user environment.
From -11 to -12: From -11 to -12:
o Moved the Walkthrough Example to the end of the document as an o Moved the Walkthrough Example to the end of the document as an
appendix. appendix.
o Incorporated changes as proposed by Ondrej Sury, relating to a o Incorporated changes as proposed by Ondrej Sury, relating to a
consistent use of Key Tag and a reference to the definition of a consistent use of Key Tag and a reference to the definition of a
Bogus RRset. Bogus RRset.
o Corrected minor typos. o Corrected minor typos.
skipping to change at page 14, line 9 skipping to change at page 17, line 20
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
Anchor Knowledge in DNS Security Extensions (DNSSEC)", Anchor Knowledge in DNS Security Extensions (DNSSEC)",
RFC 8145, DOI 10.17487/RFC8145, April 2017, RFC 8145, DOI 10.17487/RFC8145, April 2017,
<https://www.rfc-editor.org/info/rfc8145>. <https://www.rfc-editor.org/info/rfc8145>.
Appendix A. Protocol Walkthrough Example Appendix A. Protocol Walkthrough Example
This Appendix provides a non-normative example of how the sentinel This Appendix provides a non-normative example of how the sentinel
mechanism could be used, and what each participant does. It is mechanism could be used, and what each participant does. It is
provided in a conversational tone to be easier to follow. provided in a conversational tone to be easier to follow. The
examples here all assume that each person has just one resolver, or a
system of resolvers that have the same properties.
Alice is in charge of the DNS root KSK (Key Signing Key), and would Alice is in charge of the DNS root KSK (Key Signing Key), and would
like to roll / replace the key with a new one. She publishes the new like to roll / replace the key with a new one. She publishes the new
KSK, but would like to be able to predict / measure what the impact KSK, but would like to be able to predict / measure what the impact
will be before removing/revoking the old key. The current KSK has a will be before removing/revoking the old key. The current KSK has a
Key Tag of 11112, the new KSK has a Key Tag of 02323. Users want to Key Tag of 11112, the new KSK has a Key Tag of 02323. Users want to
verify that their resolver will not break after Alice rolls the root verify that their resolver will not break after Alice rolls the root
KSK key (that is, starts signing with just the KSK whose Key Tag is KSK key (that is, starts signing with just the KSK whose Key Tag is
02323). 02323).
skipping to change at page 14, line 38 skipping to change at page 17, line 51
Geoff is a researcher, and would like to both provide a means for Geoff is a researcher, and would like to both provide a means for
Bob, Charlie, Dave and Ed to be able to perform tests, and also would Bob, Charlie, Dave and Ed to be able to perform tests, and also would
like to be able to perform Internet-wide measurements of what the like to be able to perform Internet-wide measurements of what the
impact will be (and report this back to Alice). impact will be (and report this back to Alice).
Geoff sets an authoritative DNS server for example.com, and also a Geoff sets an authoritative DNS server for example.com, and also a
webserver (www.example.com). He adds three address records to webserver (www.example.com). He adds three address records to
example.com: example.com:
invalid.example.com. IN AAAA 2001:db8::1 bogus.example.com. IN AAAA 2001:db8::1
root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1 root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1
root-key-sentinel-not-ta-02323.example.com. IN AAAA 2001:db8::1 root-key-sentinel-not-ta-11112.example.com. IN AAAA 2001:db8::1
Note that the use of "example.com" names and the addresses here are Note that the use of "example.com" names and the addresses here are
examples. In a real deployment, the domain names need to be under examples. In a real deployment, the domain names need to be under
control of the researcher, and the addresses must be real, reachable control of the researcher, and the addresses must be real, reachable
addresses. addresses.
Geoff then DNSSEC signs the example.com zone, and intentionally makes Geoff then DNSSEC signs the example.com zone, and intentionally makes
the invalid.example.com record invalid/bogus (for example, by editing the bogus.example.com record have bogus validation status (for
the signed zone and entering garbage for the signature). Geoff also example, by editing the signed zone and entering garbage for the
configures his webserver to listen on 2001:db8::1 and serve a signature). Geoff also configures his webserver to listen on
resource (for example, a 1x1 GIF, 1x1.gif) for all of these names. 2001:db8::1 and serve a resource (for example, a 1x1 GIF, 1x1.gif)
The webserver also serves a webpage (www.example.com) which contains for all of these names. The webserver also serves a webpage
links to these 3 resources (http://invalid.example.com/1x1.gif, (www.example.com) which contains links to these 3 resources
http://root-key-sentinel-is-ta-02323.example.com/1x1.gif, (http://bogus.example.com/1x1.gif, http://root-key-sentinel-is-ta-
http://root-key-sentinel-not-ta-02323.example.com/1x1.gif). 02323.example.com/1x1.gif, http://root-key-sentinel-not-ta-
11112.example.com/1x1.gif).
Geoff then asks Bob, Charlie, Dave and Ed to browse to Geoff then asks Bob, Charlie, Dave and Ed to browse to
www.example.com. Using the methods described in this document, the www.example.com. Using the methods described in this document, the
users can figure out what their fate will be when the 11112 KSK is users can figure out what their fate will be when the 11112 KSK is
removed. removed.
Bob is not using a validating resolver. This means that he will be Bob is not using a validating resolver. This means that he will be
able to resolve invalid.example.com (and fetch the 1x1 GIF) - this able to resolve bogus.example.com (and fetch the 1x1 GIF) - this
tells him that the KSK roll does not affect him, and so he will be tells him that the KSK roll does not affect him, and so he will be
OK. OK.
Charlie's resolvers are validating, but they have not been upgraded Charlie's resolvers are validating, but they have not been upgraded
to support the KSK sentinel mechanism. Charlie will not be able to to support the KSK sentinel mechanism. Charlie will not be able to
fetch the http://invalid.example.com/1x1.gif resource (the fetch the http://bogus.example.com/1x1.gif resource (the
invalid.example.com record is bogus, and none of his resolvers will bogus.example.com record is bogus, and none of his resolvers will
resolve it). He is able to fetch both of the other resources - from resolve it). He is able to fetch both of the other resources - from
this he knows (see the logic in the body of this document) that he is this he knows (see the logic in the body of this document) that he is
using legacy, validating resolvers. The KSK sentinel method cannot using validating resolvers, but at least one of these resolvers is
provide him with a definitive answer to the question of what root not configured to perform sentinel processing. The KSK sentinel
trust anchors this resolver is using. method cannot provide him with a definitive answer to the question of
whether he will be impacted by the KSK roll.
Dave's resolvers implement the sentinel method, and have picked up Dave's resolvers implement the sentinel method, and have picked up
the new KSK. For the same reason as Charlie, he cannot fetch the the new KSK. For the same reason as Charlie, he cannot fetch the
"invalid" resource. His resolver resolves the root-key-sentinel-is- "bogus" resource. His resolver resolves the root-key-sentinel-is-ta-
ta-02323.example.com name normally (it contacts the example.com 02323.example.com name normally (it contacts the example.com
authoritative servers, etc); as it supports the sentinel mechanism, authoritative servers, etc); as it supports the sentinel mechanism,
just before Dave's recursive resolver sends the reply to Dave's stub, just before Dave's recursive resolver sends the reply to Dave's stub,
it performs the KSK Sentinel check. The QNAME starts with "root-key- it performs the KSK Sentinel check. The QNAME starts with "root-key-
sentinel-is-ta-", and the recursive resolver does indeed have a key sentinel-is-ta-", and the recursive resolver does indeed have a key
with the Key Tag of 02323 in its root trust store. This means that with the Key Tag of 02323 in its root trust store. This means that
that this part of the KSK Sentinel check passes (it is true that Key that this part of the KSK Sentinel check passes (it is true that Key
Tag 02323 is in the trust anchor store), and the recursive resolver Tag 02323 is in the trust anchor store), and the recursive resolver
replies normally (with the answer provided by the authoritative replies normally (with the answer provided by the authoritative
server). Dave's recursive resolver then resolves the root-key- server). Dave's recursive resolver then resolves the root-key-
sentinel-not-ta-02323.example.com name. Once again, it performs the sentinel-not-ta-11112.example.com name. Once again, it performs the
normal resolution process, but because it implements KSK Sentinel normal resolution process, but because it implements KSK Sentinel
(and the QNAME starts with "root-key-sentinel-not-ta-"), just before (and the QNAME starts with "root-key-sentinel-not-ta-"), just before
sending the reply, it performs the KSK Sentinel check. As it has sending the reply, it performs the KSK Sentinel check. As it has the
02323 in it's trust anchor store, the answer to "is this *not* a key with key-tag 11112 in it's trust anchor store, the answer to "is
trust anchor" is false, and so the recursive resolver does not reply this *not* a trust anchor" is false, and so the recursive resolver
with the answer from the authoritative server - instead, it replies does not reply with the answer from the authoritative server -
with a SERVFAIL (note that replying with SERVFAIL instead of the instead, it replies with a SERVFAIL (note that replying with SERVFAIL
original answer is the only mechanism that KSK Sentinel uses). This instead of the original answer is the only mechanism that KSK
means that Dave cannot fetch "invalid", he can fetch "root-key- Sentinel uses). This means that Dave cannot fetch "bogus", he can
sentinel-is-ta-02323", but he cannot fetch "root-key-sentinel-not-ta- fetch "root-key-sentinel-is-ta-02323", but he cannot fetch "root-key-
02323". From this, Dave knows that he is behind an upgraded, sentinel-not-ta-11112". From this, Dave knows that he is behind an
validating resolver, which has successfully installed the new, 02323 collection of resolvers that all validate, all have the key with key
KSK. tag 11112 loaded and at least one of these resolvers has loaded the
key with key-tag 02323 into its local trust anchor cache, Dave will
not be impacted by the KSK roll.
Just like Charlie and Dave, Ed cannot fetch the "invalid" record. Just like Charlie and Dave, Ed cannot fetch the "bogus" record. This
This tells him that his resolvers are validating. When his tells him that his resolvers are validating. When his (sentinel-
(upgraded) resolver performs the KSK Sentinel check for "root-key- aware) resolvers performs the KSK Sentinel check for "root-key-
sentinel-is-ta-02323", it does *not* have the (new, 02323) KSK in sentinel-is-ta-02323", none of them have loaded the new key with key-
it's trust anchor store. This means check fails, and Ed's recursive tag 02323 in their local trust anchor store. This means check fails,
resolver converts the (valid) answer into a SERVFAIL error response. and Ed's recursive resolver converts the (valid) answer into a
It performs the same check for root-key-sentinel-not-ta- SERVFAIL error response. It performs the same check for root-key-
02323.example.com; as it does not have the 02323 KSK, it is true that sentinel-not-ta-11112.example.com, and as all of Ed's resolvers both
this is not a trust anchor for it, and so it replies normally. This perform DNSSEC validation and recognise the sentinel label Ed will be
means that Ed cannot fetch the "invalid" resource, he also cannot unable to fetch the "root-key-sentinel-not-ta-11112" resource. This
fetch the "root-key-sentinel-is-ta-02323" resource, but he can fetch tells Ed that his resolvers have not installed the new KSK and he
the "root-key-sentinel-not-ta-02323" resource. This tells Ed that will be negatively implacted by the KSK roll..
his resolvers have not installed the new KSK.
Geoff would like to do a large scale test and provide the information Geoff would like to do a large scale test and provide the information
back to Alice. He uses some mechanism such as causing users to go to back to Alice. He uses some mechanism such as causing users to go to
a web page to cause a large number of users to attempt to resolve the a web page to cause a large number of users to attempt to resolve the
three resources, and then analyzes the results of the tests to three resources, and then analyzes the results of the tests to
determine what percentage of users will be affected by the KSK determine what percentage of users will be affected by the KSK
rollover event. rollover event.
This description is a simplified example - it is not anticipated that This description is a simplified example - it is not anticipated that
Bob, Charlie, Dave and Ed will actually look for the absence or Bob, Charlie, Dave and Ed will actually look for the absence or
 End of changes. 67 change blocks. 
211 lines changed or deleted 362 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/