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:

• The DS RR has been authenticated using some DNSKEY RR in the parent's apex DNSKEY RRset (see Section 5.3).
• 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.
• 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:

• The RRSIG RR and the RRset MUST have the same owner name and the same class.
• The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset.
• The RRSIG RR's Type Covered field MUST equal the RRset's type.
• 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.
• 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.
• 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.
• 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.
• 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:

• the apex DNSKEY RRset containing the DNSKEY RR is considered authentic; or
• 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.

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:

• 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.

• 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.

---