The "type covered" is the type of the other RRs covered by this SIG.
The algorithm number is an octet specifying the digital signature
algorithm used parallel to the algorithm octet for the KEY RR. The
MD5/RSA algorithm described in this document is number 1. Numbers 2
through 252 are available for assignment should sufficient reason
arise to allocate them. However, the designation of a new algorithm
could have a major impact on the interoperability of the global DNS
system and requires an IETF standards action. Number 254 is reserved
for private use and will not be assigned a specific algorithm. For
number 254, the "signature" area shown above will actually begin with
a length byte followed by an Object Identifier (OID) of that length.
The OID indicates the private algorithm in use and the remainder of
the area is whatever is required by that algorithm. Number 253,
known as the "expiration date algorithm", is used when the expiration
date or other non-signature fields of the SIG are desired without any
actual security. It is anticipated that this algorithm will only be
used in connection with some modes of DNS dynamic update. For number
253, the signature field will be null. Values 0 and 255 are
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 a secured
retrieval is the result of wild card substitution, it is necessary
for the resolver to use the original form of the name in verifying
the digital signature. This field helps optimize the determination
of the original form thus reducing the effort in authenticating
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
substitution. If the 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
entire octet is reserved and would be required should DNS names ever
be expanded to 255 labels. The following table gives some examples.
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.
labels= | 0 | 1 | 2 | 3 | 4 |
.| . | bad | bad | bad | bad |
d.| *. | d. | bad | bad | bad |
c.d.| *. | *.d. | c.d. | bad | bad |
b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad |
a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
The "original TTL" field is included in the RDATA portion to avoid
(1) authentication problems that caching servers would otherwise
cause by decrementing the real TTL field and (2) security problems
that unscrupulous servers could otherwise cause by manipulating the
real TTL field. This original TTL is protected by the signature
while the current TTL field is not.
NOTE: The "original TTL" must be restored into the covered RRs when
the signature is verified. This implies that all RRs for a
particular type, name, and class must have the same TTL to start
The SIG is valid until the "signature expiration" time which is an
unsigned number of seconds since the start of 1 January 1970, 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 requests to update a zone dynamically,
monotonically increasing "time signed" dates may be necessary.
The "time signed" field is an unsigned number of seconds since the
start of 1 January 1970, GMT, ignoring leap seconds.
A SIG RR with an expiration date before the time signed must be
considered corrupt and ignored.
The "key footprint" is a 16 bit quantity that is used to help
efficiently select between multiple keys which may be applicable and
as a quick check that a public key about to be used for the
computationally expensive effort to check the signature is possibly
valid. Its exact meaning is algorithm dependent. For the MD5/RSA
algorithm, it is the next to the bottom two octets of the public key
modulus needed to decode the signature field. That is to say, the
most significant 16 of the lest significant 24 bits of the modulus in
The "signer's name" field is the domain name of the signer generating
the 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
the RR(s) being authenticated. The signer's name may be compressed
with standard DNS name compression when being transmitted over the
The structure of the "signature" field is described below.