Appendix C. Authentication Examples
The examples in this section show how the response messages in Appendix B are authenticated.
C.1. Authenticating an Answer
The query in Appendix B.1 returned an MX RRset for x.w.example.com. The corresponding RRSIG indicates that the MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The resolver needs the corresponding DNSKEY RR in order to authenticate this answer. The discussion below describes how a resolver might obtain this DNSKEY RR.
The RRSIG indicates the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. The x.w.example.com MX RRset is placed in canonical form, and, assuming the current time falls between the signature inception and expiration dates, the signature is authenticated.
C.1.1. Authenticating the Example DNSKEY RR
This example shows the logical authentication process that starts from a configured root DNSKEY (or DS RR) and moves down the tree to authenticate the desired "example" DNSKEY RR. Note that the logical order is presented for clarity. An implementation may choose to construct the authentication as referrals are received or to construct the authentication chain only after all RRsets have been obtained, or in any other combination it sees fit. The example here demonstrates only the logical process and does not dictate any implementation rules.
We assume the resolver starts with a configured DNSKEY RR for the root zone (or a configured DS RR for the root zone). The resolver checks whether this configured DNSKEY RR is present in the root DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY RRset, and whether the signature lifetime is valid. If all these conditions are met, all keys in the DNSKEY RRset are considered authenticated. The resolver then uses one (or more) of the root DNSKEY RRs to authenticate the "example" DS RRset. Note that the resolver may have to query the root zone to obtain the root DNSKEY RRset or "example" DS RRset.
Once the DS RRset has been authenticated using the root DNSKEY, the resolver checks the "example" DNSKEY RRset for some "example" DNSKEY RR that matches one of the authenticated "example" DS RRs. If such a matching "example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "example" DNSKEY RRset and the signature lifetime is valid. If these conditions are met, all keys in the "example" DNSKEY RRset are considered authenticated.
Finally, the resolver checks that some DNSKEY RR in the "example" DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY is used to authenticate the RRSIG included in the response. If multiple "example" DNSKEY RRs match this algorithm and key tag, then each DNSKEY RR is tried, and the answer is authenticated if any of the matching DNSKEY RRs validate the signature as described above.
C.2. Name Error
The query in Appendix B.2 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs. The NSEC RRs are authenticated in a manner identical to that of the MX RRset discussed above.
C.3. No Data Error
The query in Appendix B.3 returned an NSEC RR that proves that the requested name exists, but the requested RR type does not exist. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
C.4. Referral to Signed Zone
The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical to that of the MX RRset discussed above. This DS RR is used to authenticate the "a.example" DNSKEY RRset.
Once the "a.example" DS RRset has been authenticated using the "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset for some "a.example" DNSKEY RR that matches the DS RR. If such a matching "a.example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "a.example" DNSKEY RRset and the signature lifetime is valid. If these conditions are met, all keys in the "a.example" DNSKEY RRset are considered authenticated.
C.5. Referral to Unsigned Zone
The query in Appendix B.5 returned a referral to the unsigned "b.example." zone. The NSEC RR proves that no DS RR is associated with the "b.example." delegation. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
The resolver determines that "b.example." is an unsigned zone and that answers from "b.example." will be insecure.
C.6. Wildcard Expansion
The query in Appendix B.6 resulted in wildcard expansion. Examining the RRSIG labels field shows that the answer was the result of wildcard expansion. The "*.w.example." wildcard name is placed in canonical form and authenticated as in Appendix C.1. The resolver must also verify the NSEC RR to prove that no closer match exists in the zone that would have been used instead of the wildcard match.
C.7. Wildcard No Data Error
The query in Appendix B.7 was answered using a wildcard, but the response is a "no data" response. The RRSIG labels field value of 2 in the RRSIG indicates that the NSEC RR was derived from a wildcard and provides the wildcard name. The "*.w.example." wildcard NSEC RR is authenticated as in Appendix C.1. The resolver must also verify the NSEC RR to prove that no closer match exists in the zone that would have been used instead of the wildcard match.
C.8. DS Child Zone No Data Error
The query in Appendix B.8 was sent to the child zone and returned an NSEC RR that shows that no DS RR exists in the child zone. Note that the NSEC RR indicates that there is an SOA RR at the apex of the child zone, which allows the resolver to determine that this answer is from the child zone as opposed to the parent zone. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.