authentication
Click on the red underlined text to get to the source
... DNS Security Extensions (DNSSEC) are a collection of new resource
records and protocol modifications that add data origin
authentication and data integrity to the DNS. This document defines
...
... resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
to authenticate a response.
...
... the owner name. A DS RR could also be present if the zone being
delegated is signed and seeks to have a chain of authentication to
the parent zone. This is an exception to the original DNS
...
...
o RRSIG RRs that can be used to authenticate a response MUST be
included in the response according to the rules in Section 3.1.1.
...
...
o NSEC RRs that can be used to provide authenticated denial of
existence MUST be included in the response automatically according
to the rules in Section 3.1.3.
...
... RRSIG RRs that a
security-aware resolver can use to authenticate the RRsets in the
response. A name server SHOULD make every attempt to keep the RRset ...
... name
server side. If the CD bit is set, it indicates that the originating
resolver is willing to perform whatever authentication its local
policy requires. Thus, the resolver side of the recursive name
server need not perform authentication ...
... authentication its local
policy requires. Thus, the resolver side of the recursive name
server need not perform authentication on the RRsets in the response.
When the CD bit is set, the recursive name server ...
... possible, return the requested data to the originating resolver, even
if the recursive name server's local authentication policy would
reject the records in question. That is, by setting the CD bit, the
...
... CD bit, the
originating resolver has indicated that it takes responsibility for
performing its own authentication, and the recursive name server
should not interfere.
...
... 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
...
...
To use DNSSEC RRs for authentication, a security-aware resolver
requires configured knowledge of at least one authenticated ...
... authentication, a security-aware resolver
requires configured knowledge of at least one authenticated DNSKEY or
DS RR ...
... 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 ...
... 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
...
... RRset. The process for using
an RRSIG RR to authenticate an RRset is described in Section 5.3.
...
... 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 ...
... 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
...
... RRSIG RRs from the zone to authenticate any other
RRsets in the zone once the resolver has authenticated a zone's apex
DNSKEY RRset ...
... DNSKEY RRset. Section 5.4 shows how the resolver can use
authenticated NSEC RRsets from the zone to prove that an RRset is not
...
... requested. The absence of DNSSEC data in a response MUST NOT by
itself be taken as an indication that no authentication information
exists.
...
... 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 ...
... 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 ...
... 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 ...
... DNSKEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate the delegation ...
... authenticated, DS RRsets can be used to authenticate the delegation
to a signed child zone. A DS RR ...
... 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 ...
... DNSKEY RR. The resolver can then use this child DNSKEY RR
to authenticate the entire child apex DNSKEY RRset.
...
... 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 ...
... 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 ...
... 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
...
... 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 ...
... 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 ...
... 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
...
... 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.
...
... 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 ...
... 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.
...
... A security-aware resolver can use an RRSIG RR to authenticate an
RRset if all of the following conditions hold:
...
... 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 ...
... public keys to try.
Note that this authentication process is only meaningful if the
validator authenticates the DNSKEY RR ...
... Note that this authentication process is only meaningful if the
validator authenticates the DNSKEY RR before using it to validate
...
... RRset itself,
and the DNSKEY RR either matches an authenticated DS RR from the
parent zone or matches a trust anchor ...
... RRSIG RR did not pass the necessary validation
checks and MUST NOT be used to authenticate this
RRset.
...
... TTL of the RRSIG RR and each RR in the authenticated RRset to
a value no greater than the minimum of:
...
... Note that the response received by the resolver should include all
NSEC RRs needed to authenticate the response (see Section 3.1.3).
...
... Authenticated Denial of Existence ...
... o If the requested RR name matches the owner name of an
authenticated NSEC RR, then the NSEC RR's type bit ...
... 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 ...
...
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
...
...
In addition, security-aware resolvers MUST authenticate the NSEC
RRsets that comprise the non-existence proof as described in Section
...
... Authentication Example ...
...
Appendix C shows an example of the authentication process.
...
... This document describes how the DNS security extensions use public
key cryptography to sign and authenticate DNS resource record sets.
Please see [RFC4033 ...
... Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655(-> 4035prop | 4034prop | 4033prop) ...
... Appendix C. Authentication Examples ...
...
The examples in this section show how the response messages in
Appendix B are authenticated.
...
... 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
...
... TTL of the MX RRset was 3600, and,
for the purpose of authentication, the current TTL is replaced by
3600. The RRSIG ...
...
This example shows the logical authentication process that starts
from the a configured root ...
... 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
...
... 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
...
... 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
...
... DNSKEY RRset are considered
authenticated. The resolver then uses one (or more) of the root
DNSKEY RRs ...
... DNSKEY RRset for some "example" DNSKEY
RR that matches one of the authenticated "example" DS RRs. If such a
matching "example" DNSKEY ...
... "example" DNSKEY RRset are considered authenticated.
Finally, the resolver checks that some DNSKEY RR ...
... key tag of 38519. This
DNSKEY is used to authenticate the RRSIG included in the response.
If multiple "example" DNSKEY RRs ...
... key tag,
then each DNSKEY RR is tried, and the answer is authenticated if any
of the matching DNSKEY RRs validate ...
... requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
...
... NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed
above.
...
... 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 ...
... authenticated by verifying the NSEC RR. The NSEC
RR is authenticated in a manner identical to that of the MX RRset
discussed above.
...
... 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 ...
... Once the "a.example" DS RRset has been authenticated using the
"example" DNSKEY, the resolver checks the "a.example" DNSKEY ...
... 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 ...
... 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.
...
... TTL of the MX RRset was 3600,
and, for the purpose of authentication, the current TTL is replaced
by 3600. The RRSIG ...
... requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs.
...