A security-aware resolver’s support for signature verification MUST
include support for verification of wildcard owner names.
Security-aware resolvers MAY query for missing security RRs in an
attempt to perform validation; implementations that choose to do so
must be aware that the answers received may not be sufficient to
validate the original response. For example, a zone update may have
changed (or deleted) the desired information between the original and
follow-up queries.
When attempting to retrieve missing NSEC RRs that reside on the
parental side at a zone cut, a security-aware iterative-mode resolver
MUST query the name servers for the parent zone, not the child zone.
When attempting to retrieve a missing DS, a security-aware
iterative-mode resolver MUST query the name servers for the parent
zone, not the child zone. As explained in Section 3.1.4.1,
security-aware name servers need to apply special processing rules to
handle the DS RR, and in some situations the resolver may also need
to apply special rules to locate the name servers for the parent zone
if the resolver does not already have the parent’s NS RRset. To
locate the parent NS RRset, the resolver can start with the
delegation name, strip off the leftmost label, and query for an NS
RRset by that name. If no NS RRset is present at that name, the
resolver then strips off the leftmost remaining label and retries the
query for that name, repeating this process of walking up the tree
until it either finds the NS RRset or runs out of labels.
4.3. Determining Security Status of Data
A security-aware resolver MUST be able to determine whether it should
expect a particular RRset to be signed. More precisely, a
security-aware resolver must be able to distinguish between four
cases:
Secure: An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed and is subject to
signature validation, as described above.
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
Bogus: An RRset for which the resolver believes that it ought to be
able to establish a chain of trust but for which it is unable to
do so, either due to signatures that for some reason fail to
validate or due to missing data that the relevant DNSSEC RRs
indicate should be present. This case may indicate an attack but
may also indicate a configuration error or some form of data
corruption.
Indeterminate: An RRset for which the resolver is not able to
determine whether the RRset should be signed, as the resolver is
not able to obtain the necessary DNSSEC RRs. This can occur when
the security-aware resolver is not able to contact security-aware
name servers for the relevant zones.
4.4. Configured Trust Anchors
A security-aware resolver MUST be capable of being configured with at
least one trusted public key or DS RR and SHOULD be capable of being
configured with multiple trusted public keys or DS RRs. Since a
security-aware resolver will not be able to validate signatures
without such a configured trust anchor, the resolver SHOULD have some
reasonably robust mechanism for obtaining such keys when it boots;
examples of such a mechanism would be some form of non-volatile
storage (such as a disk drive) or some form of trusted local network
configuration mechanism.
Note that trust anchors also cover key material that is updated in a
secure manner. This secure manner could be through physical media, a
key exchange protocol, or some other out-of-band means.
4.5. Response Caching
A security-aware resolver SHOULD cache each response as a single
atomic entry containing the entire answer, including the named RRset
and any associated DNSSEC RRs. The resolver SHOULD discard the
entire atomic entry when any of the RRs contained in it expire. In
most cases the appropriate cache index for the atomic entry will be
the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
form described in Section 3.1.3.2 the appropriate cache index will be
the double <QNAME,QCLASS>.
The reason for these recommendations is that, between the initial
query and the expiration of the data from the cache, the
authoritative data might have been changed (for example, via dynamic
update).
There are two situations for which this is relevant:
1. By using the RRSIG record, it is possible to deduce that an
answer was synthesized from a wildcard. A security-aware
recursive name server could store this wildcard data and use it
to generate positive responses to queries other than the name for
which the original answer was first received.
2. NSEC RRs received to prove the non-existence of a name could be
reused by a security-aware resolver to prove the non-existence of
any name in the name range it spans.
In theory, a resolver could use wildcards or NSEC RRs to generate
positive and negative responses (respectively) until the TTL or
signatures on the records in question expire. However, it seems
prudent for resolvers to avoid blocking new authoritative data or
synthesizing new data on their own. Resolvers that follow this
recommendation will have a more consistent view of the namespace.
4.6. Handling of the CD and AD Bits
A security-aware resolver MAY set a query’s CD bit in order to
indicate that the resolver takes responsibility for performing
whatever authentication its local policy requires on the RRsets in
the response. See Section 3.2 for the effect this bit has on the
behavior of security-aware recursive name servers.
A security-aware resolver MUST clear the AD bit when composing query
messages to protect against buggy name servers that blindly copy
header bits that they do not understand from the query message to the
response message.
A resolver MUST disregard the meaning of the CD and AD bits in a
response unless the response was obtained by using a secure channel
or the resolver was specifically configured to regard the message
header bits without using a secure channel.
4.7. Caching BAD Data
While many validation errors will be transient, some are likely to be
more persistent, such as those caused by administrative error
(failure to re-sign a zone, clock skew, and so forth). Since
requerying will not help in these cases, validating resolvers might
generate a significant amount of unnecessary DNS traffic as a result
of repeated queries for RRsets with persistent validation failures.
To prevent such unnecessary DNS traffic, security-aware resolvers MAY
cache data with invalid signatures, with some restrictions.
Conceptually, caching such data is similar to negative caching
([RFC2308]), except that instead of caching a valid negative
response, the resolver is caching the fact that a particular answer
failed to validate. This document refers to a cache of data with
invalid signatures as a "BAD cache".
Resolvers that implement a BAD cache MUST take steps to prevent the
cache from being useful as a denial-of-service attack amplifier,
particularly the following:
o Since RRsets that fail to validate do not have trustworthy TTLs,
the implementation MUST assign a TTL. This TTL SHOULD be small,
in order to mitigate the effect of caching the results of an
attack.
o In order to prevent caching of a transient validation failure
(which might be the result of an attack), resolvers SHOULD track
queries that result in validation failures and SHOULD only answer
from the BAD cache after the number of times that responses to
queries for that particular <QNAME, QTYPE, QCLASS> have failed to
validate exceeds a threshold value.
Resolvers MUST NOT return RRsets from the BAD cache unless the
resolver is not required to validate the signatures of the RRsets in
question under the rules given in Section 4.2 of this document. See
Section 3.2.2 for discussion of how the responses returned by a
security-aware recursive name server interact with a BAD cache.
4.8. Synthesized CNAMEs
A validating security-aware resolver MUST treat the signature of a
valid signed DNAME RR as also covering unsigned CNAME RRs that could
have been synthesized from the DNAME RR, as described in [RFC2672],
at least to the extent of not rejecting a response message solely
because it contains such CNAME RRs. The resolver MAY retain such
CNAME RRs in its cache or in the answers it hands back, but is not
required to do so.
4.9. Stub Resolvers
A security-aware stub resolver MUST support the DNSSEC RR types, at
least to the extent of not mishandling responses just because they
contain DNSSEC RRs.
4.9.1. Handling of the DO Bit
A non-validating security-aware stub resolver MAY include the DNSSEC
RRs returned by a security-aware recursive name server as part of the
data that the stub resolver hands back to the application that
invoked it, but is not required to do so. A non-validating stub
resolver that seeks to do this will need to set the DO bit in order
to receive DNSSEC RRs from the recursive name server.
A validating security-aware stub resolver MUST set the DO bit,
because otherwise it will not receive the DNSSEC RRs it needs to
perform signature validation.
4.9.2. Handling of the CD Bit
A non-validating security-aware stub resolver SHOULD NOT set the CD
bit when sending queries unless it is requested by the application
layer, as by definition, a non-validating stub resolver depends on
the security-aware recursive name server to perform validation on its
behalf.
A validating security-aware stub resolver SHOULD set the CD bit,
because otherwise the security-aware recursive name server will
answer the query using the name server’s local policy, which may
prevent the stub resolver from receiving data that would be
acceptable to the stub resolver’s local policy.
4.9.3. Handling of the AD Bit
A non-validating security-aware stub resolver MAY chose to examine
the setting of the AD bit in response messages that it receives in
order to determine whether the security-aware recursive name server
that sent the response claims to have cryptographically verified the
data in the Answer and Authority sections of the response message.
Note, however, that the responses received by a security-aware stub
resolver are heavily dependent on the local policy of the
security-aware recursive name server. Therefore, there may be little
practical value in checking the status of the AD bit, except perhaps
as a debugging aid. In any case, a security-aware stub resolver MUST
NOT place any reliance on signature validation allegedly performed on
its behalf, except when the security-aware stub resolver obtained the
data in question from a trusted security-aware recursive name server
via a secure channel.
A validating security-aware stub resolver SHOULD NOT examine the
setting of the AD bit in response messages, as, by definition, the
stub resolver performs its own signature validation regardless of the
setting of the AD bit.
5. Authenticating DNS Responses
To use DNSSEC RRs for authentication, a security-aware resolver
requires configured knowledge of at least one authenticated DNSKEY or
DS RR. The process for obtaining and authenticating this initial
trust anchor is achieved via some external mechanism. For example, a
resolver could use some off-line authenticated exchange to obtain a
zone’s DNSKEY RR or to obtain a DS RR that identifies and
authenticates a zone’s DNSKEY RR. The remainder of this section
assumes that the resolver has somehow obtained an initial set of
trust anchors.
An initial DNSKEY RR can be used to authenticate a zone’s apex DNSKEY
RRset. To authenticate an apex DNSKEY RRset by using an initial key,
the resolver MUST:
1. verify that the initial DNSKEY RR appears in the apex DNSKEY
RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
bit 7) set; and
2. verify that there is some RRSIG RR that covers the apex DNSKEY
RRset, and that the combination of the RRSIG RR and the initial
DNSKEY RR authenticates the DNSKEY RRset. The process for using
an RRSIG RR to authenticate an RRset is described in Section 5.3.
Once the resolver has authenticated the apex DNSKEY RRset by using an
initial DNSKEY RR, delegations from that zone can be authenticated by
using DS RRs. This allows a resolver to start from an initial key
and use DS RRsets to proceed recursively down the DNS tree, obtaining
other apex DNSKEY RRsets. If the resolver were configured with a
root DNSKEY RR, and if every delegation had a DS RR associated with
it, then the resolver could obtain and validate any apex DNSKEY
RRset. The process of using DS RRs to authenticate referrals is
described in Section 5.2.
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
RRsets in the zone once the resolver has authenticated a zone’s apex
DNSKEY RRset. Section 5.4 shows how the resolver can use
authenticated NSEC RRsets from the zone to prove that an RRset is not
present in the zone.
When a resolver indicates support for DNSSEC (by setting the DO bit),
a security-aware name server should attempt to provide the necessary
DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
However, a security-aware resolver may still receive a response that
lacks the appropriate DNSSEC RRs, whether due to configuration issues
such as an upstream security-oblivious recursive name server that
accidentally interferes with DNSSEC RRs or due to a deliberate attack
in which an adversary forges a response, strips DNSSEC RRs from a
response, or modifies a query so that DNSSEC RRs appear not to be
requested. The absence of DNSSEC data in a response MUST NOT by
itself be taken as an indication that no authentication information
exists.
A resolver SHOULD expect authentication information from signed
zones. A resolver SHOULD believe that a zone is signed if the
resolver has been configured with public key information for the
zone, or if the zone’s parent is signed and the delegation from the
parent contains a DS RRset.
5.1. Special Considerations for Islands of Security
Islands of security (see [RFC4033]) are signed zones for which it is
not possible to construct an authentication chain to the zone from
its parent. Validating signatures within an island of security
requires that the validator have some other means of obtaining an
initial authenticated zone key for the island. If a validator cannot
obtain such a key, it SHOULD switch to operating as if the zones in
the island of security are unsigned.
All the normal processes for validating responses apply to islands of
security. The only difference between normal validation and
validation within an island of security is in how the validator
obtains a trust anchor for the authentication chain.
5.2. Authenticating Referrals
Once the apex DNSKEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate the delegation
to a signed child zone. A DS RR identifies a DNSKEY RR in the child
zone’s apex DNSKEY RRset and contains a cryptographic digest of the
child zone’s DNSKEY RR. Use of a strong cryptographic digest
algorithm ensures that it is computationally infeasible for an
adversary to generate a DNSKEY RR that matches the digest. Thus,
authenticating the digest allows a resolver to authenticate the
matching DNSKEY RR. The resolver can then use this child DNSKEY RR
to authenticate the entire child apex DNSKEY RRset.
Given a DS RR for a delegation, the child zone’s apex DNSKEY RRset
can be authenticated if all of the following hold:
o The DS RR has been authenticated using some DNSKEY RR in the
parent’s apex DNSKEY RRset (see Section 5.3).
o The Algorithm and Key Tag in the DS RR match the Algorithm field
and the key tag of a DNSKEY RR in the child zone’s apex DNSKEY
RRset, and, when the DNSKEY RR’s owner name and RDATA are hashed
using the digest algorithm specified in the DS RR’s Digest Type
field, the resulting digest value matches the Digest field of the
DS RR.
o The matching DNSKEY RR in the child zone has the Zone Flag bit
set, the corresponding private key has signed the child zone’s
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
child zone’s apex DNSKEY RRset.
If the referral from the parent zone did not contain a DS RRset, the
response should have included a signed NSEC RRset proving that no DS
RRset exists for the delegated name (see Section 3.1.4). A
security-aware resolver MUST query the name servers for the parent
zone for the DS RRset if the referral includes neither a DS RRset nor
a NSEC RRset proving that the DS RRset does not exist (see Section
4).
If the validator authenticates an NSEC RRset that proves that no DS
RRset is present for this zone, then there is no authentication path
leading from the parent to the child. If the resolver has an initial
DNSKEY or DS RR that belongs to the child zone or to any delegation
below the child zone, this initial DNSKEY or DS RR MAY be used to
re-establish an authentication path. If no such initial DNSKEY or DS
RR exists, the validator cannot authenticate RRsets in or below the
child zone.
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
Note that, for a signed delegation, there are two NSEC RRs associated
with the delegated name. One NSEC RR resides in the parent zone and
can be used to prove whether a DS RRset exists for the delegated
name. The second NSEC RR resides in the child zone and identifies
which RRsets are present at the apex of the child zone. The parent
NSEC RR and child NSEC RR can always be distinguished because the SOA
bit will be set in the child NSEC RR and clear in the parent NSEC RR.
A security-aware resolver MUST use the parent NSEC RR when attempting
to prove that a DS RRset does not exist.
If the resolver does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver will not be able to verify
the authentication path to the child zone. In this case, the
resolver SHOULD treat the child zone as if it were unsigned.
5.3. Authenticating an RRset with an RRSIG RR
A validator can use an RRSIG RR and its corresponding DNSKEY RR to
attempt to authenticate RRsets. The validator first checks the RRSIG
RR to verify that it covers the RRset, has a valid time interval, and
identifies a valid DNSKEY RR. The validator then constructs the
canonical form of the signed data by appending the RRSIG RDATA
(excluding the Signature Field) with the canonical form of the
covered RRset. Finally, the validator uses the public key and
signature to authenticate the signed data. Sections 5.3.1, 5.3.2,
and 5.3.3 describe each step in detail.
5.3.1. Checking the RRSIG RR Validity
A security-aware resolver can use an RRSIG RR to authenticate an
RRset if all of the following conditions hold:
o The RRSIG RR and the RRset MUST have the same owner name and the
same class.
o The RRSIG RR’s Signer’s Name field MUST be the name of the zone
that contains the RRset.
o The RRSIG RR’s Type Covered field MUST equal the RRset’s type.
o The number of labels in the RRset owner name MUST be greater than
or equal to the value in the RRSIG RR’s Labels field.
o The validator’s notion of the current time MUST be less than or
equal to the time listed in the RRSIG RR’s Expiration field.
o The validator’s notion of the current time MUST be greater than or
equal to the time listed in the RRSIG RR’s Inception field.
o The RRSIG RR’s Signer’s Name, Algorithm, and Key Tag fields MUST
match the owner name, algorithm, and key tag for some DNSKEY RR in
the zone’s apex DNSKEY RRset.
o The matching DNSKEY RR MUST be present in the zone’s apex DNSKEY
RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
set.
It is possible for more than one DNSKEY RR to match the conditions
above. In this case, the validator cannot predetermine which DNSKEY
RR to use to authenticate the signature, and it MUST try each
matching DNSKEY RR until either the signature is validated or the
validator has run out of matching public keys to try.
Note that this authentication process is only meaningful if the
validator authenticates the DNSKEY RR before using it to validate
signatures. The matching DNSKEY RR is considered to be authentic if:
o the apex DNSKEY RRset containing the DNSKEY RR is considered
authentic; or
o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
and the DNSKEY RR either matches an authenticated DS RR from the
parent zone or matches a trust anchor.
5.3.2. Reconstructing the Signed Data
Once the RRSIG RR has met the validity requirements described in
Section 5.3.1, the validator has to reconstruct the original signed
data. The original signed data includes RRSIG RDATA (excluding the
Signature field) and the canonical form of the RRset. Aside from
being ordered, the canonical form of the RRset might also differ from
the received RRset due to DNS name compression, decremented TTLs, or
wildcard expansion. The validator should use the following to
reconstruct the original signed data:
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
"|" denotes concatenation
RRSIG_RDATA is the wire format of the RRSIG RDATA fields
with the Signature field excluded and the Signer’s Name
in canonical form.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
name is calculated according to the function below
class is the RRset’s class
type is the RRset type and all RRs in the class
OrigTTL is the value from the RRSIG Original TTL field
All names in the RDATA field are in canonical form
The set of all RR(i) is sorted into canonical order.
To calculate the name:
let rrsig_labels = the value of the RRSIG Labels field
let fqdn = RRset’s fully qualified domain name in
canonical form
let fqdn_labels = Label count of the fqdn above.
if rrsig_labels = fqdn_labels,
name = fqdn
if rrsig_labels < fqdn_labels,
name = "*." | the rightmost rrsig_label labels of the