1 - 2 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - Z
RR
Click on the red underlined text to get to the source
... NXT resource record and its use in DNS
responses. The NXT RR permits authenticated denial in the DNS of the
...
... An Appendix is provided that gives details of base 64 encoding which
is used in the file representation of some RR's defined in this
document.
...
...
The syntax of a KEY resource record (RR) is described in Section 3.
It includes an algorithm identifier, the actual public key ...
... resource record (signature) is described in
Section 4. It includes the type of the RR(s) being signed, the name
of the signer, the time at which the signature ...
... SIG resource record for each resource type under that name except
for glue RRs and delgation point NS RRs. A security ...
... version of the DNS protocol
security extensions will attempt to return, with RRs retrieved, the
corresponding SIGs. If a server does not support the protocol, the
resolver must retrieve all the SIG ...
...
The above security mechanism provides only a way to sign existing RRs
in a zone. "Data origin" authentication ...
... for the non-existence of a domain name in a zone or the non-existence
of a type for an existing name. This gap is filled by the NXT RR
which authenticatably asserts a range of non-existent names in a zone
...
...
Section 5 below covers the NXT RR.
...
... as "really" belonging to the subzone. These nodes occur in two
master files and may have RRs signed by both the upper and lower
zone's keys. A retrieval could get a mixture of these RRs and SIGs,
...
... master files and may have RRs signed by both the upper and lower
zone's keys. A retrieval could get a mixture of these RRs and SIGs,
especially since one server could be serving both the zone above and
below a delegation ...
...
In general, there must be a zone KEY RR for the subzone in the
superzone and the copy signed in the superzone is controlling. For
all but one other RR ...
... RR for the subzone in the
superzone and the copy signed in the superzone is controlling. For
all but one other RR type that should appearing in both the superzone
and subzone, the data from the subzone is more authoritative. To
avoid conflicts, only the KEY RR ...
... RR type that should appearing in both the superzone
and subzone, the data from the subzone is more authoritative. To
avoid conflicts, only the KEY RR in the superzone should be signed
and the NS and any A (glue) RRs ...
... RR in the superzone should be signed
and the NS and any A (glue) RRs should only be signed in the subzone.
The SOA and any other RRs that have the zone name as owner should
...
... NS and any A (glue) RRs should only be signed in the subzone.
The SOA and any other RRs that have the zone name as owner should
appear only in the subzone and thus are signed there. The NXT RR type
...
... The SOA and any other RRs that have the zone name as owner should
appear only in the subzone and thus are signed there. The NXT RR type
is an exceptional case that will always appear differently and
authoritatively in both the superzone and subzone, if both are
...
...
There is a significant problem when security related RRs with the
same owner name as a CNAME RR ...
... RRs with the
same owner name as a CNAME RR are retrieved from a non-security-aware
server. In particular, an initial retrieval for the CNAME ...
... CNAME or any
other type will not retrieve any associated signature, key, or NXT
RR. For types other than CNAME, it will retrieve that type at the
target ...
... RRs
along with CNAME RRs, (2) suppress CNAME processing on retrieval of
these types as well as on retrieval of the type CNAME ...
... query. This is a change from the previous
DNS standard which prohibited any other RR type at a node where a
CNAME ...
... entity must be present in the DNS and be
appropriately signed but the other RR(s) may be signed with the
entity's key. The other is for support of transaction ...
... Requests can also be authenticated by including a special SIG RR at
the end of the request. Authenticating requests serves no function
in the current DNS ...
...
The KEY resource record (RR) is used to document a key that is
associated with a Domain Name System (DNS ...
...
The type number for the KEY RR is 25.
...
...
The meaning of the KEY RR owner name, flags, and protocol octet are
described in Sections 3.2, 3.3 and 3.4 below respectively. The flags
...
...
The public key in a KEY RR belongs to the object named in the owner
name.
...
... DNS name of the
user or account dee@cybercash.com. Thus, there are flags, as
described below, in the KEY RR to indicate with which of these roles
the owner name and public key ...
... public key are associated. Note that an
appropriate zone KEY RR MUST occur at the apex node of a secure zone
...
... The KEY RR Flag Field ...
... serve. If both bits of this field are one, the "no key" value, there
is no key information and the RR stops after the algorithm octet. By
the use of this "no key" value, a signed KEY ...
... algorithm octet. By
the use of this "no key" value, a signed KEY RR can authenticatably
assert that, for example, a zone is not secured.
...
... zone key, the zone should be assumed
secured by SIG RRs and any responses indicating the zone is not
secured should be considered bogus. If this bit is a one for a host ...
... experimental bit, like all
other aspects of the KEY RR, is only effective if the KEY RR is
appropriately signed by a SIG ...
... bit, like all
other aspects of the KEY RR, is only effective if the KEY RR is
appropriately signed by a SIG RR ...
... domain could have a public key associated through a
KEY RR with name j\.random_user.host.subdomain.domain and the user
...
... Bit 6 on indicates that this is a key associated with the non-
zone "entity" whose name is the RR owner name. This will commonly be
a host but could, in some parts of the DNS tree ...
... bit and indicates that this is a zone key
for the zone whose name is the KEY RR owner name. This is the public
key used for DNS data origin authentication ...
... communication on behalf of an end entity or user whose name is the
owner name of the KEY RR if the entity or user bits are on. The
...
... behalf of an end entity or user whose name is the owner name of the
KEY RR if the entity or user bits are on.
...
... Bits 12-15 are the "signatory" field. If non-zero, they
indicate that the key can validly sign RRs or updates of the same
name. If the owner name is a wildcard, then RRs ...
... RRs or updates of the same
name. If the owner name is a wildcard, then RRs or updates with any
name which is in the wildcard's scope can be signed. Fifteen
...
... DNS commands. Zone
keys always have authority to sign any RRs in the zone regardless of
the value of this field. The signatory field, like all other aspects
of the KEY RR ...
... RRs in the zone regardless of
the value of this field. The signatory field, like all other aspects
of the KEY RR, is only effective if the KEY RR is appropriately
signed by a SIG ...
... the value of this field. The signatory field, like all other aspects
of the KEY RR, is only effective if the KEY RR is appropriately
signed by a SIG RR ...
... other protocols and with which it shares key values that duplicate
RRs are a serious burden and (2) should the protocol provide
substantial facilities not available in any protocol for which a
flags field ...
... KEY RRs in the Construction of Responses ...
...
An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG
...
... information processing except, of course, for the corresponding SIG
RR from a security aware server.
...
... Security aware DNS servers MUST include KEY RRs as additional
information in responses where appropriate including the following:
...
... NS RRs, the zone key KEY RR(s) for the zone
served by these name servers MUST be included as additional
information if space is avilable. There will always be at least one
...
... served by these name servers MUST be included as additional
information if space is avilable. There will always be at least one
such KEY RR in a secure zone, even if it has the no-key type value to
...
... type value to
indicate that the subzone is insecure. If not all additional
information will fit, the KEY RR(s) have higher priority than type A
or AAAA ...
... priority than type A
or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the
retrieval must be considered truncated.
...
... or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the
retrieval must be considered truncated.
...
... AAAA RRs, the end entity KEY RR(s) MUST
be included if space is available. On inclusion of A or AAAA RRs ...
... RR(s) MUST
be included if space is available. On inclusion of A or AAAA RRs as
additional information, their KEY RRs will also be included but with
...
... AAAA RRs as
additional information, their KEY RRs will also be included but with
lower priority than the relevant A or AAAA ...
... File Representation of KEY RRs ...
...
KEY RRs may appear as lines in a zone data master file.
...
... SIG or "signature" resource record (RR) is the fundamental way
that data is authenticated in the secure Domain Name System ...
... SIG RR unforgably authenticates other RRs of a particular type,
class, and name and binds them to a time interval and the signer ...
... The "labels" octet is an unsigned count of how many labels there are
in the original SIG RR owner name not counting the null label for
root and not counting any initial "*" for a wildcard ...
...
If, on retrieval, the RR appears to have a longer name than indicated
by "labels", the resolver can tell it is the result of wildcard
...
... by "labels", the resolver can tell it is the result of wildcard
substitution. If the RR owner name appears to be shorter than the
labels count, the SIG RR ...
... RR owner name appears to be shorter than the
labels count, the SIG RR must be considered corrupt and ignored. The
maximum number of labels allowed in the current DNS is 127 but the
...
... The value of "labels" is at the top, the retrieved owner name on the
left, and the table entry is the name to use in signature
verification except that "bad" means the RR is corrupt.
...
...
NOTE: The "original TTL" must be restored into the covered RRs when
the signature is verified. This implies that all RRs ...
... RRs when
the signature is verified. This implies that all RRs for a
particular type, name, and class must have the same TTL ...
... GMT,
ignoring leap seconds. (See also Section 4.4.) SIG RRs should not
have a date signed significantly in the future. To prevent
misordering of network ...
...
A SIG RR with an expiration date before the time signed must be
considered corrupt and ignored.
...
... SIG RR. This is the owner of the public KEY RR that can be used
to verify the signature. It is frequently the zone which contained
...
... to verify the signature. It is frequently the zone which contained
the RR(s) being authenticated. The signer's name may be compressed
...
... signature portion of the SIG RR binds the other RDATA fields to all
of the "type covered" RRs ...
... RR binds the other RDATA fields to all
of the "type covered" RRs with that owner name and class. These
covered RRs ...
... RRs with that owner name and class. These
covered RRs are thereby authenticated. To accomplish this, a data
sequence is constructed as follows:
...
... RR itself before and not including the signature, and RR(s) are all
the RR(s) of the type covered with the same owner name and class ...
... signature, and RR(s) are all
the RR(s) of the type covered with the same owner name and class as
the SIG ...
... class as
the SIG RR in canonical form and order. How this data sequence is
processed into the signature ...
... DNS security, the canonical form for an RR is the RR
with domain names (1) fully expanded (no name compression ...
... For purposes of DNS security, the canonical order for RRs is to sort
them in ascending order by name, considering labels as a left
justified unsigned octet sequence in network ...
... RDATA as a left justified unsigned
octet sequence. EXCEPT that the type SIG RR(s) covering any
particular type appear immediately after the other RRs of that type.
...
... SIG RR(s) covering any
particular type appear immediately after the other RRs of that type.
(This special consideration for SIG RR ...
... RRs of that type.
(This special consideration for SIG RR(s) in ordering really only
applies to calculating the AXFR SIG ...
... applies to calculating the AXFR SIG RR as explained in section 4.1.3
below.) Thus if at name a.b there are two A RRs and one KEY RR ...
... SIG RR as explained in section 4.1.3
below.) Thus if at name a.b there are two A RRs and one KEY RR,
their order with SIGs for concatenating the "data" to be signed would
...
... RR as explained in section 4.1.3
below.) Thus if at name a.b there are two A RRs and one KEY RR,
their order with SIGs for concatenating the "data" to be signed would
be as follows:
...
... SIG mechanisms assure the authentication of all zone signed
RRs of a particular name, class and type. However, to efficiently
assure the completeness and security ...
... assure the completeness and security of zone transfers, a SIG RR
owned by the zone name must be created with a type covered of AXFR ...
... created with a type covered of AXFR
that covers all zone signed RRs in the zone and their zone SIGs but
not the SIG AXFR ...
... not the SIG AXFR itself. The RRs are ordered and concatenated for
hashing as described in Section 4.1.1. (See also ordering discussion
...
... the zone. In effect, when signing the zone, you order, as described
above, all RRs to be signed by the zone, and all associated glue RRs
and delegation ...
... signing the zone, you order, as described
above, all RRs to be signed by the zone, and all associated glue RRs
and delegation point NS ...
... and delegation point NS RRs. You can then make one pass inserting
all the zone SIGs. As you proceed you hash RRs ...
... RRs. You can then make one pass inserting
all the zone SIGs. As you proceed you hash RRs to be signed into
both an RRset hash ...
... hash that SIG into the zone hash (note that glue RRs and
delegation point NSs are not zone signed but zone apex NSs are).
...
... delegation point NSs are not zone signed but zone apex NSs are).
When you have finished processing all the starting RRs as described
above, you can then use the cumulative zone hash RR ...
... RRs as described
above, you can then use the cumulative zone hash RR to calculate and
insert an AXFR SIG ...
... valid without verification of the
internal zone signed SIGs in the zone; however, any RRs authenticated
by SIGs signed by entity ...
... the recommended off line zone signing procedure (see Section 7.2).
Thus, such RRs are not directly signed by the zone, are not included
in the AXFR SIG ...
... This SIG has a "type covered" field of zero, which is not a valid RR
type. It is calculated by using a "data" (see Section 4.1.2) of the
entire preceding DNS ...
... Security aware DNS servers MUST, for every authoritative RR the query
will return, attempt to send the available SIG ...
... query
will return, attempt to send the available SIG RRs which authenticate
the requested RR ...
... RRs which authenticate
the requested RR. The following rules apply to the inclusion of SIG
RRs ...
... 1. when an RR set is placed in a response, its SIG RR has a higher
priority for inclusion than other additional RRs ...
... RR has a higher
priority for inclusion than other additional RRs that may need to
be included. If space does not permit its inclusion, the response
MUST be considered truncated except as provided in 2 below.
...
...
2. when a SIG RR is present in the zone for an additional information
section RR, the response MUST NOT be considered truncated merely
...
... SIG RR is present in the zone for an additional information
section RR, the response MUST NOT be considered truncated merely
because space does not permit the inclusion of its SIG RR ...
... RR, the response MUST NOT be considered truncated merely
because space does not permit the inclusion of its SIG RR.
3. SIGs to authenticate ...
... authenticate non-authoritative data (glue records and NS
RRs for subzones) are unnecessary and MUST NOT be sent. (Note
that KEYs for subzones are controlling in a superzone so the
superzone's signature ...
...
4. If a SIG covers any RR that would be in the answer section of the
response, its automatic inclusion MUST be the answer section. If
it covers an RR ...
... RR that would be in the answer section of the
response, its automatic inclusion MUST be the answer section. If
it covers an RR that would appear in the authority section, its
automatic inclusion MUST be in the authority ...
... automatic inclusion MUST be in the authority section. If it
covers an RR that would appear in the additional information
section it MUST appear in the additional information section.
This is a change in the existing standard which contemplates only
...
... This is a change in the existing standard which contemplates only
NS and SOA RRs in the authority section.
...
... transactions may be authenticated by a SIG RR at
the end of the response in the additional information section
(Section 4.1.4). Such SIG ...
... the end of the response in the additional information section
(Section 4.1.4). Such SIG RRs are signed by the DNS server
originating the response. Although the signer ...
... authentication is desired,
that SIG RR must be considered higher priority for inclusion than
any other RR ...
... with the AD bit (see Section 6.1) set, MAY choose to accept the
RRs as received without verifying the zone SIG RRs.
...
... security aware resolver SHOULD verify the SIG
RRs for the RRs of interest. This may involve initiating
additional queries ...
... additional queries for SIG or KEY RRs, especially in the case of
getting a response from an insecure server. (As explained in 4.2
above, it will not be possible to secure CNAMEs ...
... If the message does not pass reasonable checks or the SIG does not
check against the signed RRs, the SIG RR is invalid and should be
...
... check against the signed RRs, the SIG RR is invalid and should be
ignored. If all of the SIG RR ...
... RR is invalid and should be
ignored. If all of the SIG RR(s) purporting to authenticate a set of
RRs ...
... RR(s) purporting to authenticate a set of
RRs are invalid, then the set of RR(s) is not authenticated.
...
...
If the SIG RR is the last RR in a response in the additional
information section and has a type covered of zero, it is a
...
... If the SIG RR is the last RR in a response in the additional
information section and has a type covered of zero, it is a
transaction ...
... RRs in the message.
Only a proper SIG RR signed by the zone or a key tracing its
authority to the zone or to static resolver configuration can
...
... authority to the zone or to static resolver configuration can
authenticate RRs. If a resolver does not implement transaction
and/or request SIGs, it MUST ignore them without error.
...
... Security aware servers must not consider SIG RRs to authenticate
anything after their expiration time and not consider any RR ...
... RRs to authenticate
anything after their expiration time and not consider any RR to be
authenticated after its signatures ...
... expire parameters and a non-authoritative server should count down
the TTL and discard RRs when the TTL is zero. In addition, when RRs
...
... TTL and discard RRs when the TTL is zero. In addition, when RRs
are transmitted in a query response, the TTL ...
...
A SIG RR can be represented as a single logical line in a zone data
file [RFC1033] but there are some special considerations as described
...
... transaction or request
authenticating SIG RR in a file as they are a transient
authentication that covers data including an ephemeral transaction ...
... the TTL of the SIG RR itself, it may be omitted. The date field
which follows it is larger than the maximum possible TTL so there is
...
... RR mechanism described in Section 4 above provides strong
authentication of RRs that exist in a zone. But is it not clear
above how to authenticatably deny the existence of a name in a zone
or a type for an existent name.
...
... The nonexistence of a name in a zone is indicated by the NXT ("next")
RR for a name interval containing the nonexistent name. A NXT RR and
its SIG ...
... NXT ("next")
RR for a name interval containing the nonexistent name. A NXT RR and
its SIG are returned in the authority ...
... type under an existing name. This is a change in the existing
standard which contemplates only NS and SOA RRs in the authority
section. NXT ...
... security aware server
serving the zone will always result in an reply containing at least
one signed RR.
...
...
NXT RRs do not appear in zone master files since they can be derived
from the rest of the zone.
...
... The NXT resource record is used to securely indicate that RRs with an
owner name in a certain name interval do not exist in a zone and to
indicate what zone signed RR ...
... RRs with an
owner name in a certain name interval do not exist in a zone and to
indicate what zone signed RR types are present for an existing name.
...
...
The owner name of the NXT RR is an existing name in the zone. It's
RDATA is a "next" name and a type bit ...
... RDATA is a "next" name and a type bit map. The presence of the NXT RR
means that generally no name between its owner name and the name in
its RDATA ...
...
The NXT RRs for a zone SHOULD be automatically calculated and added
to the zone by the same recommended off-line process that signs the
...
... to the zone by the same recommended off-line process that signs the
zone (see Section 7.2). The NXT RR's TTL SHOULD not exceed the zone
minimum TTL ...
...
The type number for the NXT RR is 30.
...
... NXT RR type bit map is one bit per RR type present for the owner
name similar to the WKS socket bit ...
... socket bit map. The first bit represents RR
type zero (an illegal type which should not be present.) A one bit
...
... type zero (an illegal type which should not be present.) A one bit
indicates that at least one RR of that type is present for the owner
name. A zero indicates that no such RR is present. All bits ...
... indicates that at least one RR of that type is present for the owner
name. A zero indicates that no such RR is present. All bits not
specified because they are beyond the end of the bit ...
... NXT bit map
should be printed as a list of RR type mnemonics or decimal numbers
similar to the WKS RR ...
...
Note that this response implies that big.foo.tld is an existing name
in the zone and thus has other RR types associated with it than NXT.
However, only the NXT ...
... However, only the NXT (and its SIG) RR appear in the response to this
query for huge.foo.tld, which is a non-existent name.
...
...
Since, in some sense, a wildcard RR causes all possible names in an
interval to exist, there should not be an NXT RR that would cover any
...
... wildcard RR causes all possible names in an
interval to exist, there should not be an NXT RR that would cover any
part of this interval. Thus if *.X.ZONE exists you would expect an
NXT RR ...
... NXT RR that would cover any
part of this interval. Thus if *.X.ZONE exists you would expect an
NXT RR that ends at X.ZONE and one that starts with the last name
covered by *.X.ZONE. However, this "last name covered" is something
...
...
If there could be any wildcard RRs in a zone and thus wildcard NXTs,
care must be taken in interpreting the results of explicit NXT ...
...
The existence of one or more wildcard RRs covering a name interval
makes it possible for a malicious server to hide any more
specifically named RRs ...
... RRs covering a name interval
makes it possible for a malicious server to hide any more
specifically named RRs in the internal. The server can just falsely
return the wildcard match NXT ...
... wildcard match NXT instead of the more specifically named
RRs. If there is a zone wide wildcard, there will be an NXT RR whose
...
... RRs. If there is a zone wide wildcard, there will be an NXT RR whose
owner name is the wild card and whose RDATA is the zone name. In this
...
... owner name is the wild card and whose RDATA is the zone name. In this
case a server could conceal the existence of any more specific RRs in
the zone. It would be possible to design a more strict NXT feature
...
... domain name RDATA field from that
RR, it can query for the next NXT RR. By repeating this, it can walk
...
... RR, it can query for the next NXT RR. By repeating this, it can walk
through all the NXTs in the zone. If there are no wildcards, it can
...
... wildcards, this NXT walking technique will not find
any more specific RR names in the part of the name space the wildcard
...
... entity, or user) bit on. This will cause
there to be one zone covering NXT RR and leak no information about
what real names exist in the zone. This protection from pseudo-zone
...
... transfers is bought at the expense of eliminating the data origin
authentication of the non-existence of names that NXT RRs can
provide. If an entire zone is covered by a wildcard, a malicious
...
... provide. If an entire zone is covered by a wildcard, a malicious
server can return an RR produced by matching the resulting wildcard
NXT ...
... the leaf in a superzone. If both are secure, there will always be
two different NXT RRs with the same name. They can be distinguished
by their signers and next domain name ...
... SIG under a KEY traceable via a chain of zero or more SIG and
KEY RRs to a KEY configured at the resolver via its boot file.
Pending data has no authenticated SIGs and at least one additional
...
... Security aware resolvers will know that if data is Insecure versus
Authentic by the absence of SIG RRs. Security aware servers MAY
return Pending data to security ...
... AD bit in the response. The AD bit MUST NOT
be set on a response unless all of the RRs in the response are either
Authenticated or Insecure.
...
... for a public key. "name" is the owner name (if the line is
translated into a KEY RR). Flags indicates the type of key and is
the same as the flag octet in the KEY RR. Protocol and algorithm ...
... translated into a KEY RR). Flags indicates the type of key and is
the same as the flag octet in the KEY RR. Protocol and algorithm
also have the same meaning as they do in the KEY RR ...
... RR. Protocol and algorithm
also have the same meaning as they do in the KEY RR. The material
after the algorithm is algorithm ...
... The file looks like a master file except that it can only contain KEY
and SIG RRs with the SIGs signed under a key configured with the
pubkey directive.
...
... root, for its superzone. Every authoritative
secure zone server MUST also include the KEY RR for a super-zone
signed by the secure zone via a keyfile directive. This makes it
...
... starts below root. A
secure sub-zone is indicated by a KEY RR with non-null key
information appearing with the NS ...
... null key
information appearing with the NS RRs for the sub-zone. These make
it possible to descend within the tree of zones.
...
... non-secure, or only experimentally secure, by the
presence of an authenticated KEY RR for the non-secure zone with the
no-key type value ...
... non-secure zone with the
no-key type value or the presence of a KEY RR with the experimental
bit ...
...
Coordinated interpretation of the time fields in SIG RRs requires
that reasonably consistent time be available to the hosts
...
... host could get its clock turned back and
might then believe old SIG and KEY RRs which were valid but no longer
are.
...
...
However, larger keys increase the size of the KEY and SIG RRs. This
increases the chance of DNS UDP ...
... authentication to a zone by adding SIG and NXT RRs and adding no-key
type KEY RRs for subzones where a real KEY RR ...
... NXT RRs and adding no-key
type KEY RRs for subzones where a real KEY RR is not provided. Then
the augmented file can be transferred, perhaps by sneaker-net, to the
...
... RRs and adding no-key
type KEY RRs for subzones where a real KEY RR is not provided. Then
the augmented file can be transferred, perhaps by sneaker-net, to the
networked zone primary server machine.
...
... zone key should only be seen signing itself or signing RRs
with names one level below root, such as .aq, .edu, or .arpa.
...
... (including zone transfer) SIG, KEY, and NXT RRs. Any secondary,
caching, or other server for a secure zone MUST be at least
...
... (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
ability, given a zone file and private key, to add appropriate SIG ...
... SIG
and NXT RRs, possibly via a separate application, (3) proper
automatic inclusion of SIG, KEY, and NXT ...
... automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
suppression of CNAME following on retrieval of the security ...
... CNAME following on retrieval of the security type
RRs, (5) recognize the CD query header bit ...
... header bit, as appropriate, and (6) proper handling of the two NXT
RRs at delegation points. Primary servers for secure zones MUST
...
... A basic compliance resolver can handle SIG, KEY, and NXT RRs when
they are explicitly requested.
...
... A fully compliant resolver (1) understands KEY, SIG, and NXT RRs,
(2) maintains appropriate information in its local caches and
...
... caches and
database to indicate which RRs have been authenticated and to what
extent they have been authenticated ...
... queries as necessary to attempt to obtain KEY, SIG, or NXT RRs
from non-security aware servers, (4) normally sets the CD ...