Commit d42de116 authored by Mark Andrews's avatar Mark Andrews
Browse files

new draft

parent 9848aa3e
DNSOP O. Kolkman
Internet-Draft RIPE NCC
Expires: June 23, 2005 R. Gieben
Expires: September 2, 2005 R. Gieben
NLnet Labs
December 23, 2004
March 2005
DNSSEC Operational Practices
draft-ietf-dnsop-dnssec-operational-practices-03.txt
draft-ietf-dnsop-dnssec-operational-practices-04.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
......@@ -33,11 +34,11 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2005.
This Internet-Draft will expire on September 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2005).
Abstract
......@@ -51,66 +52,121 @@ Abstract
Kolkman & Gieben Expires June 23, 2005 [Page 1]
Kolkman & Gieben Expires September 2, 2005 [Page 1]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3
1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 4
3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 5
3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 5
3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 5
3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 6
3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 7
3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 9
4. Signature generation, Key Rollover and Related Policies . . . 10
4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 10
4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Difference Between ZSK and KSK Rollovers . . . . . . . 12
4.2.2 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13
4.2.3 Key-signing Key Rollovers . . . . . . . . . . . . . . 17
4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 18
4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 18
4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 19
4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 19
4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 4
1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 5
2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5
3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6
3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6
3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 6
3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 7
3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 8
3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 10
4. Signature generation, Key Rollover and Related Policies . . . 11
4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 11
4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13
4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 17
4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . . 18
4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 19
4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 19
4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 20
4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 20
4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Initial Key Exchanges and Parental Policies
Considerations . . . . . . . . . . . . . . . . . . . . 20
4.4.2 Storing Keys So Hashes Can Be Regenerated . . . . . . 20
4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 21
4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 22
7.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 24
B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 24
C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 25
D. Document Details and Changes . . . . . . . . . . . . . . . . . 26
D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 27
D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 27
D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 27
D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28
Kolkman & Gieben Expires June 23, 2005 [Page 2]
Considerations . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Storing Keys or Hashes? . . . . . . . . . . . . . . . 21
4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 22
4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1 Normative References . . . . . . . . . . . . . . . . . . . 24
7.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 25
B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 26
C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 26
D. Document Details and Changes . . . . . . . . . . . . . . . . . 29
D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29
D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29
D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29
D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29
D.5 draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30
Kolkman & Gieben Expires September 2, 2005 [Page 2]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
Intellectual Property and Copyright Statements . . . . . . . . 31
Kolkman & Gieben Expires September 2, 2005 [Page 3]
Internet-Draft DNSSEC Operational Practices March 2005
1. Introduction
......@@ -120,23 +176,23 @@ Internet-Draft DNSSEC Operational Practices December 2004
with security extensions (DNSSEC). This document translates these
experiences into a set of practices for zone administrators. At the
time of writing, there exists very little experience with DNSSEC in
production environments, this document should therefore explicitly
production environments; this document should therefore explicitly
not be seen as representing 'Best Current Practices'.
The procedures herein are focused on the maintenance of signed zones
(i.e. signing and publishing zones on authoritative servers). It is
(i.e. signing and publishing zones on authoritative servers). It is
intended that maintenance of zones such as resigning or key rollovers
be transparent to any verifying clients on the Internet.
The structure of this document is as follows. In Section 2 we
discuss the importance of keeping the "chain of trust" intact.
Aspects of key generation and storage of private keys are discussed
in Section 3, the focus in this section is mainly on the private part
in Section 3; the focus in this section is mainly on the private part
of the key(s). Section 4 describes considerations concerning the
public part of the keys. Since these public keys appear in the DNS
one has to take into account all kinds of timing issues, these are
one has to take into account all kinds of timing issues, which are
discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the
rollover, or supersession, of keys. Finally Section 4.4 discusses
rollover, or which, of keys. Finally Section 4.4 discusses
considerations on how parents deal with their children's public keys
in order to maintain chains of trust.
......@@ -144,9 +200,9 @@ Internet-Draft DNSSEC Operational Practices December 2004
Appendix C.
Since this is a document with operational suggestions and there are
no protocol specifications, the RFC2119 [6] language does not apply.
no protocol specifications, the RFC2119 [4] language does not apply.
This document obsoletes RFC2541 [1]
This document obsoletes RFC2541 [7]
1.1 The Use of the Term 'key'
......@@ -164,9 +220,9 @@ Internet-Draft DNSSEC Operational Practices December 2004
Kolkman & Gieben Expires June 23, 2005 [Page 3]
Kolkman & Gieben Expires September 2, 2005 [Page 4]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
1.2 Time Definitions
......@@ -183,15 +239,16 @@ Internet-Draft DNSSEC Operational Practices December 2004
replaced with a new signature (made with the same key). This
replacement takes place by publishing the relevant RRSIG in the
master zone file.
After one stopped publishing an RRSIG in a zone file it will
take a while before the RRSIG has actually been removed from
the DNS.
After one stopped publishing an RRSIG in a zone it may take a
while before the RRSIG has expired from caches and has actually
been removed from the DNS.
o "Key effectivity period"
The period during a key pair is effective. This period is
defined as the time between the first inception time stamp and
the last expiration date of any signature made with this key.
The period which a key pair is expected to be effective. This
period is defined as the time between the first inception time
stamp and the last expiration date of any signature made with
this key.
The key effectivity period can span multiple signature validity
intervals.
periods.
o "Maximum/Minimum Zone TTL"
The maximum or minimum value of the TTLs from the complete set
of RRs in a zone.
......@@ -199,32 +256,32 @@ Internet-Draft DNSSEC Operational Practices December 2004
2. Keeping the Chain of Trust Intact
Maintaining a valid chain of trust is important because broken chains
of trust will result in data being marked as bogus, which may cause
entire (sub)domains to become invisible to verifying clients. The
administrators of secured zones have to realize that their zone is,
to their clients, part of a chain of trust.
of trust will result in data being marked as Bogus (as defined in [2]
section 5), which may cause entire (sub)domains to become invisible
to verifying clients. The administrators of secured zones have to
realize that their zone is, to their clients, part of a chain of
trust.
As mentioned in the introduction, the procedures herein are intended
to ensure maintenance of zones, such as resigning or key rollovers,
be transparent to the verifying clients on the Internet.
will be transparent to the verifying clients on the Internet.
Administrators of secured zones will have to keep in mind that data
published on an authoritative primary server will not be immediately
seen by verifying clients; it may take some time for the data to be
transfered to other secondary authoritative nameservers, during which
period clients may be fetching data from caching non-authoritative
servers.
transfered to other secondary authoritative nameservers and clients
may be fetching data from caching non-authoritative servers.
For the verifying clients it is important that data from secured
zones can be used to build chains of trust regardless of whether the
Kolkman & Gieben Expires June 23, 2005 [Page 4]
Kolkman & Gieben Expires September 2, 2005 [Page 5]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
zones can be used to build chains of trust regardless of whether the
data came directly from an authoritative server, a caching nameserver
or some middle box. Only by carefully using the available timing
parameters can a zone administrator assure that the data necessary
......@@ -234,8 +291,8 @@ Internet-Draft DNSSEC Operational Practices December 2004
administrators of secured zones in the chain of trust. This is most
obvious in the case of a 'key compromise' when a trade off between
maintaining a valid chain of trust and replacing the compromised keys
as soon as possible, must be made. Then zone administrators will
have to make a trade off between keeping the chain of trust intact -
as soon as possible must be made. Then zone administrators will have
to make a trade off, between keeping the chain of trust intact -
thereby allowing for attacks with the compromised key - or to
deliberately break the chain of trust and making secured sub domains
invisible to security aware resolvers. Also see Section 4.3.
......@@ -250,57 +307,61 @@ Internet-Draft DNSSEC Operational Practices December 2004
The DNSSEC validation protocol does not distinguish between DNSKEYs.
All DNSKEYs can be used during the validation. In practice operators
use Key Singing and Zone Signing Keys and use the so called SEP flag
to distinguish between them during operations. The dynamics and
considerations are discussed below.
use Key Signing and Zone Signing Keys and use the so-called (Secure
Entry Point) SEP flag to distinguish between them during operations.
The dynamics and considerations are discussed below.
To make zone re-signing and key rollovers procedures easier to
To make zone resigning and key rollover procedures easier to
implement, it is possible to use one or more keys as Key Signing Keys
(KSK) these keys will only sign the apex DNSKEY RR set in a zone.
(KSK). These keys will only sign the apex DNSKEY RR set in a zone.
Other keys can be used to sign all the RRsets in a zone and are
referred to as Zone Signing Keys (ZSK). In this document we assume
that KSKs are the subset of keys that are used for key exchanges with
the parent and potentially for configuration as trusted anchors - the
so called Secure Entry Point keys (SEP). In this document we assume
a one-to-one mapping between KSK and SEP keys and we assume the SEP
flag [2] to be set on KSKs.
SEP keys. In this document we assume a one-to-one mapping between
KSK and SEP keys and we assume the SEP flag [1] to be set on all
KSKs.
3.1.1 Motivations for the KSK and ZSK Separation
Differentiating between the KSK to ZSK functions has several
Differentiating between the KSK and ZSK functions has several
advantages:
o The KSK can be made stronger (i.e. using more bits in the key
material). This has little operational impact since it is only
used to sign a small fraction of the zone data.
Kolkman & Gieben Expires June 23, 2005 [Page 5]
Kolkman & Gieben Expires September 2, 2005 [Page 6]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
o No parent/child interaction is required when ZSKs are updated.
o The KSK can be made stronger (i.e. using more bits in the key
material). This has little operational impact since it is only
used to sign a small fraction of the zone data. Also when
verifying the KSK is only used to verify the zone's keyset.
o As the KSK is only used to sign a key set, which is most probably
updated less frequently than other data in the zone, it can be
stored separately from and in a safer location than the ZSK.
o A KSK can have a longer key effectivity period.
o No parent/child interaction is required when ZSKs are updated.
The KSK is used less than ZSK, once a key set is signed with the KSK
all the keys in the key set can be used as ZSK. If a ZSK is
For almost any method of key management and zone signing the KSK is
used less frequently than the ZSK. Once a key set is signed with the
KSK all the keys in the key set can be used as ZSK. If a ZSK is
compromised, it can be simply dropped from the key set. The new key
set is then resigned with the KSK.
Given the assumption that for KSKs the SEP flag is set, the KSK can
be distinguished from a ZSK by examining the flag field in the DNSKEY
RR. If the flag field is an odd number it is a KSK if it is an even
number it is a ZSK.
RR. If the flag field is an odd number it is a KSK. If it is an
even number it is a ZSK.
The zone-signing key can be used to sign all the data in a zone on a
regular basis. When a zone-signing key is to be rolled, no
interaction with the parent is needed. This allows for "Signature
Validity Periods" in the order of days.
Validity Periods" on the order of days.
The key-signing key is only to be used to sign the DNSKEY RRs in a
zone. If a key-signing key is to be rolled over, there will be
......@@ -310,8 +371,8 @@ Internet-Draft DNSSEC Operational Practices December 2004
trusted entry points. Hence, the key effectivity period of these
keys can and should be made much longer. Although, given a long
enough key, the Key Usage Time can be on the order of years we
suggest to plan for a key effectivity of the order of a few months so
that a key rollover remains an operational routine.
suggest planning for a key effectivity of the order of a few months
so that a key rollover remains an operational routine.
3.1.2 KSKs for high level zones
......@@ -324,25 +385,25 @@ Internet-Draft DNSSEC Operational Practices December 2004
The root zone is the most critical of all zones. Someone controlling
or compromising the security of the root zone would control the
entire DNS name space of all resolvers using that root zone (except
in the case of resolvers that have locally configured the public key
of a sub domain). Therefore, the utmost care must be taken in the
securing of the root zone. The strongest and most carefully handled
keys should be used. The root zone private key should always be kept
Kolkman & Gieben Expires June 23, 2005 [Page 6]
Kolkman & Gieben Expires September 2, 2005 [Page 7]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
entire DNS name space of all resolvers using that root zone (except
in the case of resolvers that have locally configured the public key
of a sub domain). Therefore, the utmost care must be taken in the
securing of the root zone. The strongest and most carefully handled
keys should be used. The root zone private key should always be kept
off line.
Many resolvers will start at a root server for their access to and
authentication of DNS data. Securely updating the trust anchors an
enormous population of resolvers around the world will be extremely
difficult.
authentication of DNS data. Securely updating the trust anchors in
an enormous population of resolvers around the world will be
extremely difficult.
3.2 Randomness
......@@ -352,7 +413,7 @@ Internet-Draft DNSSEC Operational Practices December 2004
use if an adversary can guess enough to lower the size of the likely
key space so that it can be exhaustively searched. Technical
suggestions for the generation of random keys will be found in
RFC1750 [5]. One should carefully assess if the random number
RFC1750 [3]. One should carefully assess if the random number
generator used during key generation adheres to these suggestions.
Keys with a long effectivity period are particularly sensitive as
......@@ -369,7 +430,7 @@ Internet-Draft DNSSEC Operational Practices December 2004
it will have been compromised through carelessness, accident,
espionage, or cryptanalysis. Furthermore when key rollovers are too
rare an event, they will not become part of the operational habit and
there is risk that no body on-site will remember the procedure for
there is risk that nobody on-site will remember the procedure for
rollover when the need is there.
For Key Signing Keys a reasonable key effectivity period is 13
......@@ -380,18 +441,19 @@ Internet-Draft DNSSEC Operational Practices December 2004
Using these recommendations will lead to rollovers occurring
frequently enough to become part of 'operational habits'; the
procedure does not have to be reinvented every time a key is
replaced.
Key effectivity periods can be made very short, as in the order of a
few minutes. But when replacing keys one has to take the
considerations from Section 4.1 and Section 4.2 into account.
Kolkman & Gieben Expires June 23, 2005 [Page 7]
Kolkman & Gieben Expires September 2, 2005 [Page 8]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
replaced.
Key effectivity periods can be made very short, as in the order of a
few minutes. But when replacing keys one has to take the
considerations from Section 4.1 and Section 4.2 into account.
3.4 Key Algorithm
......@@ -402,15 +464,20 @@ Internet-Draft DNSSEC Operational Practices December 2004
RSA has been developed in an open and transparent manner. As the
patent on RSA expired in 2000, its use is now also free.
DSA has been developed by NIST. The creation of signatures creation
is roughly the same speed as with RSA, but is 10 to 40 times as slow
for verification [11].
DSA has been developed by NIST. The creation of signatures is
roughly done at the same speed as with RSA, but is 10 to 40 times as
slow for verification [11].
We suggest the use of RSA/SHA-1 as the preferred algorithm for the
key. The current known attacks on RSA can be defeated by making your
key longer. As the MD5 hashing algorithm is showing (theoretical)
cracks, we recommend the usage of SHA1.
In 2005 some discoveries were made that SHA-1 also has some
weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is
expected that a new hashing algorithm is rolled out, before any
attack becomes practical.
3.5 Key Sizes
When choosing key sizes, zone administrators will need to take into
......@@ -433,20 +500,9 @@ Internet-Draft DNSSEC Operational Practices December 2004
Kolkman & Gieben Expires June 23, 2005 [Page 8]
Kolkman & Gieben Expires September 2, 2005 [Page 9]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
Year RSA Key Sizes Year RSA Key Sizes
......@@ -476,14 +532,19 @@ Internet-Draft DNSSEC Operational Practices December 2004
check the RSA key size values for 2006 in this table. In this case
it should be at least 1191 bits.
Please keep in mind that nobody can see into the future, and that
these key lengths are only provided here as a guide.
When determining a key size one should take into account that a large
key will be slower during generation and verification. For RSA,
verification, the most common operation, will vary roughly with the
square of the key size signing will vary with the cube of the key
size length, and key generation will vary with the fourth power of
square of the key size; signing will vary with the cube of the key
size length; and key generation will vary with the fourth power of
the modulus length. Besides larger keys will increase the sizes of
the RRSIG and DNSKEY records and will therefore increase the chance
of DNS UDP packet overflow. Also see Section 3.1.1.
of DNS UDP packet overflow. Also see Section 3.1.1 for a discussion
of how keys serving different roles (ZSK v. KSK) may need different
key strengths.
3.6 Private Key Storage
......@@ -492,19 +553,19 @@ Internet-Draft DNSSEC Operational Practices December 2004
connected, physically secure machines only. Periodically an
application can be run to add authentication to a zone by adding
RRSIG and NSEC RRs. Then the augmented file can be transferred,
perhaps by sneaker-net, to the networked zone primary server machine.
The ideal situation is to have a one way information flow to the
network to avoid the possibility of tampering from the network.
Keeping the zone master file on-line on the network and simply
Kolkman & Gieben Expires June 23, 2005 [Page 9]
Kolkman & Gieben Expires September 2, 2005 [Page 10]
Internet-Draft DNSSEC Operational Practices December 2004
Internet-Draft DNSSEC Operational Practices March 2005
perhaps by sneaker-net, to the networked zone primary server machine.
The ideal situation is to have a one way information flow to the
network to avoid the possibility of tampering from the network.
Keeping the 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
......@@ -516,9 +577,9 @@ Internet-Draft DNSSEC Operational Practices December 2004
network. Operators are advised to take security measures to shield
unauthorized access to the master copy.