The examples in this section show how the response messages in
Appendix B are authenticated.
12.1. 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.
12.1.1. C.1.1. Authenticating the Example DNSKEY RR
This example shows the logical authentication process that starts
from the 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.
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.
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.
12.4. 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 whether
the signature lifetime is valid. If all these conditions are met,
all keys in the "a.example" DNSKEY RRset are considered
authenticated.
12.5. C.5. Referral to Unsigned Zone
The query in Appendix B.5 returned a referral to an unsigned
"b.example." zone. The NSEC proves that no authentication leads from
"example" to "b.example", and the NSEC RR is authenticated in a
manner identical to that of the MX RRset discussed above.
12.6. C.6. Wildcard Expansion
The query in Appendix B.6 returned an answer that was produced as a
result of wildcard expansion. The answer section contains a wildcard
RRset expanded as it would be in a traditional DNS response, and the
corresponding RRSIG indicates that the expanded wildcard MX RRset was
signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
The RRSIG indicates that 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 2 indicates that the answer
is the result of wildcard expansion, as the "a.z.w.example" name
contains 4 labels. The name "a.z.w.w.example" is replaced by
"*.w.example", the MX RRset is placed in canonical form, and,
assuming that the current time falls between the signature inception
and expiration dates, the signature is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query, and the NSEC RR must also be
authenticated before the answer is considered valid.
The query in Appendix B.7 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 query in Appendix B.8 returned NSEC RRs that shows the requested
was answered by a child server ("example" server). The NSEC RR
indicates the presence of an SOA RR, showing that the answer is from
the child . Queries for the "example" DS RRset should be sent to the
parent servers ("root" servers).
