< draft-ietf-dnsop-kskroll-sentinel-01.txt   draft-ietf-dnsop-kskroll-sentinel-02.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: August 16, 2018 W. Kumari Expires: August 25, 2018 W. Kumari
Google Google
February 12, 2018 February 21, 2018
A Sentinel for Detecting Trusted Keys in DNSSEC A Sentinel for Detecting Trusted Keys in DNSSEC
draft-ietf-dnsop-kskroll-sentinel-01 draft-ietf-dnsop-kskroll-sentinel-02
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 to determine the trusted key state of the will allow an end user to determine the trusted key state for the
resolvers that handle that user's DNS queries. root key of the resolvers that handle that user's DNS queries. Note
that this method is only applicable for determing which keys are in
the trust store for the root key.
There is an example / toy implementation of this at http://www.ksk- There is an example / toy implementation of this at http://www.ksk-
test.net . 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. Text
in square brackets will be removed before publication. ] in square brackets will be removed before publication. ]
[ NOTE: This version uses the labels "kskroll-sentinel-is-ta-<tag- [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-<tag-
index>", "kskroll-sentinel-not-ta-<tag-index>"; older versions of index>", "kskroll-sentinel-not-ta-<tag-index>"; older versions of
this document used "_is-ta-<tag-index>", "_not-ta-<tag-index>". ] this document used "_is-ta-<tag-index>", "_not-ta-<tag-index>". ]
Status of This Memo Status of This Memo
skipping to change at page 2, line 4 skipping to change at page 2, line 6
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 16, 2018.
This Internet-Draft will expire on August 25, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 30 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Sentinel Mechanism . . . . . . . . . . . . . . . . . . . . . 6 3. Sentinel Mechanism . . . . . . . . . . . . . . . . . . . . . 6
4. Sentinel Processing . . . . . . . . . . . . . . . . . . . . . 7 4. Sentinel Processing . . . . . . . . . . . . . . . . . . . . . 7
5. Sentinel Test Result Considerations . . . . . . . . . . . . . 9 5. Sentinel Test Result Considerations . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 not unlike a from the RDATA portion of a DNSKEY RR using a formula not unlike a
ones-complement checksum. RRSIG RRs contain a Key Tag field whose ones-complement checksum. RRSIG RRs contain a Key Tag field whose
value is equal to the Key Tag of the DNSKEY RR that validates the value 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 validating resolvers can respond to
certain queries in a manner that allows a querier to deduce whether a certain queries in a manner that allows a querier to deduce whether a
particular key has been loaded into that resolver's trusted key particular key for the root has been loaded into that resolver's
store. In particular, this response mechanism can be used to trusted key store. In particular, this response mechanism can be
determine whether a certain Root Zone KSK is ready to be used as a used to determine whether a certain Root Zone KSK is ready to be used
trusted key within the context of a key roll by this resolver. as a trusted key within the context of a key roll by this resolver.
This new mechanism is OPTIONAL to implement and use, although for This new mechanism is OPTIONAL to implement and use, although for
reasons of supporting broad-based measurement techniques, it is reasons of supporting broad-based measurement techniques, it is
strongly preferred if configurations of DNSSEC-validating resolvers strongly preferred if 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.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Address Record: Throughout this document we use the term Address Note that example.com, AAAA records and the IPv6 documentation prefix
Record (AR) to mean an A or AAAA record. We are using example.com, (2001:db8::/32) are only examples - A records (or CNAMES), other IPs,
AAAA records and the IPv6 documentation prefix (2001:DB8::/32) as other domains work just as well.
examples; these are only examples - A records (or CNAMES), other IPs,
other domains work just as well. [Ed note: There was some earlier
confusion on this, being explicit! ]
2. Use Case 2. Use Case
[Ed note: This is currently towards the front of the document; we [Ed note: This is currently towards the front of the document; we
will make it an appendix at publication time, but until then it is will make it an appendix at publication time, but until then it is
worth having up front, as it makes the rest of the document much worth having up front, as it makes the rest of the document much
easier to understand ] easier to understand ]
This section provides a non-normative example of how the sentinel This section 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
skipping to change at page 4, line 15 skipping to change at page 4, line 13
2222 KSK in its trust store yet. 2222 KSK in its trust store yet.
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 3 AAAA records to example.com: webserver (www.example.com). He adds 3 AAAA records to example.com:
invalid IN AAAA 2001:DB8::1 invalid.example.com. IN AAAA 2001:db8::1
kskroll-sentinel-is-ta-2222 IN AAAA 2001:DB8::1 kskroll-sentinel-is-ta-2222.example.com. IN AAAA 2001:db8::1
kskroll-sentinel-not-ta-2222 IN AAAA 2001:DB8::1 kskroll-sentinel-not-ta-2222.example.com. IN AAAA 2001:db8::1
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 invalid.example.com record invalid/bogus (for example, by editing
the signed zone and entering garbage for the signature). Geoff also the signed zone and entering garbage for the signature). Geoff also
configures his webserver to listen on 2001:DB8::1 and serve a configures his webserver to listen on 2001:db8::1 and serve a
resource (for example, a 1x1 GIF, 1x1.gif) for all of these names. resource (for example, a 1x1 GIF, 1x1.gif) for all of these names.
The webserver also serves a webpage (www.example.com) which contains The webserver also serves a webpage (www.example.com) which contains
links to these 3 resources (http://invalid.example.com/1x1.gif, links to these 3 resources (http://invalid.example.com/1x1.gif,
http://kskroll-sentinel-is-ta-2222.example.com/1x1.gif, http://kskroll-sentinel-is-ta-2222.example.com/1x1.gif,
http://kskroll-sentinel-not-ta-2222.example.com/1x1.gif). http://kskroll-sentinel-not-ta-2222.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 1111 KSK is users can figure out what their fate will be when the 1111 KSK is
removed. removed.
skipping to change at page 4, line 46 skipping to change at page 4, line 44
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 invalid.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://invalid.example.com/1x1.gif resource (the
invalid.example.com record is bogus, and none of his resolvers will invalid.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 below) that he is using legacy, non- this he knows (see the logic below) that he is using legacy,
validating resolvers. The KSK sentinel method cannot provided him validating resolvers. The KSK sentinel method cannot provided him
with a definitive answer. with a definitive answer.
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 kskroll-sentinel-is- "invalid" resource. His resolver resolves the kskroll-sentinel-is-
ta-2222.example.com name normally (it contacts the example.com ta-2222.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 server send the reply to Dave's stub, it just before Dave's recursive server send the reply to Dave's stub, it
performs the KSK Sentinel check (see below). The QNAME starts with performs the KSK Sentinel check (see below). The QNAME starts with
skipping to change at page 5, line 35 skipping to change at page 5, line 32
ta-2222", but he cannot fetch "kskroll-sentinel-not-ta-2222". From ta-2222", but he cannot fetch "kskroll-sentinel-not-ta-2222". From
this, Dave knows that he is behind an upgraded, validating resolver, this, Dave knows that he is behind an upgraded, validating resolver,
which has successfully installed the new, 2222 KSK. Dave has nothing which has successfully installed the new, 2222 KSK. Dave has nothing
to worry about - he will be fine with the old (1111) KSK is removed. to worry about - he will be fine with the old (1111) KSK is removed.
Now for Ed. Just like Charlie and Dave, Ed cannot fetch the Now for Ed. Just like Charlie and Dave, Ed cannot fetch the
"invalid" record. This tells him that his resolvers are validating. "invalid" record. This tells him that his resolvers are validating.
When his (upgraded) resolver performs the KSK Sentinel check for When his (upgraded) resolver performs the KSK Sentinel check for
"kskroll-sentinel-is-ta-2222", it does *not* have the (new, 2222) KSK "kskroll-sentinel-is-ta-2222", it does *not* have the (new, 2222) KSK
in it's trust anchor store. This means check fails, and Ed's in it's trust anchor store. This means check fails, and Ed's
recursive resolver converts the (valid) 2001:DB8::1 answer into a recursive resolver converts the (valid) 2001:db8::1 answer into a
SERVFAIL error response. It performs the same check for kskroll- SERVFAIL error response. It performs the same check for kskroll-
sentinel-not-ta-2222.example.com; as it does not have the 2222 KSK, sentinel-not-ta-2222.example.com; as it does not have the 2222 KSK,
it is true that this is not a trust anchor for it, and so it replies it is true that this is not a trust anchor for it, and so it replies
normally. This means that Ed cannot fetch the "invalid" resource, he normally. This means that Ed cannot fetch the "invalid" resource, he
also cannot fetch the "kskroll-sentinel-is-ta-2222" resource, but he also cannot fetch the "kskroll-sentinel-is-ta-2222" resource, but he
can fetch the "kskroll-sentinel-not-ta-2222" resource. This tells Ed can fetch the "kskroll-sentinel-not-ta-2222" resource. This tells Ed
that his resolvers have not installed the new KSK, and, when the old that his resolvers have not installed the new KSK, and, when the old
KSK is removed, his DNS will break. KSK is removed, his DNS will break.
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
skipping to change at page 6, line 36 skipping to change at page 6, line 31
This sentinel mechanism makes use of 2 special labels, "kskroll- This sentinel mechanism makes use of 2 special labels, "kskroll-
sentinel-is-ta-<tag-index>." (intended to be used in a query where sentinel-is-ta-<tag-index>." (intended to be used in a query where
the response can answer the question: Is this the key tag a trust the response can answer the question: Is this the key tag a trust
anchor which the validating DNS resolver is currently trusting?) and anchor which the validating DNS resolver is currently trusting?) and
"kskroll-sentinel-not-ta-<tag-index>." (intended to be used in a "kskroll-sentinel-not-ta-<tag-index>." (intended to be used in a
query where the response can answer the question: Is this the key tag query where the response can answer the question: Is this the key tag
of a key that is NOT in the resolver's current trust store?). The of a key that is NOT in the resolver's current trust store?). The
use of the positive question and its inverse allows for queries to use of the positive question and its inverse allows for queries to
detect whether resolvers support this sentinel mechanism. Note that detect whether resolvers support this sentinel mechanism. Note that
the test is "Is there a key with this KeyID in the resolver's current the test is "Is there an active key with this KeyID in the resolver's
trust store for the DNS root", not "Is there any key with this KeyID current trust store for the DNS root?", not "Is there any key with
in the trust store", nor "Was a key with this KeyID used to validate this KeyID in the trust store", nor "Was a key with this KeyID used
this query?". [This is still an active discussion on the DNSOP list to validate this query?". An active key is one which could currently
] be used for validation (ie not in AddPend or Revoked state
([RFC5011])).
If the outcome of the DNSSEC validation process on the response RRset If the outcome of the DNSSEC validation process on the response
indicates that the response RRset is authentic, and if the left-most indicates that the response is authentic, and if the left-most label
label of the original query name matches the template "kskroll- of the original query name matches the template "kskroll-sentinel-is-
sentinel-is-ta-<tag-index>.", then the following rule should be ta-<tag-index>.", then the following rule should be applied to the
applied to the response: If the resolver has placed a Root Zone Key response: If the resolver has placed a Root Zone Key Signing Key with
Signing Key with tag index value matching the value specified in the tag index value matching the value specified in the query into the
query into the local resolver's store of trusted keys, then the local resolver's store of trusted keys, then the resolver should
return a response indicating that the response contains authenticated
data according to section 5.8 of [RFC6840]. Otherwise, the resolver
MUST return RCODE 2 (server failure). Note that the <tag-index> is
specified in the DNS label using hexadecimal notation.
If the outcome of the DNSSEC validation process applied to the
response indicates that the response is authentic, and if the left-
most label of the original query name matches the template "kskroll-
sentinel-not-ta-<tag-index>.", then the following rule should be
applied to the response: If the resolver has not placed a Root Zone
Key Signing Key with tag index value matching the value specified in
the query into the local resolver's store of trusted keys, then the
resolver should return a response indicating that the response resolver should return a response indicating that the response
contains authenticated data according to section 5.8 of [RFC6840]. contains authenticated data according to section 5.8 of [RFC6840].
Otherwise, the resolver MUST return RCODE 2 (server failure). Note Otherwise, the resolver MUST return RCODE 2 (server failure). Note
that the <tag-index> is specified in the DNS label using hexadecimal that the <tag-index> is specified in the DNS label using hexadecimal
notation. notation.
If the outcome of the DNSSEC validation process applied to the
response RRset indicates that the response RRset is authentic, and if
the left-most label of the original query name matches the template
"kskroll-sentinel-not-ta-<tag-index>.", then the following rule
should be applied to the response: If the resolver has not placed a
Root Zone Key Signing Key with tag index value matching the value
specified in the query into the local resolver's store of trusted
keys, then the resolver should return a response indicating that the
response contains authenticated data according to section 5.8 of
[RFC6840]. Otherwise, the resolver MUST return RCODE 2 (server
failure). Note that the <tag-index> is specified in the DNS label
using hexadecimal notation.
In all other cases the resolver MUST NOT alter the outcome of the DNS In all other cases the resolver MUST NOT alter the outcome of the DNS
response validation process. response validation process.
This mechanism is to be applied only by resolvers that are performing This mechanism is to be applied only by resolvers that are performing
DNSSEC validation, and applies only to RRset responses to an A or DNSSEC validation, and applies only to responses to an A or AAAA
AAAA query (Query Type value 1 or 28) where the resolver has query (Query Type value 1 or 28) where the resolver has authenticated
authenticated the response RRset according to the DNSSEC validation the response according to the DNSSEC validation process and where the
process and where the query name contains either of the labels query name contains either of the labels described in this section as
described in this section as its left-most label. In this case, the its left-most label. In this case, the resolver is to perform an
resolver is to perform an additional test following the conventional additional test following the conventional validation function, as
validation function, as described in this section. The result of described in this section. The result of this additional test
this additional test determines whether the resolver will alter its determines whether the resolver will alter its response that would
response that would have indicated that the RRset is authentic to a have indicated that the RRset is authentic to a response that
response that indicates DNSSEC validation failure via the use of indicates DNSSEC validation failure via the use of RCODE 2.
RCODE 2.
4. Sentinel Processing 4. Sentinel Processing
This proposed test that uses the sentinel detection mechanism This proposed test that uses the sentinel detection mechanism
described in this document is based on the use of three DNS names described in this document is based on the use of three DNS names
that have three distinct DNS resolution behaviours. The test is that have three distinct DNS resolution behaviours. The test is
intended to allow a user to determine the state of their DNS intended to allow a user to determine the state of their DNS
resolution system, and, in particular, whether or not they are using resolution system, and, in particular, whether or not they are using
validating DNS resolvers that have picked up an incoming trust anchor validating DNS resolvers that have picked up an incoming trust anchor
as a trusted key in a root zone KSK roll scenario. as a trusted key in a root zone KSK roll scenario.
skipping to change at page 8, line 24 skipping to change at page 8, line 17
b. a query name containing the left-most label "kskroll-sentinel- b. a query name containing the left-most label "kskroll-sentinel-
not-ta-<tag-index>.". This is also a validly-signed name. Any not-ta-<tag-index>.". 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.
c. a third query name that is signed with a DNSSEC signature that c. a third query name that is signed with a DNSSEC signature that
cannot be validated (i.e. the corresponding RRset is not signed cannot be validated (i.e. the corresponding RRset is not signed
with a valid RRSIG record). with a valid RRSIG 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 would allow us to infer a trust key state of the resolution
environment. To describe this process of classification, we can environment. The techniques describes in this document rely on
(DNSSEC validating) resolvers responding with SERVFAIL (RCODE 2) to
valid answers. Note that a slew of other issues can also cause
SERVFAIL responses, so false positive or negative results may
sometimes occur. To describe this process of classification, we can
classify resolvers into four distinct behavior types, for which we classify resolvers into four distinct behavior types, for which we
will use the labels: "Vnew", "Vold", "Vleg", and "nonV". These will use the labels: "Vnew", "Vold", "Vleg", and "nonV". These
labels correspond to resolver behaviour types as follows: labels correspond to resolver behaviour types as follows:
o Vnew: A DNSSEC-Validating resolver that is configured to implement o Vnew: A DNSSEC-Validating resolver that is configured to implement
this mechanism has loaded the nominated key into its local trusted this mechanism has loaded the nominated key into its local trusted
key store will respond with an A or AAAA RRset response for key store will respond with an A or AAAA RRset response for
"kskroll-sentinel-is-ta" queries, SERVFAIL for "kskroll-sentinel- "kskroll-sentinel-is-ta" queries, SERVFAIL for "kskroll-sentinel-
not-ta" queries and SERVFAIL for the invalidly signed name not-ta" queries and SERVFAIL for the invalidly signed name
queries. queries.
o Vold: A DNSSEC-Validating resolver that is configured to implement o Vold: A DNSSEC-Validating resolver that is configured to implement
this mechanism that has not loaded the nominated key into its this mechanism that has not loaded the nominated key into its
local trusted key store will respond with an SERVFAIL for local trusted key store will respond with an SERVFAIL for
"kskroll-sentinel-is-ta" queries, an A or AAAA RRset response for "kskroll-sentinel-is-ta" queries, an A or AAAA RRset response for
"kskroll-sentinel-not-ta" queries and SERVFAIL for the invalidly "kskroll-sentinel-not-ta" queries and SERVFAIL for the invalidly
signed name queries. signed name queries.
o Vleg: A DNSSEC-Validating resolver that does not implement this o Vleg: A DNSSEC-Validating resolver that does not implement this
mechanism will respond with an A or AAAA RRSET response for mechanism will respond with an A or AAAA RRset response for
"kskroll-sentinel-is-ta", an A record response for "kskroll- "kskroll-sentinel-is-ta", an A record response for "kskroll-
sentinel-not-ta" and SERVFAIL for the invalid name. sentinel-not-ta" and SERVFAIL for the invalid name.
o nonV: A non-DNSSEC-Validating resolver will respond with an A o nonV: A non-DNSSEC-Validating resolver will respond with an A or
record response for "kskroll-sentinel-is-ta", an A record response AAAA record response for "kskroll-sentinel-is-ta", an A record
for "kskroll-sentinel-not-ta" and an A record response for the response for "kskroll-sentinel-not-ta" and an A record response
invalid name. for the invalid name.
Given the clear delineation amongst these three cases, if a client Given the clear delineation amongst these three cases, if a client
directs these three queries to a simple resolver, the variation in directs these three queries to a simple resolver, the variation in
response to the three queries should allow the client to determine response to the three queries should allow the client to determine
the category of the resolver, and if it supports this mechanism, the category of the resolver, and if it supports this mechanism,
whether or not it has loaded a particular key into its local trusted whether or not it has loaded a particular key into its local trusted
key stash. key stash.
+-------------+----------+-----------+------------+ +-------------+----------+-----------+------------+
| Type\Query | is-ta | not-ta | invalid | | Type\Query | is-ta | not-ta | invalid |
skipping to change at page 11, line 21 skipping to change at page 11, line 16
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 Key Signing Key of the Root Zone of the progress of a roll of the Key Signing Key of the Root Zone of the
DNS. DNS.
The authors would like the especially thank Joe Abley, Mehmet Akcin, The authors would like the especially thank Joe Abley, Mehmet Akcin,
Mark Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David Mark Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David
Conrad, Ralph Dolmans, Steinar Haug, Bob Harold, Wes Hardaker, Paul Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes
Hoffman, Matt Larson, Edward Lewis, George Michaelson, Benno Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis,
Overeinder, Matthew Pounsett, Andreas Schulze, Mukund Sivaraman, Petr George Michaelson, Benno Overeinder, Matthew Pounsett, Andreas
Spacek. Andrew Sullivan, Paul Vixie, Duane Wessels and Paul Wouters Schulze, Mukund Sivaraman, Petr Spacek. Andrew Sullivan, Paul Vixie,
for their helpful feedback. Duane Wessels and Paul Wouters for their helpful feedback.
[TODO: Add people who have contributed!] [TODO: Add people who have contributed!]
9. Change Log 9. Change Log
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 -01 to 02:
Removed Address Record definition.
Clarified that many things can cause SERVFAIL.
Made examples FQDN.
Fixed a number of typos.
Had accidentally said that Charlie was using a non-validating
resolver in example.
[ TODO(WK): Doc says keytags are hex, is this really what the WG
wants? ]
And active key is one that can be used *now* (not e.g AddPend)
From -00 to 01: From -00 to 01:
o Added a conversational description of how the system is intended o Added a conversational description of how the system is intended
to work. to work.
o Clarification that this is for the root. o Clarification that this is for the root.
o Changed the label template from _is-ta-<tag> to kskroll-sentinel- o Changed the label template from _is-ta-<tag> to kskroll-sentinel-
is-ta-<tag-index>. This is because BIND (at least) will not allow is-ta-<tag-index>. This is because BIND (at least) will not allow
records which start with an underscore to have address records records which start with an underscore to have address records
skipping to change at page 12, line 4 skipping to change at page 12, line 13
o Clarification that this is for the root. o Clarification that this is for the root.
o Changed the label template from _is-ta-<tag> to kskroll-sentinel- o Changed the label template from _is-ta-<tag> to kskroll-sentinel-
is-ta-<tag-index>. This is because BIND (at least) will not allow is-ta-<tag-index>. This is because BIND (at least) will not allow
records which start with an underscore to have address records records which start with an underscore to have address records
(CNAMEs, yes, A/AAAA no). Some browsers / operating systems also (CNAMEs, yes, A/AAAA no). Some browsers / operating systems also
will not fetch resources from names which start with an will not fetch resources from names which start with an
underscore. underscore.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc- 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-
editor.org/info/rfc4033>. editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840, Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013, <https://www.rfc- DOI 10.17487/RFC6840, February 2013, <https://www.rfc-
editor.org/info/rfc6840>. editor.org/info/rfc6840>.
10.2. Informative References 10.2. Informative References
[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)", RFC Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC
8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc- 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-
 End of changes. 27 change blocks. 
72 lines changed or deleted 98 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/