4.  Resolving

   This section describes the behavior of entities that include
   security-aware resolver functions.  In many cases such functions will
   be part of a security-aware recursive name server, but a stand-alone
   security-aware resolver has many of the same requirements.  Functions
   specific to security-aware recursive name servers are described in
   Section 3.2.

4.1.  EDNS Support

   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.

   A security-aware resolver MUST support a message size of at least
   1220 octets, SHOULD support a message size of 4000 octets, and MUST
   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
   to advertise the message size that it is willing to accept.  A
   security-aware resolver's IP layer MUST handle fragmented UDP packets
   correctly regardless of whether any such fragmented packets were
   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
   [RFC3226] for discussion of these requirements.

4.2.  Signature Verification Support

   A security-aware resolver MUST support the signature verification
   mechanisms described in Section 5 and SHOULD apply them to every
   received response, except when:

   o  the security-aware resolver is part of a security-aware recursive
      name server, and the response is the result of recursion on behalf
      of a query received with the CD bit set;

   o  the response is the result of a query generated directly via some
      form of application interface that instructed the security-aware
      resolver not to perform validation for this query; or

   o  validation for this query has been disabled by local policy.

   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
                                fqdn

               if rrsig_labels > fqdn_labels
                  the RRSIG RR did not pass the necessary validation
                  checks and MUST NOT be used to authenticate this
                  RRset.

   The canonical forms for names and RRsets are defined in [RFC4034].

   NSEC RRsets at a delegation boundary require special processing.
   There are two distinct NSEC RRsets associated with a signed delegated
   name.  One NSEC RRset resides in the parent zone, and specifies which
   RRsets are present at the parent zone.  The second NSEC RRset resides
   at the child zone and identifies which RRsets are present at the apex
   in the child zone.  The parent NSEC RRset and child NSEC RRset can
   always be distinguished as only a child NSEC RR will indicate that an
   SOA RRset exists at the name.  When reconstructing the original NSEC
   RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
   be combined with NSEC RRs from the child zone.  When reconstructing
   the original NSEC RRset for the apex of the child zone, the NSEC RRs
   MUST NOT be combined with NSEC RRs from the parent zone.

   Note that each of the two NSEC RRsets at a delegation point has a
   corresponding RRSIG RR with an owner name matching the delegated
   name, and each of these RRSIG RRs is authoritative data associated
   with the same zone that contains the corresponding NSEC RRset.  If
   necessary, a resolver can tell these RRSIG RRs apart by checking the
   Signer's Name field.

5.3.3.  Checking the Signature

   Once the resolver has validated the RRSIG RR as described in Section
   5.3.1 and reconstructed the original signed data as described in
   Section 5.3.2, the validator can attempt to use the cryptographic
   signature to authenticate the signed data, and thus (finally!)
   authenticate the RRset.

   The Algorithm field in the RRSIG RR identifies the cryptographic
   algorithm used to generate the signature.  The signature itself is
   contained in the Signature field of the RRSIG RDATA, and the public
   key used to verify the signature is contained in the Public Key field
   of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
   provides a list of algorithm types and provides pointers to the
   documents that define each algorithm's use.

   Note that it is possible for more than one DNSKEY RR to match the
   conditions in Section 5.3.1.  In this case, the validator can only
   determine which DNSKEY RR is correct by trying each matching public
   key until the validator either succeeds in validating the signature
   or runs out of keys to try.

   If the Labels field of the RRSIG RR is not equal to the number of
   labels in the RRset's fully qualified owner name, then the RRset is
   either invalid or the result of wildcard expansion.  The resolver
   MUST verify that wildcard expansion was applied properly before
   considering the RRset to be authentic.  Section 5.3.4 describes how
   to determine whether a wildcard was applied properly.

   If other RRSIG RRs also cover this RRset, the local resolver security
   policy determines whether the resolver also has to test these RRSIG
   RRs and how to resolve conflicts if these RRSIG RRs lead to differing
   results.

   If the resolver accepts the RRset as authentic, the validator MUST
   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
   a value no greater than the minimum of:

   o  the RRset's TTL as received in the response;

   o  the RRSIG RR's TTL as received in the response;

   o  the value in the RRSIG RR's Original TTL field; and

   o  the difference of the RRSIG RR's Signature Expiration time and the
      current time.

5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response

   If the number of labels in an RRset's owner name is greater than the
   Labels field of the covering RRSIG RR, then the RRset and its
   covering RRSIG RR were created as a result of wildcard expansion.
   Once the validator has verified the signature, as described in
   Section 5.3, it must take additional steps to verify the non-
   existence of an exact match or closer wildcard match for the query.
   Section 5.4 discusses these steps.

   Note that the response received by the resolver should include all
   NSEC RRs needed to authenticate the response (see Section 3.1.3).

