The Key Tag field contains the key tag value of the DNSKEY RR that
validates this signature, in network byte order. Appendix B explains
how to calculate Key Tag values.
3.1.7. The Signer’s Name Field
The Signer’s Name field value identifies the owner name of the DNSKEY
RR that a validator is supposed to use to validate this signature.
The Signer’s Name field MUST contain the name of the zone of the
covered RRset. A sender MUST NOT use DNS name compression on the
Signer’s Name field when transmitting a RRSIG RR.
3.1.8. The Signature Field
The Signature field contains the cryptographic signature that covers
the RRSIG RDATA (excluding the Signature field) and the RRset
specified by the RRSIG owner name, RRSIG class, and RRSIG Type
Covered field. The format of this field depends on the algorithm in
use, and these formats are described in separate companion documents.
3.1.8.1. Signature Calculation
A signature covers the RRSIG RDATA (excluding the Signature Field)
and covers the data RRset specified by the RRSIG owner name, RRSIG
class, and RRSIG Type Covered fields. The RRset is in canonical form
(see Section 6), and the set RR(1),...RR(n) is signed as follows:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
"|" denotes concatenation;
RRSIG_RDATA is the wire format of the RRSIG RDATA fields
with the Signer’s Name field in canonical form and
the Signature field excluded;
RR(i) = owner | type | class | TTL | RDATA length | RDATA
"owner" is the fully qualified owner name of the RRset in
canonical form (for RRs with wildcard owner names, the
wildcard label is included in the owner name);
Each RR MUST have the same owner name as the RRSIG RR;
Each RR MUST have the same class as the RRSIG RR;
Each RR in the RRset MUST have the RR type listed in the
RRSIG RR’s Type Covered field;
Each RR in the RRset MUST have the TTL listed in the
RRSIG Original TTL Field;
Any DNS names in the RDATA field of each RR MUST be in
canonical form; and
The RRset MUST be sorted in canonical order.
See Sections 6.2 and 6.3 for details on canonical form and ordering
of RRsets.
3.2. The RRSIG RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Type Covered field is represented as an RR type mnemonic. When
the mnemonic is not known, the TYPE representation as described in
[RFC3597], Section 5, MUST be used.
The Algorithm field value MUST be represented either as an unsigned
decimal integer or as an algorithm mnemonic, as specified in Appendix
A.1.
The Labels field value MUST be represented as an unsigned decimal
integer.
The Original TTL field value MUST be represented as an unsigned
decimal integer.
The Signature Expiration Time and Inception Time field values MUST be
represented either as an unsigned decimal integer indicating seconds
since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
UTC, where:
YYYY is the year (0001-9999, but see Section 3.1.5);
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and
SS is the second (00-59).
Note that it is always possible to distinguish between these two
formats because the YYYYMMDDHHmmSS format will always be exactly 14
digits, while the decimal representation of a 32-bit unsigned integer
can never be longer than 10 digits.
The Key Tag field MUST be represented as an unsigned decimal integer.
The Signer’s Name field value MUST be represented as a domain name.
The Signature field is represented as a Base64 encoding of the
signature. Whitespace is allowed within the Base64 text. See
Section 2.2.
3.3. RRSIG RR Example
The following RRSIG RR stores the signature for the A RRset of
host.example.com:
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
The first four fields specify the owner name, TTL, Class, and RR type
(RRSIG). The "A" represents the Type Covered field. The value 5
identifies the algorithm used (RSA/SHA1) to create the signature.
The value 3 is the number of Labels in the original owner name. The
value 86400 in the RRSIG RDATA is the Original TTL for the covered A
RRset. 20030322173103 and 20030220173103 are the expiration and
inception dates, respectively. 2642 is the Key Tag, and example.com.
is the Signer’s Name. The remaining text is a Base64 encoding of the
signature.
Note that combination of RRSIG RR owner name, class, and Type Covered
indicates that this RRSIG covers the "host.example.com" A RRset. The
Label value of 3 indicates that no wildcard expansion was used. The
Algorithm, Signer’s Name, and Key Tag indicate that this signature
can be authenticated using an example.com zone DNSKEY RR whose
algorithm is 5 and whose key tag is 2642.
4. The NSEC Resource Record
The NSEC resource record lists two separate things: the next owner
name (in the canonical ordering of the zone) that contains
authoritative data or a delegation point NS RRset, and the set of RR
types present at the NSEC RR’s owner name [RFC3845]. The complete
set of NSEC RRs in a zone indicates which authoritative RRsets exist
in a zone and also form a chain of authoritative owner names in the
zone. This information is used to provide authenticated denial of
existence for DNS data, as described in [RFC4035].
Because every authoritative name in a zone must be part of the NSEC
chain, NSEC RRs must be present for names containing a CNAME RR.
This is a change to the traditional DNS specification [RFC1034],
which stated that if a CNAME is present for a name, it is the only
type allowed at that name. An RRSIG (see Section 3) and NSEC MUST
exist for the same name as does a CNAME resource record in a signed
zone.
See [RFC4035] for discussion of how a zone signer determines
precisely which NSEC RRs it has to include in a zone.
The type value for the NSEC RR is 47.
The NSEC RR is class independent.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching ([RFC2308]).
4.1. NSEC RDATA Wire Format
The RDATA of the NSEC RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. The Next Domain Name Field
The Next Domain field contains the next owner name (in the canonical
ordering of the zone) that has authoritative data or contains a
delegation point NS RRset; see Section 6.1 for an explanation of
canonical ordering. The value of the Next Domain Name field in the
last NSEC record in the zone is the name of the zone apex (the owner
name of the zone’s SOA RR). This indicates that the owner name of
the NSEC RR is the last name in the canonical ordering of the zone.
A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR.
Owner names of RRsets for which the given zone is not authoritative
(such as glue records) MUST NOT be listed in the Next Domain Name
unless at least one authoritative RRset exists at the same owner
name.
4.1.2. The Type Bit Maps Field
The Type Bit Maps field identifies the RRset types that exist at the
NSEC RR’s owner name.
The RR type space is split into 256 window blocks, each representing
the low-order 8 bits of the 16-bit RR type space. Each block that
has at least one active RR type is encoded using a single octet
window number (from 0 to 255), a single octet bitmap length (from 1
to 32) indicating the number of octets used for the window block’s
bitmap, and up to 32 octets (256 bits) of bitmap.
Blocks are present in the NSEC RR RDATA in increasing numerical
order.
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
where "|" denotes concatenation.
Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
to RR type 2 (NS), and so forth. For window block 1, bit 1
corresponds to RR type 257, and bit 2 to RR type 258. If a bit is
set, it indicates that an RRset of that type is present for the NSEC
RR’s owner name. If a bit is clear, it indicates that no RRset of
that type is present for the NSEC RR’s owner name.
Bits representing pseudo-types MUST be clear, as they do not appear
in zone data. If encountered, they MUST be ignored upon being read.
Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of each block’s
bitmap is determined by the type code with the largest numerical
value, within that block, among the set of RR types present at the
NSEC RR’s owner name. Trailing zero octets not specified MUST be
interpreted as zero octets.
The bitmap for the NSEC RR at a delegation point requires special
attention. Bits corresponding to the delegation NS RRset and the RR
types 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.
A zone MUST NOT include an NSEC RR for any domain name that only
holds glue records.
4.1.3. Inclusion of Wildcard Names in NSEC RDATA
If a wildcard owner name appears in a zone, the wildcard label ("*")
is treated as a literal symbol and is treated the same as any other
owner name for the purposes of generating NSEC RRs. Wildcard owner
names appear in the Next Domain Name field without any wildcard
expansion. [RFC4035] describes the impact of wildcards on
authenticated denial of existence.
4.2. The NSEC RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Next Domain Name field is represented as a domain name.
The Type Bit Maps field is represented as a sequence of RR type
mnemonics. When the mnemonic is not known, the TYPE representation
described in [RFC3597], Section 5, MUST be used.
4.3. NSEC RR Example
The following NSEC RR identifies the RRsets associated with
alfa.example.com. and identifies the next authoritative name after
alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )
The first four text fields specify the name, TTL, Class, and RR type
(NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
and TYPE1234 RRsets associated with the name alfa.example.com.
The RDATA section of the NSEC RR above would be encoded as:
0x04 ’h’ ’o’ ’s’ ’t’
0x07 ’e’ ’x’ ’a’ ’m’ ’p’ ’l’ ’e’
0x03 ’c’ ’o’ ’m’ 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
Assuming that the validator can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or to
prove that there is no AAAA record associated with alfa.example.com.
Authenticated denial of existence is discussed in [RFC4035].
5. The DS Resource Record
The DS Resource Record refers to a DNSKEY RR and is used in the DNS
DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
storing the key tag, algorithm number, and a digest of the DNSKEY RR.
Note that while the digest should be sufficient to identify the
public key, storing the key tag and key algorithm helps make the
identification process more efficient. By authenticating the DS
record, a resolver can authenticate the DNSKEY RR to which the DS
record points. The key authentication process is described in
[RFC4035].
The DS RR and its corresponding DNSKEY RR have the same owner name,
but they are stored in different locations. The DS RR appears only
on the upper (parental) side of a delegation, and is authoritative
data in the parent zone. For example, the DS RR for "example.com" is
stored in the "com" zone (the parent zone) rather than in the
"example.com" zone (the child zone). The corresponding DNSKEY RR is
stored in the "example.com" zone (the child zone). This simplifies
DNS zone management and zone signing but introduces special response
processing requirements for the DS RR; these are described in
[RFC4035].
The type number for the DS record is 43.
The DS resource record is class independent.
The DS RR has no special TTL requirements.
5.1. DS RDATA Wire Format
The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
Algorithm field, a 1 octet Digest Type field, and a Digest field.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1. The Key Tag Field
The Key Tag field lists the key tag of the DNSKEY RR referred to by
the DS record, in network byte order.
The Key Tag used by the DS RR is identical to the Key Tag used by
RRSIG RRs. Appendix B describes how to compute a Key Tag.
5.1.2. The Algorithm Field
The Algorithm field lists the algorithm number of the DNSKEY RR
referred to by the DS record.
The algorithm number used by the DS RR is identical to the algorithm
number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the
algorithm number types.
5.1.3. The Digest Type Field
The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
RR. The Digest Type field identifies the algorithm used to construct
the digest. Appendix A.2 lists the possible digest algorithm types.
5.1.4. The Digest Field
The DS record refers to a DNSKEY RR by including a digest of that
DNSKEY RR.
The digest is calculated by concatenating the canonical form of the
fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
and then applying the digest algorithm.
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
"|" denotes concatenation
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
The size of the digest may vary depending on the digest algorithm and
DNSKEY RR size. As of the time of this writing, the only defined
digest algorithm is SHA-1, which produces a 20 octet digest.
5.2. Processing of DS RRs When Validating Responses
The DS RR links the authentication chain across zone boundaries, so
the DS RR requires extra care in processing. The DNSKEY RR referred
to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
used in the validation process.
5.3. The DS RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Key Tag field MUST be represented as an unsigned decimal integer.
The Algorithm field MUST be represented either as an unsigned decimal
integer or as an algorithm mnemonic specified in Appendix A.1.
The Digest Type field MUST be represented as an unsigned decimal
integer.
The Digest MUST be represented as a sequence of case-insensitive
hexadecimal digits. Whitespace is allowed within the hexadecimal
text.
5.4. DS RR Example
The following example shows a DNSKEY RR and its corresponding DS RR.
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )
The first four text fields specify the name, TTL, Class, and RR type
(DS). Value 60485 is the key tag for the corresponding
"dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
used by this "dskey.example.com." DNSKEY RR. The value 1 is the
algorithm used to construct the digest, and the rest of the RDATA
text is the digest in hexadecimal.
6. Canonical Form and Order of Resource Records
This section defines a canonical form for resource records, a
canonical ordering of DNS names, and a canonical ordering of resource
records within an RRset. A canonical name order is required to
construct the NSEC name chain. A canonical RR form and ordering
within an RRset are required in order to construct and verify RRSIG
RRs.
6.1. Canonical DNS Name Order
For the purposes of DNS security, owner names are ordered by treating
individual labels as unsigned left-justified octet strings. The
absence of a octet sorts before a zero value octet, and uppercase
US-ASCII letters are treated as if they were lowercase US-ASCII
letters.
To compute the canonical ordering of a set of DNS names, start by
sorting the names according to their most significant (rightmost)
labels. For names in which the most significant label is identical,
continue sorting according to their next most significant label, and
so forth.
For example, the following names are sorted in canonical DNS name
order. The most significant label is "example". At this level,
"example" sorts first, followed by names ending in "a.example", then
by names ending "z.example". The names within each level are sorted
in the same way.
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example
6.2. Canonical RR Form
For the purposes of DNS security, the canonical form of an RR is the
wire format of the RR where:
1. every domain name in the RR is fully expanded (no DNS name
compression) and fully qualified;
2. all uppercase US-ASCII letters in the owner name of the RR are
replaced by the corresponding lowercase US-ASCII letters;
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
the DNS names contained within the RDATA are replaced by the
corresponding lowercase US-ASCII letters;
4. if the owner name of the RR is a wildcard name, the owner name is
in its original unexpanded form, including the "*" label (no
wildcard substitution); and
5. the RR’s TTL is set to its original value as it appears in the
originating authoritative zone or the Original TTL field of the
covering RRSIG RR.
6.3. Canonical RR Ordering within an RRset
For the purposes of DNS security, RRs with the same owner name,
class, and type are sorted by treating the RDATA portion of the
canonical form of each RR as a left-justified unsigned octet sequence
in which the absence of an octet sorts before a zero octet.
[RFC2181] specifies that an RRset is not allowed to contain duplicate
records (multiple RRs with the same owner name, class, type, and
RDATA). Therefore, if an implementation detects duplicate RRs when
putting the RRset in canonical form, it MUST treat this as a protocol
error. If the implementation chooses to handle this protocol error