3. Serving
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, but a
security-aware authoritative name server has some of the same
requirements. Functions specific to security-aware recursive name
servers are described in Section 3.2; functions specific to
authoritative servers are described in Section 3.1.
In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
are as used in [RFC1034].
A security-aware name server MUST support the EDNS0 ([RFC2671])
message size extension, MUST support a message size of at least 1220
octets, and SHOULD support a message size of 4000 octets. As IPv6
packets can only be fragmented by the source host, a security aware
name server SHOULD take steps to ensure that UDP datagrams it
transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
and [RFC3226] for further discussion of packet size and fragmentation
issues.
A security-aware name server that receives a DNS query that does not
include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
MUST NOT perform any of the additional processing described below.
Because the DS RR type has the peculiar property of only existing in
the parent zone at delegation points, DS RRs always require some
special processing, as described in Section 3.1.4.1.
Security aware name servers that receive explicit queries for
security RR types that match the content of more than one zone that
it serves (for example, NSEC and RRSIG RRs above and below a
delegation point where the server is authoritative for both zones)
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:
o The above-delegation RRsets.
o The below-delegation RRsets.
o Both above and below-delegation RRsets.
o Empty answer section (no records).
o Some other response.
o An error.
DNSSEC allocates two new bits in the DNS message header: the CD
(Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
is controlled by resolvers; a security-aware name server MUST copy
the CD bit from a query into the corresponding response. The AD bit
is controlled by name servers; a security-aware name server MUST
ignore the setting of the AD bit in queries. See Sections 3.1.6,
3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
A security aware name server that synthesizes CNAME RRs from DNAME
RRs as described in [RFC2672] SHOULD NOT generate signatures for the
synthesized CNAME RRs.
3.1. Authoritative Name Servers
Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
server for a signed zone MUST include additional RRSIG, NSEC, and DS
RRs, according to the following rules:
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.
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
be included in referrals automatically according to the rules in
Section 3.1.4.
These rules only apply to responses where the semantics convey
information about the presence or absence of resource records. That
is, these rules are not intended to rule out responses such as RCODE
4 ("Not Implemented") or RCODE 5 ("Refused").
DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
discusses zone transfer requirements.
3.1.1. Including RRSIG RRs in a Response
When responding to a query that has the DO bit set, a security-aware
authoritative name server SHOULD attempt to send 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
and its associated RRSIG(s) together in a response. Inclusion of
RRSIG RRs in a response is subject to the following rules:
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 have a higher priority for inclusion than any other 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 Authority section, the name
server MUST also place its RRSIG RRs in the Authority section.
The RRSIG RRs have a higher priority for inclusion than any other
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 and its
associated RRSIG RRs, the name server MAY retain the RRset while
dropping the RRSIG RRs. If this happens, the name server MUST NOT
set the TC bit solely because these RRSIG RRs didn't fit.
3.1.2. Including DNSKEY RRs in a Response
When responding to a query that has the DO bit set and that requests
the SOA or NS RRs at the apex of a signed zone, a security-aware
authoritative name server for that zone MAY return the zone apex
DNSKEY RRset in the Additional section. In this situation, the
DNSKEY RRset and associated RRSIG RRs have lower 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
enough space in the response message for both the DNSKEY RRset and
its associated RRSIG RR(s). If there is not enough space to include
these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
NOT set the TC bit solely because these RRs didn't fit (see Section
3.1.1).
3.1.3. Including NSEC RRs in a Response
When responding to a query that has the DO bit set, a security-aware
authoritative name server for a signed zone MUST include NSEC RRs in
each of the following cases:
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
but does not contain any RRsets that exactly match <SNAME, SCLASS,
STYPE>.
Name Error: The zone does not contain any RRsets that match <SNAME,
SCLASS> either exactly or via wildcard name expansion.
Wildcard Answer: The zone does not contain any RRsets that exactly
match <SNAME, SCLASS> but does contain an RRset that matches
<SNAME, SCLASS, STYPE> via wildcard name expansion.
Wildcard No Data: The zone does not contain any RRsets that exactly
match <SNAME, SCLASS> and does contain one or more RRsets that
match <SNAME, SCLASS> via wildcard name expansion, but does not
contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
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
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
RRSIG RR(s) in the Authority section of the response (see Section
3.1.1). If space does not permit inclusion of the NSEC RR or its
associated RRSIG RR(s), the name server MUST set the TC bit (see
Section 3.1.1).
Since the search name exists, wildcard name expansion does not apply
to this query, and a single signed NSEC RR suffices to prove that the
requested RR type does not exist.
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 section, along
with their associated RRSIG RRs:
o An NSEC RR proving that there is no exact match for <SNAME,
SCLASS>.
o An NSEC RR proving that the zone contains no RRsets that would
match <SNAME, SCLASS> via wildcard name expansion.
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(s) once in the Authority section.
If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1).
The owner names of these NSEC and RRSIG RRs are not subject to
wildcard name expansion when these RRs are included in the Authority
section of the response.
Note that this form of response includes cases in which SNAME
corresponds to an empty non-terminal name within the zone (a name
that is not the owner name for any RRset but that is the parent name
of one or more RRsets).
3.1.3.3. Including NSEC RRs: Wildcard Answer Response
If the zone does not contain any RRsets that exactly match <SNAME,
SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
via wildcard name expansion, the name server MUST include the
wildcard-expanded answer and the corresponding wildcard-expanded
RRSIG RRs in the Answer section and MUST include in the Authority
section an NSEC RR and associated RRSIG RR(s) proving that the zone
does not contain a closer match for <SNAME, SCLASS>. If space does
not permit inclusion of the answer, NSEC and RRSIG RRs, the name
server MUST set the TC bit (see Section 3.1.1).
This case is a combination of the previous cases. The zone does not
contain an exact match for <SNAME, SCLASS>, and although the zone
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 section, along with
their associated RRSIG RRs:
o An NSEC RR proving that there are no RRsets matching STYPE at the
wildcard owner name that matched <SNAME, SCLASS> via wildcard
expansion.
o An NSEC RR proving that there are no RRsets in the zone that would
have been a closer match for <SNAME, SCLASS>.
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(s) once in the Authority section.
The owner names of these NSEC and RRSIG RRs are not subject to
wildcard name expansion when these RRs are included in the Authority
section of the response.
If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1).
3.1.3.5. Finding the Right NSEC RRs
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.
Locating such an NSEC RR within an authoritative zone is relatively
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
written for clarity, not for efficiency.
To find the NSEC that proves that no RRsets matching name N exist in
the zone Z that would have held them, construct a sequence, S,
consisting of the owner names of every RRset in Z, sorted into
canonical order ([RFC4034]), with no duplicate names. Find the name
M that would have immediately preceded N in S if any RRsets with
owner name N had existed. M is the owner name of the NSEC RR that
proves that no RRsets exist with owner name N.
The algorithm for finding the NSEC RR that proves that a given name
is not covered by any applicable wildcard is similar but requires an
extra step. More precisely, the algorithm for finding the NSEC
proving that no RRsets exist with the applicable wildcard name is
precisely the same as the algorithm for finding the NSEC RR that
proves that RRsets with any other owner name do not exist. The part
that's missing is a method of determining the name of the non-
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
lookup algorithm described in Section 4.3.2 of [RFC1034].
3.1.4. Including DS RRs in a Response
When responding to a query that has the DO bit set, a security-aware
authoritative name server returning a referral includes DNSSEC data
along with the NS RRset.
If a DS RRset is present at the delegation point, the name server
MUST return both the DS RRset and its associated RRSIG RR(s) in the
Authority section along with the NS RRset.
If no DS RRset is present at the delegation point, the name server
MUST return both the NSEC RR that proves that the DS RRset is not
present and the NSEC RR's associated RRSIG RR(s) along with the NS
RRset. The name server MUST place the NS RRset before the NSEC RRset
and its associated RRSIG RR(s).
Including these DS, NSEC, and RRSIG RRs increases the size of
referral messages and may cause some or all glue RRs to be omitted.
If space does not permit inclusion of the DS or NSEC RRset and
associated RRSIG RRs, the name server MUST set the TC bit (see
Section 3.1.1).
3.1.4.1. Responding to Queries for DS RRs
The DS resource record type is unusual in that it appears only on the
parent zone's side of a zone cut. For example, the DS RRset for the
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 rules but the child zone does not contain the DS RRset.
A security-aware resolver sends queries to the parent zone when
looking for a needed DS RR at a delegation point (see Section 4.2).
However, special rules are necessary to avoid confusing
security-oblivious resolvers which might become involved in
processing such a query (for example, in a network configuration that
forces a security-aware resolver to channel its queries through a
security-oblivious recursive name server). The rest of this section
describes how a security-aware name server processes DS queries in
order to avoid this problem.
The need for special processing by a security-aware name server only
arises when all the following conditions are met:
o The name server has received a query for the DS RRset at a zone
cut.
o The name server is authoritative for the child zone.
o The name server is not authoritative for the parent zone.
o The name server does not offer recursion.
In all other cases, the name server either has some way of obtaining
the DS RRset or could not have been expected to have the DS RRset
even by the pre-DNSSEC processing rules, so the name server can
return either the DS RRset or an error response according to the
normal processing rules.
If all the above conditions are met, however, the name server is
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 RRset does not exist in the child zone's
apex. See Appendix B.8 for an example of such a response.
3.1.5. Responding to Queries for Type AXFR or IXFR
DNSSEC does not change the DNS zone transfer process. A signed zone
will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
records have no special meaning with respect to a zone transfer
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 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 MUST NOT selectively
reject some RRs and accept others.
DS RRsets appear only on the parental side of a zone cut and are
authoritative data in the parent zone. As with any other
authoritative RRset, the DS RRset MUST be included in zone transfers
of the zone in which the RRset is authoritative data. In the case of
the DS RRset, this is the parent zone.
NSEC RRs appear in both the parent and child zones at a zone cut and
are authoritative data in both the parent and child zones. The
parental and child NSEC RRs at a zone cut are never identical to each
other, as the NSEC RR in the child zone's apex will always indicate
the presence of the child zone's SOA RR whereas the parental NSEC RR
at the zone cut will never indicate the presence of an SOA RR. As
with any other authoritative RRs, NSEC RRs MUST be included in zone
transfers of the zone in which they are authoritative data. The
parental NSEC RR at a zone cut MUST be included in zone transfers of
the parent zone, and the NSEC at the zone apex of the child zone MUST
be included in zone transfers of the child zone.
RRSIG RRs appear in both the parent and child zones at a zone cut and
are authoritative in whichever zone contains the authoritative RRset
for which the RRSIG RR provides the signature. That is, the RRSIG RR
for a DS RRset or a parental NSEC RR at a zone cut will be
authoritative in the parent zone, and the RRSIG for any RRset in the
child zone's apex will be authoritative in the child zone. Parental
and child RRSIG RRs at a zone cut will never be identical to each
other, as the Signer's Name field of an RRSIG RR in the child zone's
apex will indicate a DNSKEY RR in the child zone's apex whereas the
same field of a parental RRSIG RR at the zone cut will indicate a
DNSKEY RR in the parent zone's apex. As with any other authoritative
RRs, RRSIG RRs MUST be included in zone transfers of the zone in
which they are authoritative data.
3.1.6. The AD and CD Bits in an Authoritative Response
The CD and AD bits are designed for use in communication between
security-aware resolvers and security-aware recursive name servers.
These bits are for the most part not relevant to query processing by
security-aware authoritative name servers.
A security-aware name server does not perform signature validation
for authoritative data during query processing, even when the CD bit
is clear. A security-aware name server SHOULD clear the CD bit when
composing an authoritative response.
A security-aware 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
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 transfer
mechanism) and MUST NOT do so unless this behavior has been
configured explicitly.
A security-aware name server that supports recursion MUST follow the
rules for the CD and AD bits given in Section 3.2 when generating a
response that involves data obtained via recursion.
3.2. Recursive Name Servers
As explained in [RFC4033], a security-aware recursive name server is
an entity that acts in both the security-aware name server and
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 that implements the
security-aware name server role and the code that implements the
security-aware resolver role, respectively.
The resolver side follows the usual rules for caching and negative
caching that would apply to any security-aware resolver.
The resolver side of a security-aware recursive name server MUST set
the 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 is not set, the name server side
MUST strip any authenticating DNSSEC RRs from the response but MUST
NOT strip any DNSSEC RR types that the initiating query explicitly
requested.
The CD bit exists in order to allow a security-aware resolver to
disable signature validation in a security-aware name server's
processing of a particular query.
The name server side MUST copy the setting of the CD bit from a query
to the corresponding response.
The name server side of a security-aware recursive name server MUST
pass the state of the CD bit to the resolver side along with the rest
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 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 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, the
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, the name server side's response depends on
the state of the CD bit in the original query. If the CD bit is set,
the name server side SHOULD return the data from the BAD cache; if
the CD bit is not set, the name server side MUST return RCODE 2
(server failure).
The intent of the above rule is to provide the raw data to clients
that are capable of performing their own signature verification
checks while protecting 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 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's clock may be set incorrectly, or the 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 validation from ever seeing
the "bad" data does not help the client.
The name server side of a security-aware recursive 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. 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
relevant negative response RRs in the Authority section to be
authentic. The resolver side MUST follow the procedure described in
Section 5 to determine whether the RRs in question are authentic.
However, for backward compatibility, a recursive name server MAY set
the AD bit when a response includes unsigned CNAME RRs if those CNAME
RRs demonstrably could have been synthesized from an authentic DNAME
RR that is also included in the response according to the synthesis
rules described in [RFC2672].
3.3. Example DNSSEC Responses
See Appendix B for example response packets.
