Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Eastlake, 3rd
Request for Comments: 2065 CyberCash
Updates: 1034, 1035 C. Kaufman
Category: Standards Track Iris
January 1997
Abstract
The Domain Name System (DNS) has become a critical operational part
of the Internet infrastructure yet it has no strong security
mechanisms to assure data integrity or authentication. Extensions to
the DNS are described that provide these services to security aware
resolvers or applications through the use of cryptographic digital
signatures. These digital signatures are included in secured zones
as resource records. Security can still be provided even through
non-security aware DNS servers in many cases.
Acknowledgments
The significant contributions of the following persons (in alphabetic
order) to this document are gratefully acknowledged:
Harald T. Alvestrand
Madelyn Badger
Scott Bradner
Matt Crawford
James M. Galvin
Olafur Gudmundsson
Edie Gunter
Sandy Murphy
Masataka Ohta
Michael A. Patton
Jeffrey I. Schiller
Table of Contents
1. Overview of Contents....................................3
2. Overview of the DNS Extensions.........................4
2.1 Services Not Provided..................................4
2.2 Key Distribution.......................................5
2.3 Data Origin Authentication and Integrity...............5
2.3.1 The SIG Resource Record..............................6
2.3.2 Authenticating Name and Type Non-existence...........7
2.3.3 Special Considerations With Time-to-Live.............7
2.3.4 Special Considerations at Delegation Points..........7
2.3.5 Special Considerations with CNAME RRs................8
2.3.6 Signers Other Than The Zone..........................8
2.4 DNS Transaction and Request Authentication.............8
3. The KEY Resource Record.................................9
3.1 KEY RDATA format......................................10
3.2 Object Types, DNS Names, and Keys.....................10
3.3 The KEY RR Flag Field.................................11
3.4 The Protocol Octet....................................13
3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....13
3.6 Interaction of Flags, Algorithm, and Protocol Bytes...14
3.7 KEY RRs in the Construction of Responses..............15
3.8 File Representation of KEY RRs........................16
4. The SIG Resource Record................................16
4.1 SIG RDATA Format......................................17
4.1.1 Signature Data......................................19
4.1.2 MD5/RSA Algorithm Signature Calculation.............20
4.1.3 Zone Transfer (AXFR) SIG............................21
4.1.4 Transaction and Request SIGs........................22
4.2 SIG RRs in the Construction of Responses..............23
4.3 Processing Responses and SIG RRs......................24
1. Overview of Contents
Section 5 discusses the NXT resource record and its use in DNS
responses. The NXT RR permits authenticated denial in the DNS of the
existence of a name or of a particular type for an existing name.
Resource records (RRs) are defined to associate keys with DNS names.
This permits the DNS to be used as a public key distribution
mechanism in support of the DNS data origin authentication and other
security services.
This data origin authentication key belongs to the zone and not to
the servers that store copies of the data. That means compromise of
a server or even all servers for a zone will not necessarily affect
the degree of assurance that a resolver has that it can determine
whether data is genuine.
The above security mechanism provides only a way to sign existing RRs
in a zone. "Data origin" authentication is not obviously provided
for the non-existence of a domain name in a zone or the non-existence
of a type for an existing name. This gap is filled by the NXT RR
which authenticatably asserts a range of non-existent names in a zone
and the non-existence of types for the name just before that range.
There are two cases where a SIG resource record is signed by other
than the zone private key. One is for support of dynamic update
where an entity is permitted to authenticate/update its own records.
The public key of the entity must be present in the DNS and be
appropriately signed but the other RR(s) may be signed with the
entity's key. The other is for support of transaction and request
authentication as described in Section 2.4 immediately below.
If header bits are falsely set by a server, there is little that can
be done. However, it is possible to add transaction authentication.
Such authentication means that a resolver can be sure it is at least
getting messages from the server it thinks it queried, that the
response is from the query it sent, and that these messages have not
been diddled in transit. This is accomplished by optionally adding a
special SIG resource record at the end of the reply which digitally
signs the concatenation of the server's response and the resolver's
query.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The meaning of the KEY RR owner name, flags, and protocol octet are
described in Sections 3.2, 3.3 and 3.4 below respectively. The flags
and algorithm must be examined before any data following the
algorithm octet as they control the format and even whether there is
any following data. The algorithm and public key fields are
described in Section 3.5. The format of the public key is algorithm
dependent.
The public key in a KEY RR belongs to the object named in the owner
name.
Although the same name can be used for up to all three of these
categories, such overloading of a name is discouraged. It is also
possible to use the same key for different things with the same name
or even different names, but this is strongly discouraged. In
particular, the use of a zone key as a non-zone key will usually
require that the corresponding private key be kept on line and
thereby become more vulnerable.
In addition to the name type bits, there are additional flag bits
including the "type" field, "experimental" bit, "signatory" field,
etc., as described below.
Bit 0 and 1 are the key "type" field. Bit 0 a one indicates
that use of the key is prohibited for authentication. Bit 1 a one
indicates that use of the key is prohibited for confidentiality. If
this field is zero, then use of the key for authentication and/or
confidentiality is permitted. Note that DNS security makes use of
keys for authentication only. Confidentiality use flagging is
provided for use of keys in other protocols. Implementations not
intended to support key distribution for confidentiality MAY require
that the confidentiality use prohibited bit be on for keys they
serve. If both bits of this field are one, the "no key" value, there
is no key information and the RR stops after the algorithm octet. By
the use of this "no key" value, a signed KEY RR can authenticatably
assert that, for example, a zone is not secured.
Bit 7 is the "zone" bit and indicates that this is a zone key
for the zone whose name is the KEY RR owner name. This is the public
key used for DNS data origin authentication.
This octet is the key algorithm parallel to the same field for the
SIG resource. The MD5/RSA algorithm described in this document is
number 1. Numbers 2 through 252 are available for assignment should
sufficient reason arise. However, the designation of a new algorithm
could have a major impact on interoperability and requires an IETF
standards action. Number 254 is reserved for private use and will
never be assigned a specific algorithm. For number 254, the public
key area shown in the packet diagram 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 is
If the type field does not have the "no key" value and the algorithm
field is 1, indicating the MD5/RSA algorithm, the public key field is
structured as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pub exp length| public key exponent /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
+- modulus /
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
AL PR NK Meaning
0 0 0 Illegal, claims key but has bad algorithm field.
0 0 1 Specifies total lack of security for owner.
0 x 0 Illegal, claims key but has bad algorithm field.
0 x 1 Specified protocols insecure, others may be secure.
x 0 0 Useless. Gives key but no protocols to use it.
x 0 1 Useless. Denies key but for no protocols.
x x 0 Specifies key for protocols and asserts that
those protocols are implemented with security.
x x 1 Algorithm not understood for protocol.
An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG
RR from a security aware server.
(1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone
served by these name servers MUST be included as additional
information if space is avilable. There will always be at least one
such KEY RR in a secure zone, even if it has the no-key type value to
indicate that the subzone is insecure. If not all additional
information will fit, the KEY RR(s) have higher priority than type A
or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the
retrieval must be considered truncated.
(2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST
be included if space is available. On inclusion of A or AAAA RRs as
additional information, their KEY RRs will also be included but with
lower priority than the relevant A or AAAA RRs.
The flag field, protocol, and algorithm number octets are then
represented as unsigned integers. Note that if the type field has
the "no key" value or the algorithm specified is 253, nothing appears
after the algorithm octet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time signed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key footprint | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
+- signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "type covered" is the type of the other RRs covered by this SIG.
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
signed data.
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. |
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
with.
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
network.
where "|" is concatenation, RDATA is all the RDATA fields in the SIG
RR itself before and not including the signature, and RR(s) are all
the RR(s) of the type covered with the same owner name and class as
the SIG RR in canonical form and order. How this data sequence is
processed into the signature is algorithm dependent.
For purposes of DNS security, the canonical order for RRs is to sort
them in ascending order by name, considering labels as a left
justified unsigned octet sequence in network (transmission) order
where a missing octet sorts before a zero octet. (See also ordering
discussion in Section 5.1.) Within any particular name they are
similarly sorted by type and then RDATA as a left justified unsigned
octet sequence. EXCEPT that the type SIG RR(s) covering any
particular type appear immediately after the other RRs of that type.
(This special consideration for SIG RR(s) in ordering really only
applies to calculating the AXFR SIG RR as explained in section 4.1.3
below.) Thus if at name a.b there are two A RRs and one KEY RR,
their order with SIGs for concatenating the "data" to be signed would
be as follows:
a.b. A ....
a.b. A ....
a.b. SIG A ...
a.b. KEY ...
a.b. SIG KEY ...
SIGs covering type ANY should not be included in a zone.
where MD5 is the message digest algorithm documented in RFC 1321, "|"
is concatenation, "e" is the private key exponent of the signer, and
"n" is the modulus of the signer's public key. 01, FF, and 00 are
fixed octets of the corresponding hexadecimal value. "prefix" is the
ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, that
is,
hex 3020300c06082a864886f70d020505000410 [NETSEC].
This prefix is included to make it easier to use RSAREF or similar
packages. The FF octet is repeated the maximum number of times such
that the value of the quantity being exponentiated is one octet
shorter than the value of n.
The size of n, including most and least significant bits (which will
be 1) SHALL be not less than 512 bits and not more than 2552 bits. n
and e SHOULD be chosen such that the public exponent is small.
The above SIG mechanisms assure the authentication of all zone signed
RRs of a particular name, class and type. However, to efficiently
assure the completeness and security of zone transfers, a SIG RR
owned by the zone name must be created with a type covered of AXFR
that covers all zone signed RRs in the zone and their zone SIGs but
not the SIG AXFR itself. The RRs are ordered and concatenated for
hashing as described in Section 4.1.1. (See also ordering discussion
in Section 5.1.)
The AXFR SIG must be calculated last of all zone key signed SIGs in
the zone. In effect, when signing the zone, you order, as described
above, all RRs to be signed by the zone, and all associated glue RRs
and delegation point NS RRs. You can then make one pass inserting
all the zone SIGs. As you proceed you hash RRs to be signed into
both an RRset hash and the zone hash. When the name or type changes
you calculate and insert the RRset zone SIG, clear the RRset hash,
and hash that SIG into the zone hash (note that glue RRs and
delegation point NSs are not zone signed but zone apex NSs are).
When you have finished processing all the starting RRs as described
above, you can then use the cumulative zone hash RR to calculate and
insert an AXFR SIG covering the zone. Of course any computational
technique producing the same results as above is permitted.
The AXFR SIG really belongs to the zone as a whole, not to the zone
name. Although it should be correct for the zone name, the labels
field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only
retrieved as part of a zone transfer. After validation of the AXFR
SIG, the zone MAY be considered valid without verification of the
internal zone signed SIGs in the zone; however, any RRs authenticated
by SIGs signed by entity keys or the like MUST still be validated.
The AXFR SIG SHOULD be transmitted first in a zone transfer so the
RRs which are authenticated by a dynamic update key and not by the
zone key (see Section 3.2) are not included in the AXFR SIG. They may
originate in the network and might not, in general, be migrated to
the recommended off line zone signing procedure (see Section 7.2).
Thus, such RRs are not directly signed by the zone, are not included
in the AXFR SIG, and are protected against omission from zone
transfers only to the extent that the server and communication can be
trusted.
This SIG has a "type covered" field of zero, which is not a valid RR
type. It is calculated by using a "data" (see Section 4.1.2) of the
entire preceding DNS reply message, including DNS header but not the
IP header, concatenated with the entire DNS query message that
produced this response, including the query's DNS header but not its
IP header. That is
Security aware DNS servers MUST, for every authoritative RR the query
will return, attempt to send the available SIG RRs which authenticate
the requested RR. The following rules apply to the inclusion of SIG
RRs in responses:
If all reasonable checks indicate that the SIG RR is valid then RRs
verified by it should be considered authenticated.
min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
If the original TTL, which applies to the type signed, is the same as
the TTL of the SIG RR itself, it may be omitted. The date field
which follows it is larger than the maximum possible TTL so there is
no ambiguity.
However, the signature itself can be very long. It is the last data
field and is represented in base 64 (see Appendix) and may be divided
up into any number of white space separated substrings, down to
single base 64 digits, which are concatenated to obtain the full
signature. These substrings can be split between lines using the
standard parenthesis.
NXT RRs do not appear in zone master files since they can be derived
from the rest of the zone.
The owner name of the NXT RR is an existing name in the zone. It's
RDATA is a "next" name and a type bit map. The presence of the NXT RR
means that generally no name between its owner name and the name in
its RDATA area exists and that no other zone signed types exist under
its owner name. This implies a canonical ordering of all domain
names in a zone.
The NXT RRs for a zone SHOULD be automatically calculated and added
to the zone by the same recommended off-line process that signs the
zone (see Section 7.2). The NXT RR's TTL SHOULD not exceed the zone
minimum TTL.
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 map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NXT RR type bit map is one bit per RR type present for the owner
name similar to the WKS socket bit map. The first bit represents RR
type zero (an illegal type which should not be present.) A one bit
indicates that at least one RR of that type is present for the owner
name. A zero indicates that no such RR is present. All bits not
specified because they are beyond the end of the bit map are assumed
to be zero. Note that bit 30, for NXT, will always be on so the
minimum bit map length is actually four octets. The NXT bit map
should be printed as a list of RR type mnemonics or decimal numbers
similar to the WKS RR.
The domain name may be compressed with standard DNS name compression
when being transmitted over the network. The size of the bit map can
be inferred from the RDLENGTH and the length of the next domain name.
5.3 Example
big.foo.tld,
medium.foo.tld.
small.foo.tld.
tiny.foo.tld.
If there could be any wildcard RRs in a zone and thus wildcard NXTs,
care must be taken in interpreting the results of explicit NXT
retrievals as the owner name may be a wildcard expansion.
return the wildcard match NXT instead of the more specifically named
RRs. If there is a zone wide wildcard, there will be an NXT RR whose
owner name is the wild card and whose RDATA is the zone name. In this
case a server could conceal the existence of any more specific RRs in
the zone. It would be possible to design a more strict NXT feature
which would eliminate this possibility. But it would be more complex
and might be so constraining as to make any dynamic update feature
very difficult.
In a secure zone, a resolver can query for the initial NXT associated
with the zone name. Using the next domain name RDATA field from that
RR, it can query for the next NXT RR. By repeating this, it can walk
through all the NXTs in the zone. If there are no wildcards, it can
use this technique to find all names in a zone. If it does type ANY
queries, it can incrementally get all information in the zone and
thus defeat attempts to administratively block zone transfers.
If there are any wildcards, this NXT walking technique will not find
any more specific RR names in the part of the name space the wildcard
covers. By doing explicit retrievals for wildcard names, a resolver
could determine what intervals are covered by wildcards but still
could not, with these techniques, find any names inside such
intervals except by trying every name.
A name (other than root) which is the head of a zone also appears as
the leaf in a superzone. If both are secure, there will always be
two different NXT RRs with the same name. They can be distinguished
by their signers and next domain name fields. Security aware servers
should return the correct NXT automatically when required to
authenticate the non-existence of a name and both NXTs, if available,
on explicit query for type NXT.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These bits are zero in old servers and resolvers. Thus the responses
of old servers are not flagged as authenticated to security aware
resolvers and queries from non-security aware resolvers do not assert
the checking disabled bit and thus will be answered by security aware
servers only with authenticated data. Aware resolvers MUST not trust
the AD bit unless they trust the server they are talking to and
either have a secure path to it or use DNS transaction security.
The format for a boot file directive to configure a starting zone key
is as follows:
for a public key. "name" is the owner name (if the line is
translated into a KEY RR). Flags indicates the type of key and is
the same as the flag octet in the KEY RR. Protocol and algorithm
also have the same meaning as they do in the KEY RR. The material
after the algorithm is algorithm dependent and, for private
algorithms (algorithm 254), starts with the algorithm's identifying
OID and its length. If the "no key" type value is set in flags or
the algorithm is specified as 253, then the key-data after algorithm
is null. When present the key-data is treated as an octet stream and
encoded in base 64 (see Appendix).
keyfile filename
The file looks like a master file except that it can only contain KEY
and SIG RRs with the SIGs signed under a key configured with the
pubkey directive.
While it might seem logical for everyone to start with the key for
the root zone, this has problems. The logistics of updating every
DNS resolver in the world when the root key changes would be
excessive. It may be some time before there even is a root key.
Furthermore, many organizations will explicitly wish their "interior"
DNS implementations to completely trust only their own zone. Such
interior resolvers can then go through the organization's zone
servers to access data outsize the organization's domain and should
only be configured with the key forthe organization's DNS apex.
information appearing with the NS RRs for the sub-zone. These make
it possible to descend within the tree of zones.
7. Operational Considerations
There are a number of factors that effect public key size choice for
use in the DNS security extension. Unfortunately, these factors
usually do not all point in the same direction. Choice of zone key
size should generally be made by the zone administrator depending on
their local conditions.
For most schemes, larger keys are more secure but slower. Given a
small public exponent, verification (the most common operation) for
the MD5/RSA algorithm will vary roughly with the square of the
modulus length, signing will vary with the cube of the modulus
length, and key generation (the least common operation) will vary
with the fourth power of the modulus length. The current best
algorithms for factoring a modulus and breaking RSA security vary
roughly with the 1.6 power of the modulus itself. Thus going from a
640 bit modulus to a 1280 bit modulus only increases the verification
time by a factor of 4 but increases the work factor of breaking the
key by over 2^900. An upper bound of 2552 bits has been established
for the MD5/RSA DNS security algorithm for interoperability purposes.
However, larger keys increase the size of the KEY and SIG RRs. This
increases the chance of DNS UDP packet overflow and the possible
necessity for using higher overhead TCP in responses.
It is recommended that zone private keys and the zone file master
copy be kept and used in off-line non-network connected physically
secure machines only. Periodically an application can be run to add
authentication to a zone by adding SIG and NXT RRs and adding no-key
type KEY RRs for subzones where a real KEY RR is not provided. Then
the augmented file can be transferred, perhaps by sneaker-net, to the
networked zone primary server machine.
zone master file on-line on the network and simply cycling it through
an off-line signer does not do this. The on-line version could still
be tampered with if the host it resides on is compromised. For
maximum security, the master copy of the zone file should be off net
and should not be updated based on an unsecured network mediated
communication.
Signature expiration times must be set far enough in the future that
it is quite certain that new signatures can be generated before the
old ones expire. However, setting expiration too far into the future
could, if bad data or signatures were ever generated, mean a long
time to flush such badness.
7.6 Root
It should be noted that in DNS the root is a zone unto itself. Thus
the root zone key should only be seen signing itself or signing RRs
with names one level below root, such as .aq, .edu, or .arpa.
Implementations MAY reject as bogus any purported root signature of
records with a name more than one level below root. The root zone
contains the root KEY RR signed by a SIG RR under the root key
itself.
8. Conformance
(1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
ability, given a zone file and private key, to add appropriate SIG
and NXT RRs, possibly via a separate application, (3) proper
automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
suppression of CNAME following on retrieval of the security type
RRs, (5) recognize the CD query header bit and set the AD query
header bit, as appropriate, and (6) proper handling of the two NXT
RRs at delegation points. Primary servers for secure zones MUST
be fully compliant and for completely successful secure operation,
all secondary, caching, and other servers handling the zone SHOULD
be fully compliant as well.
A basic compliance resolver can handle SIG, KEY, and NXT RRs when
they are explicitly requested.
A fully compliant resolver (1) understands KEY, SIG, and NXT RRs,
(2) maintains appropriate information in its local caches and
database to indicate which RRs have been authenticated and to what
extent they have been authenticated, (3) performs additional
queries as necessary to attempt to obtain KEY, SIG, or NXT RRs
from non-security aware servers, (4) normally sets the CD query
header bit on its queries.
9. Security Considerations
References
[RFC1305] - Mills, D., "Network Time Protocol (v3)", RFC 1305, March
1992.
Authors' Addresses
Telephone: +1 508-287-4877
+1 508-371-7148(fax)
+1 703-620-4200(main office, Reston, Virginia, USA)
EMail: dee@cybercash.com
Charles W. Kaufman
Iris Associates
1 Technology Park Drive
Westford, MA 01886 USA
Telephone: +1 508-392-5276
EMail: charlie_kaufman@iris.com
Eastlake & Kaufman Standards Track [Page 39]