5.4.  Authenticated Denial of Existence

   A resolver can use authenticated NSEC RRs to prove that an RRset is
   not present in a signed zone.  Security-aware name servers should
   automatically include any necessary NSEC RRs for signed zones in
   their responses to security-aware resolvers.

   Denial of existence is determined by the following rules:

   o  If the requested RR name matches the owner name of an
      authenticated NSEC RR, then the NSEC RR's type bit map field lists
      all RR types present at that owner name, and a resolver can prove
      that the requested RR type does not exist by checking for the RR
      type in the bit map.  If the number of labels in an authenticated
      NSEC RR's owner name equals the Labels field of the covering RRSIG
      RR, then the existence of the NSEC RR proves that wildcard
      expansion could not have been used to match the request.

   o  If the requested RR name would appear after an authenticated NSEC
      RR's owner name and before the name listed in that NSEC RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [RFC4034], then no RRsets with the requested name exist
      in the zone.  However, it is possible that a wildcard could be
      used to match the requested RR owner name and type, so proving
      that the requested RRset does not exist also requires proving that
      no possible wildcard RRset exists that could have been used to
      generate a positive response.

   In addition, security-aware resolvers MUST authenticate the NSEC
   RRsets that comprise the non-existence proof as described in Section
   5.3.

   To prove the non-existence of an RRset, the resolver must be able to
   verify both that the queried RRset does not exist and that no
   relevant wildcard RRset exists.  Proving this may require more than

   one NSEC RRset from the zone.  If the complete set of necessary NSEC
   RRsets is not present in a response (perhaps due to message
   truncation), then a security-aware resolver MUST resend the query in
   order to attempt to obtain the full collection of NSEC RRs necessary
   to verify the non-existence of the requested RRset.  As with all DNS
   operations, however, the resolver MUST bound the work it puts into
   answering any particular query.

   Since a validated NSEC RR proves the existence of both itself and its
   corresponding RRSIG RR, a validator MUST ignore the settings of the
   NSEC and RRSIG bits in an NSEC RR.

5.5.  Resolver Behavior When Signatures Do Not Validate

   If for whatever reason none of the RRSIGs can be validated, the
   response SHOULD be considered BAD.  If the validation was being done
   to service a recursive query, the name server MUST return RCODE 2 to
   the originating client.  However, it MUST return the full response if
   and only if the original query had the CD bit set.  Also see Section
   4.7 on caching responses that do not validate.

5.6.  Authentication Example

   Appendix C shows an example of the authentication process.

6.  IANA Considerations

   [RFC4034] contains a review of the IANA considerations introduced by
   DNSSEC.  The following are additional IANA considerations discussed
   in this document:

   [RFC2535] reserved the CD and AD bits in the message header.  The
   meaning of the AD bit was redefined in [RFC3655], and the meaning of
   both the CD and AD bit are restated in this document.  No new bits in
   the DNS message header are defined in this document.

   [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
   and defined its use.  The use is restated but not altered in this
   document.

7.  Security Considerations

   This document describes how the DNS security extensions use public
   key cryptography to sign and authenticate DNS resource record sets.
   Please see [RFC4033] for terminology and general security
   considerations related to DNSSEC; see [RFC4034] for considerations
   specific to the DNSSEC resource record types.

   An active attacker who can set the CD bit in a DNS query message or
   the AD bit in a DNS response message can use these bits to defeat the
   protection that DNSSEC attempts to provide to security-oblivious
   recursive-mode resolvers.  For this reason, use of these control bits
   by a security-aware recursive-mode resolver requires a secure
   channel.  See Sections 3.2.2 and 4.9 for further discussion.

   The protocol described in this document attempts to extend the
   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
   recovery from validation failures is likely to be specific to
   particular applications, the facilities that DNSSEC provides for stub
   resolvers may prove inadequate.  Operators of security-aware
   recursive name servers will have to pay close attention to the
   behavior of the applications that use their services when choosing a
   local validation policy; failure to do so could easily result in the
   recursive name server accidentally denying service to the clients it
   is intended to support.

8.  Acknowledgements

   This document was created from the input and ideas of the members of
   the DNS Extensions Working Group and working group mailing list.  The
   editors would like to express their thanks for the comments and
   suggestions received during the revision of these security extension
   specifications.  Although explicitly listing everyone who has
   contributed during the decade in which DNSSEC has been under
   development would be impossible, [RFC4033] includes a list of some of
   the participants who were kind enough to comment on these documents.