Name Server
Click on the red underlined text to get to the source
... zone signing. Section 3 describes the modifications to authoritative
name server behavior necessary for handling signed zones. Section 4
describes the behavior of entities that include security-aware
...
... This section describes the behavior of entities that include
security-aware name server functions. In many cases such functions
will be part of a security-aware recursive name server ...
... name server functions. In many cases such functions
will be part of a security-aware recursive name server, but a
security-aware authoritative name server ...
... name server, but a
security-aware authoritative name server has some of the same
requirements. Functions specific to security-aware ...
...
A security-aware name server that receives a DNS query that does not
include the EDNS OPT pseudo ...
... should behave self-consistently. As long as the response is always
consistent for each query to the name server, the name server MAY
return one of the following:
...
... consistent for each query to the name server, the name server MAY
return one of the following:
...
... CD bit
is controlled by resolvers; a security-aware name server MUST copy
the CD bit from a query ...
... AD bit
is controlled by name servers; a security-aware name server MUST
ignore the setting of the AD bit in queries ...
... DO bit ([RFC3225]) set, a security-aware authoritative name
server for a signed zone MUST include additional RRSIG, NSEC, and DS
RRs ...
... DO bit set, a security-aware
authoritative name server SHOULD attempt to send RRSIG RRs that a
security-aware ...
... security-aware resolver can use to authenticate the RRsets in the
response. A name server SHOULD make every attempt to keep the RRset
and its associated RRSIG ...
...
o When placing a signed RRset in the Answer section, the name server
MUST also place its RRSIG RRs in the Answer section. The RRSIG
RRs ...
... that may have to be included. If space does not permit inclusion
of these RRSIG RRs, the name server MUST set the TC bit.
...
... o When placing a signed RRset in the Authority section, the name
server MUST also place its RRSIG RRs in the Authority section.
...
... RRsets that may have to be included. If space does not permit
inclusion of these RRSIG RRs, the name server MUST set the TC bit.
...
...
o When placing a signed RRset in the Additional section, the name
server MUST also place its RRSIG RRs in the Additional section.
If space does not permit inclusion of both the RRset ...
... RRset and its
associated RRSIG RRs, the name server MAY retain the RRset while
dropping the RRSIG RRs ...
... RRset while
dropping the RRSIG RRs. If this happens, the name server MUST NOT
set the TC bit solely because these RRSIG RRs ...
... RRs at the apex of a signed zone, a security-aware
authoritative name server for that zone MAY return the zone apex
DNSKEY RRset ...
... priority than does
any other information that would be placed in the additional section.
The name server SHOULD NOT include the DNSKEY RRset unless there is
...
... these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
NOT set the TC bit solely because these RRs ...
... DO bit set, a security-aware
authoritative name server for a signed zone MUST include NSEC RRs in
each of the following cases:
...
... name expansion.
In each of these cases, the name server includes NSEC RRs in the
response to prove that an exact match for <SNAME, SCLASS, STYPE> was
...
... NSEC RRs in the
response to prove that an exact match for <SNAME, SCLASS, STYPE> was
not present in the zone and that the response that the name server is
returning is correct given the data in the zone.
...
... If the zone contains RRsets matching <SNAME, SCLASS> but contains no
RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
include the NSEC RR for <SNAME, SCLASS> along with its associated
...
... NSEC RR or its
associated RRSIG RR(s), the name server MUST set the TC bit (see
Section 3.1.1).
...
... If the zone does not contain any RRsets matching <SNAME, SCLASS>
either exactly or via wildcard name expansion, then the name server
MUST include the following NSEC RRs in the Authority ...
... In some cases, a single NSEC RR may prove both of these points. If
it does, the name server SHOULD only include the NSEC RR and its
RRSIG RR ...
... RRset that matches <SNAME, SCLASS, STYPE>
via wildcard name expansion, the name server MUST include the
wildcard ...
... not permit inclusion of the answer, NSEC and RRSIG RRs, the name
server MUST set the TC bit (see Section 3.1.1).
...
... does contain RRsets that match <SNAME, SCLASS> via wildcard
expansion, none of those RRsets matches STYPE. The name server MUST
include the following NSEC RRs in the Authority ...
... In some cases, a single NSEC RR may prove both of these points. If
it does, the name server SHOULD only include the NSEC RR and its
RRSIG RR ...
... As explained above, there are several situations in which a
security-aware authoritative name server has to locate an NSEC RR
that proves that no RRsets matching a particular SNAME exist.
...
... simple, at least in concept. The following discussion assumes that
the name server is authoritative for the zone that would have held
the non-existent RRsets matching SNAME. The algorithm below is
...
... existent applicable wildcard. In practice, this is easy, because the
authoritative name server has already checked for the presence of
precisely this wildcard name as part of step (1)(c) of the normal
...
... DO bit set, a security-aware
authoritative name server returning a referral includes DNSSEC data
along with the NS ...
... DS RRset is present at the delegation point, the name server
MUST return both the NSEC RR that proves that the DS ...
... delegation of "foo.example" is stored in the "example" zone rather
than in the "foo.example" zone. This requires special processing
rules for both name servers and resolvers, as the name server for the
child zone is authoritative for the name at the zone cut by the
normal DNS ...
... queries through a
security-oblivious recursive name server). The rest of this section
describes how a security-aware name server ...
... name server). The rest of this section
describes how a security-aware name server processes DS queries in
...
...
The need for special processing by a security-aware name server only
arises when all the following conditions are met:
...
... arises when all the following conditions are met:
o The name server has received a query for the DS RRset ...
... cut.
o The name server is authoritative for the child zone.
o The name server ...
... name server is authoritative for the child zone.
o The name server is not authoritative for the parent zone.
o The name server ...
... name server is not authoritative for the parent zone.
o The name server does not offer recursion.
In all other cases, the name server ...
... name server does not offer recursion.
In all other cases, the name server either has some way of obtaining
the DS RRset ...
... processing rules.
If all the above conditions are met, however, the name server is
authoritative for SNAME but cannot supply the requested RRset. In
...
... authoritative for SNAME but cannot supply the requested RRset. In
this case, the name server MUST return an authoritative "no data"
response showing that the DS ...
... operation.
An authoritative name server is not required to verify that a zone is
properly signed before sending or accepting a zone transfer.
However, an authoritative name server ...
... name server is not required to verify that a zone is
properly signed before sending or accepting a zone transfer.
However, an authoritative name server MAY choose to reject the entire
zone transfer if the zone fails to meet any of the signing
...
... requirements described in Section 2. The primary objective of a zone
transfer is to ensure that all authoritative name servers have
identical copies of the zone. An authoritative name server that
chooses to perform its own zone validation ...
... CD bit
is clear. A security-aware name server SHOULD clear the CD bit when
composing an authoritative response.
...
... name server MUST NOT set the AD bit in a response
unless the name server considers all RRsets in the Answer and
Authority sections of the response to be authentic. A security-aware ...
... Authority sections of the response to be authentic. A security-aware
name server's local policy MAY consider data from an authoritative
zone to be authentic without further validation. However, the name
server ...
... name server's local policy MAY consider data from an authoritative
zone to be authentic without further validation. However, the name
server MUST NOT do so unless the name server obtained the
authoritative zone via secure means (such as a secure zone ...
... zone to be authentic without further validation. However, the name
server MUST NOT do so unless the name server obtained the
authoritative zone via secure means (such as a secure zone transfer
...
...
A security-aware name server that supports recursion MUST follow the
rules for the CD and AD ...
... As explained in [RFC4033], a security-aware recursive name server is
an entity that acts in both the security-aware ...
... an entity that acts in both the security-aware name server and
security-aware resolver roles ...
... security-aware resolver roles. This section uses the terms "name
server side" and "resolver side" to refer to the code within a
security-aware recursive name server ...
... name
server side" and "resolver side" to refer to the code within a
security-aware recursive name server that implements the
security-aware name server ...
... name server that implements the
security-aware name server role and the code that implements the
security-aware ...
...
The resolver side of a security-aware recursive name server MUST set
the DO bit when sending requests, regardless of the state ...
... DO bit when sending requests, regardless of the state of the DO
bit in the initiating request received by the name server side. If
the DO bit in an initiating query ...
... the DO bit in an initiating query is not set, the name server side
MUST strip any authenticating DNSSEC RRs from the response but MUST
...
... to the corresponding response.
The name server side of a security-aware recursive name server MUST
...
... The name server side of a security-aware recursive name server MUST
pass the state of the CD bit ...
... of an initiating query, so that the resolver side will know whether
it is required to verify the response data it returns to the name
server side. If the CD bit is set, it indicates that the originating
resolver is willing to perform whatever authentication ...
... resolver is willing to perform whatever 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 ...
... authentication on the RRsets in the response.
When the CD bit is set, the recursive name server SHOULD, if
possible, return the requested data to the originating resolver, even
if the recursive name server ...
... name server SHOULD, if
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 ...
... originating resolver has indicated that it takes responsibility for
performing its own authentication, and the recursive name server
should not interfere.
...
... If the resolver side implements a BAD cache (see Section 4.7) and the
name server side receives a query that matches an entry in the
resolver side's BAD cache ...
... query that matches an entry in the
resolver side's BAD cache, the name server side's response depends on
the state of the CD bit ...
... query. If the CD bit is set,
the name server side SHOULD return the data from the BAD cache; if
the CD bit ...
... clients that depend on the resolver side of a
security-aware recursive name server to perform such checks. Several
of the possible reasons why signature validation ...
... signature validation might fail involve
conditions that may not apply equally to the recursive name server
and the client that invoked it. For example, the recursive name
server ...
... name server
and the client that invoked it. For example, the recursive name
server's clock may be set incorrectly, or the client may have
knowledge of a relevant island of security ...
... client may have
knowledge of a relevant island of security that the recursive name
server does not share. In such cases, "protecting" a client that is
capable of performing its own signature ...
... The name server side of a security-aware recursive name server MUST
NOT set the AD bit in a response unless the name server ...
... name server MUST
NOT set the AD bit in a response unless the name server considers all
RRsets in the Answer and Authority sections of the response to be
...
... RRsets in the Answer and Authority sections of the response to be
authentic. The name server side SHOULD set the AD bit if and only if
the resolver side considers all RRsets in the Answer section and any
...
... RRs in question are authentic.
However, for backward compatibility, a recursive name server MAY set
the AD bit when a response includes unsigned CNAME ...
... security-aware resolver functions. In many cases such functions will
be part of a security-aware recursive name server, but a stand-alone
security-aware resolver has many of the same requirements ...
... security-aware resolver is part of a security-aware recursive
name server, and the response is the result of recursion on behalf
of a query received with the CD bit ...
... wildcard. A security-aware
recursive name server could store this wildcard data and use it
to generate positive responses to queries ...
... discussion of how the responses returned by a
security-aware recursive name server interact with a BAD cache.
...
... security-aware stub resolver MAY include the DNSSEC
RRs returned by a security-aware recursive name server as part of the
data that the stub resolver hands back to the application that
invoked it, but is not required to do so. A non-validating stub
...
... DO bit in order
to receive DNSSEC RRs from the recursive name server.
A validating security-aware ...
... application
layer, as by definition, a non-validating stub resolver depends on
the security-aware recursive name server to perform validation on its
behalf.
...
... CD bit,
because otherwise the security-aware recursive name server will
answer the query using the name server ...
... name server will
answer the query using the name server's local policy, which may
prevent the stub resolver from receiving data that would be
...
... AD bit in response messages that it receives in
order to determine whether the security-aware recursive name server
that sent the response claims to have cryptographically verified the
data in the Answer and Authority ...
... resolver are heavily dependent on the local policy of the
security-aware recursive name server. Therefore, there may be little
practical value in checking the status of the AD bit, except perhaps
...
... security-aware stub resolver obtained the
data in question from a trusted security-aware recursive name server
via a secure channel.
...
... such as an upstream security-oblivious recursive name server that
accidentally interferes with DNSSEC RRs ...
... local validation policy; failure to do so could easily result in the
recursive name server accidentally denying service to the clients it
...