code point 252 is designated to indicate "indirect" keys, to be
defined in a separate document, where the actual key is elsewhere.
Both the KEY and SIG RR definitions have been simplified by
eliminating the "null" algorithm 253 as defined in [RFC2065].
That algorithm had been included because at the time it was
thought it might be useful in DNS dynamic update [RFC2136]. It
was in fact not so used and it is dropped to simplify DNS
security. Howver, that algorithm number has been re-used to
indicate private algorithms where a domain name specifies the
algorithm.
5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
cover all names, including wildcards as literal names without
expansion, except for glue address records whose names would not
otherwise appear, (5b) all NXT bit map areas whose first octet has
bit zero set have been reserved for future definition, (5c) the
number of and circumstances under which an NXT must be returned in
connection with wildcard names has been extended, and (5d) in
connection with the bit map, references to the WKS RR have been
removed and verticle bars ("|") have been added between the RR
type mnemonics in the ASCII representation.
6. Information on the canonical form and ordering of RRs has been
moved into a separate Section 8.
7. A subsection covering incremental and full zone transfer has been
added in Section 5.
8. Concerning DNS chaining: Further specification and policy
recommendations on secure resolution have been added, primarily in
Section 6.3.1. It is now clearly stated that authenticated data
has a validity period of the intersection of the validity periods
of the SIG RRs in its authentication chain. The requirement to
staticly configure a superzone's key signed by a zone in all of
the zone's authoritative servers has been removed. The
recommendation to continue DNS security checks in a secure island
of DNS data that is separated from other parts of the DNS tree by
insecure zones and does not contain a zone for which a key has
been staticly configured was dropped.
9. It was clarified that the presence of the AD bit in a response
does not apply to the additional information section or to glue
address or delegation point NS RRs. The AD bit only indicates
that the answer and authority sections of the response are
authoritative.
10. It is now required that KEY RRs and NXT RRs be signed only with
zone-level keys.
11. Add IANA Considerations section and references to RFC2434.
Appendix C: Key Tag Calculation
The key tag field in the SIG RR is just a means of more efficiently
selecting the correct KEY RR to use when there is more than one KEY
RR candidate available, for example, in verifying a signature. It is
possible for more than one candidate key to have the same tag, in
which case each must be tried until one works or all fail. The
following reference implementation of how to calculate the Key Tag,
for all algorithms other than algorithm 1, is in ANSI C. It is coded
for clarity, not efficiency. (See section 4.1.6 for how to determine
the Key Tag of an algorithm 1 key.)
/* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return
value
second byte of the key tag is the least significant byte of
return value
*/
int keytag (
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */
)
{
long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFFFF;
return ac & 0xFFFF;
}
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.