DNSSEC introduces the concept of signed zones. A signed zone
includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
respectively. A zone that does not include these records according
to the rules in this section is an unsigned zone.
DNSSEC requires a change to the definition of the CNAME resource
record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG
and NSEC RRs to appear at the same owner name as does a CNAME RR.
DNSSEC specifies the placement of two new RR types, NSEC and DS,
which can be placed at the parental side of a zone cut (that is, at a
delegation point). This is an exception to the general prohibition
against putting data in the parent zone at a zone cut. Section 2.6
describes this change.
2.1. Including DNSKEY RRs in a Zone
To sign a zone, the zone's administrator generates one or more
public/private key pairs and uses the private key(s) to sign
authoritative RRsets in the zone. For each private key used to
create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
containing the corresponding public key. A zone key DNSKEY RR MUST
have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
of [RFC4034]). Public keys associated with other DNS operations MAY
be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
be used to verify RRSIGs.
If the zone administrator intends a signed zone to be usable other
than as an island of security, the zone apex MUST contain at least
one DNSKEY RR to act as a secure entry point into the zone. This
secure entry point could then be used as the target of a secure
delegation via a corresponding DS RR in the parent zone (see
[RFC4034]).
2.2. Including RRSIG RRs in a Zone
For each authoritative RRset in a signed zone, there MUST be at least
one RRSIG record that meets the following requirements:
o The RRSIG owner name is equal to the RRset owner name.
o The RRSIG class is equal to the RRset class.
o The RRSIG Type Covered field is equal to the RRset type.
o The RRSIG Original TTL field is equal to the TTL of the RRset.
o The RRSIG RR's TTL is equal to the TTL of the RRset.
o The RRSIG Labels field is equal to the number of labels in the
RRset owner name, not counting the null root label and not
counting the leftmost label if it is a wildcard.
o The RRSIG Signer's Name field is equal to the name of the zone
containing the RRset.
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
zone key DNSKEY record at the zone apex.
The process for constructing the RRSIG RR for a given RRset is
described in [RFC4034]. An RRset MAY have multiple RRSIG RRs
associated with it. Note that as RRSIG RRs are closely tied to the
RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
RR types, do not form RRsets. In particular, the TTL values among
RRSIG RRs with a common owner name do not follow the RRset rules
described in [RFC2181].
An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
add no value and would create an infinite loop in the signing
process.
The NS RRset that appears at the zone apex name MUST be signed, but
the NS RRsets that appear at delegation points (that is, the NS
RRsets in the parent zone that delegate the name to the child zone's
name servers) MUST NOT be signed. Glue address RRsets associated
with delegations MUST NOT be signed.
There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
itself MUST be signed by each algorithm appearing in the DS RRset
located at the delegating parent (if any).
2.3. Including NSEC RRs in a Zone
Each owner name in the zone that has authoritative data or a
delegation point NS RRset MUST have an NSEC resource record. The
format of NSEC RRs and the process for constructing the NSEC RR for a
given name is described in [RFC4034].
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
value field in the zone SOA RR.
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
RRset at any particular owner name. That is, the signing process
MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
the owner name of any RRset before the zone was signed. The main
reasons for this are a desire for namespace consistency between
signed and unsigned versions of the same zone and a desire to reduce
the risk of response inconsistency in security oblivious recursive
name servers.
The type bitmap of every NSEC resource record in a signed zone MUST
indicate the presence of both the NSEC record itself and its
corresponding RRSIG record.
The difference between the set of owner names that require RRSIG
records and the set of owner names that require NSEC records is
subtle and worth highlighting. RRSIG records are present at the
owner names of all authoritative RRsets. NSEC records are present at
the owner names of all names for which the signed zone is
authoritative and also at the owner names of delegations from the
signed zone to its children. Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address
RRsets. Note, however, that this distinction is for the most part
visible only during the zone signing process, as NSEC RRsets are
authoritative data and are therefore signed. Thus, any owner name
that has an NSEC RRset will have RRSIG RRs as well in the signed
zone.
The bitmap for the NSEC RR at a delegation point requires special
attention. Bits corresponding to the delegation NS RRset and any
RRsets for which the parent zone has authoritative data MUST be set;
bits corresponding to any non-NS RRset for which the parent is not
authoritative MUST be clear.
2.4. Including DS RRs in a Zone
The DS resource record establishes authentication chains between DNS
zones. A DS RRset SHOULD be present at a delegation point when the
child zone is signed. The DS RRset MAY contain multiple records,
each referencing a public key in the child zone used to verify the
RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS
RRsets MUST NOT appear at a zone's apex.
A DS RR SHOULD point to a DNSKEY RR that is present in the child's
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
by the corresponding private key. DS RRs that fail to meet these
conditions are not useful for validation, but because the DS RR and
its corresponding DNSKEY RR are in different zones, and because the
DNS is only loosely consistent, temporary mismatches can occur.
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
(that is, the NS RRset from the same zone containing the DS RRset).
Construction of a DS RR requires knowledge of the corresponding
DNSKEY RR in the child zone, which implies communication between the
child and parent zones. This communication is an operational matter
not covered by this document.
If a CNAME RRset is present at a name in a signed zone, appropriate
RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
name for secure dynamic update purposes is also allowed ([RFC3007]).
Other types MUST NOT be present at that name.
This is a modification to the original CNAME definition given in
[RFC1034]. The original definition of the CNAME RR did not allow any
other types to coexist with a CNAME record, but a signed zone
requires NSEC and RRSIG RRs for every authoritative name. To resolve
this conflict, this specification modifies the definition of the
CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
2.6. DNSSEC RR Types Appearing at Zone Cuts
DNSSEC introduced two new RR types that are unusual in that they can
appear at the parental side of a zone cut. At the parental side of a
zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
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
specification ([RFC1034]), which states that only NS RRsets could
appear at the parental side of a zone cut.
This specification updates the original DNS specification to allow
NSEC and DS RR types at the parent side of a zone cut. These RRsets
are authoritative for the parent when they appear at the parent side
of a zone cut.
Appendix A shows a complete example of a small signed zone.
