upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-28 01:28:05 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

new drafts

Browse source
This commit is contained in:
David Lawrence 2001-03-05 12:42:31 +00:00
parent c56c28c3f2
commit da928cb9b8
4 changed files with 1188 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

396
doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt Normal file
View file

@ -0,0 +1,396 @@
IETF DNSOPS working group T. Hardie
Internet draft Equinix, Inc
Category: Work-in-progress January, 2001
draft-ietf-dnsop-hardie-shared-root-server-03.txt
Distributing Authoritative Name Servers via Shared Unicast Addresses
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single
named server in multiple locations. The primary motivation for the
development and deployment of these practices is to increase the
distribution of DNS servers to previously under-served areas of the
network topology and to reduce the latency for DNS query responses
in those areas. This document presumes a one-to-one mapping between
named authoritative servers and administrative entities (operators).
This document contains no guidelines or recommendations for caching
name servers.
1. Architecture
1.1 Server Requirements
Operators of authoritative name servers may wish to refer to [1] and
[2] for general guidance on appropriate practice for authoritative
name servers. In addition to proper configuration as a standard
authoritative name server, each of the hosts participating in a
shared-unicast system should be configured with two network
interfaces. These interfaces may be either two physical interfaces
or one physical interface mapped to two logical interfaces. One of
the network interfaces should use the shared unicast address
associated with the authoritative name server. The other interface,
referred to as the administrative interface below, should use a
distinct address specific to that host. The host should respond to
DNS queries only on the shared-unicast interface. In order to
provide the most consistent set of responses from the mesh of
anycast hosts, it is good practice to limit responses on that
interface to zones for which the host is authoritative.
1.2 Zone file delivery
In order to minimize the risk of man-in-the-middle attacks, zone
files should be delivered to the administrative interface of the
servers participating in the mesh. Secure file transfer methods and
strong authentication should be used for all transfers. If the hosts
in the mesh make their zones available for zone transer, the administrative
interfaces should be used for those transfers as well, in order to avoid
the problems with potential routing changes for TCP traffic
noted in section 1.5 below.
1.3 Synchronization
Authoritative name servers may be loosely or tightly synchronized,
depending on the practices set by the operating organization. As
noted below in section 3.1.2, lack of synchronization among servers
using the same shared unicast address could create problems for some
users of this service. In order to minimize that risk, switch-overs
from one data set to another data set should be coordinated as much
as possible. The use of synchronized clocks on the participating
hosts and set times for switch-overs provides a basic level of
coordination. A more complete coordination process would involve:
a) receipt of zones at a distribution host
b) confirmation of the integrity of zones received
c) distribution of the zones to all of the servers in the
mesh
d) confirmation of the integrity of the zones at each server
e) coordination of the switchover times for the servers in the
mesh
f) institution of a failure process to ensure that servers that
did not receive correct data or could not switchover to the
new data ceased to respond to incoming queries until the
problem could be resolved.
Depending on the size of the mesh, the distribution host may also be
a participant; for authoritative servers, it may also be the host on
which zones are generated.
1.4 Server Placement
Though the geographic diversity of server placement helps reduce the
effects of service disruptions due to local problems, it is
diversity of placement in the network topology which is the driving
force behind these distribution practices. Server placement should
emphasize that diversity. Ideally, servers should be placed
topologically near the points at which the operator exchanges routes
and traffic with other networks.
1.5 Routing
The organization administering the mesh of servers sharing a unicast
address must have an autonomous system number and speak BGP to its
peers. To those peers, the organization announces a route to the
network containing the shared-unicast address of the name server.
The organization's border routers must then deliver the traffic
destined for the name server to the nearest instantiation. Routing
to the administrative interfaces for the servers can use the normal
routing methods for the administering organization.
One potential problem with using shared unicast addresses is that
routers forwarding traffic to them may have more than one available
route, and those routes may, in fact, reach different instances of
the shared unicast address. Because UDP is self-contained, UDP
traffic from a single source reaching different instances presents
no problem. TCP traffic, in contrast, may fail or present
unworkable performance characteristics in a limited set of
circumstances. For split-destination failures to occur, the router
forwarding the traffic must both have equal cost routes to the two
different instances and use a load sharing algorithm which does
per-packet rather than per-destination load sharing.
Four things mitigate the severity of this problem. The first is
that UDP is a fairly high proportion of the query traffic to name
servers. The second is that the aim of this proposal is to
diversify topological placement; for most users, this means that the
coordination of placement will ensure that new instances of a name
server will be at a significantly different cost metric from
existing instances. Some set of users may end up in the middle, but
that should be relatively rare. The third is that per packet load
sharing is only one of the possible load sharing mechanisms, and
other mechanisms are increasing in popularity.
Lastly, in the case where the traffic is TCP, per packet load
sharing is used, and equal cost routes to different instances of a
name server are available, any implementation which measures the
performance of servers to select a preferred server will quickly
prefer a server for which this problem does not occur. For
authoritative servers, care must be taken that all of the servers
for a specific zone are not participants in the same shared-unicast
mesh. To guard even against the case where multiple meshes have a
set of users affected by per packet load sharing along equal cost
routes, organizations implementing these practices should always
provide at least one authoritative server which is not a participant
in any shared unicast mesh. Those deploying shared-unicast meshes
should note that any specific host may become unreachable to a
client should a server fail, a path fail, or the route to that host
be withdrawn. These error conditions are, however, not specific to
shared-unicast distributions, but would occur for standard unicast
hosts.
Appendix A. contains an ASCII diagram of a simple implementation of
this system. In it, the odd numbered routers deliver traffic to the
shared-unicast interface network and filter traffic from the
administrative network; the even numbered routers deliver traffic to
the administrative network and filter traffic from the shared-unicast
network. These are depicted as separate routers for the ease this
gives in explanation, but they could easily be separate interfaces
on the same router. Similarly, a local NTP source is depicted for
synchronization, but the level of synchronization needed would not
require that source to be either local or a stratum one NTP server.
2. Administration
2.1 Points of Contact
A single point of contact for reporting problems is crucial to the
correct administration of this system. If an external user of the
system needs to report a problem related to the service, there must
be no ambiguity about whom to contact. If internal monitoring does
not indicate a problem, the contact may, of course, need to work
with the external user to identify which server generated the
error.
3. Security Considerations
As a core piece of internet infrastructure, authoritative name
servers are common targets of attack. The practices outlined here
increase the risk of certain kinds of attack and reduce the risk of
others.
3.1 Increased Risks
3.1.1 Increase in physical servers
The architecture outlined in this document increases the number of
physical servers, which could increase the possibility that a
server mis-configuration will occur which allows for a security
breach. In general, the entity administering a mesh should ensure
that patches and security mechanisms applied to a single member of
the mesh are appropriate for and applied to all of the members of a
mesh. "Genetic diversity" (code from different code bases) can be
a useful security measure in avoiding attacks based on
vulnerabilities in a specific code base; in order to ensure
consistency of responses from a single named server, however, that
diversity should be applied to different shared-unicast meshes or
between a mesh and a related unicast authoritative server.
3.1.2 Data synchronization problems
The level of systemic synchronization described above should be
augmented by synchronization of the data present at each of the
servers. While the DNS itself is a loosely coupled system,
debugging problems with data in specific zones would be far more
difficult if two different servers sharing a single unicast address
might return different responses to the same query. For example,
if the data associated with www.example.com has changed and the
administrators of the domain are testing for the changes at the
example.com authoritative name servers, they should not need to
check each instance of a named root server. The use of ntp to
provide a synchronized time for switch-over eliminates some aspects
of this problem, but mechanisms to handle failure during the
switchover are required. In particular, a server which cannot make
the switchover must not roll-back to a previous version; it must
cease to respond to queries so that other servers are queried.
3.1.3 Distribution risks
If the mechanism used to distribute zone files among the servers is
not well secured, a man-in-the-middle attack could result in the
injection of false information. Digital signatures will alleviate
this risk, but encrypted transport and tight access lists are a
necessary adjunct to them. Since zone files will be distributed to
the administrative interfaces of meshed servers, the access control
list for distribution of the zone files should include the
administrative interface of the server or servers, rather than
their shared unicast addresses.
3.2 Decreased Risks
The increase in number of physical servers reduces the likelihood
that a denial-of-service attack will take out a significant portion
of the DNS infrastructure. The increase in servers also reduces
the effect of machine crashes, fiber cuts, and localized disasters
by reducing the number of users dependent on a specific machine.
4. 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.
5. Acknowledgements
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato,
Suzanne Woolf, Scott Tucker, and Gunnar Lindberg all provided input
and commentary on this work.
6. References
[1] "Selection and Operation of Secondary Name Servers". R. Elz, R. Bush,
S Bradner, M. Patton, BCP0016.
[2] "Root Name Server Operational Requirements". R. Bush,
D. Karrenberg, M. Kosters, R. Plzak, BCP0040.
7. Editor's address
Ted Hardie
Equinix, Inc.
2450 Bayshore Parkway
Mountain View, CA 94043-1107
hardie@equinix.com
Tel: 1.650.316.6226
Fax: 1.650.315.6903
Appendix A.
__________________
Peer 1-| |
Peer 2-| |
Peer 3-| Switch |
Transit| | _________ _________
etc | |--|Router1|---|----|--------------|Router2|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router3|---|----|--------------|Router4|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router5|---|----|--------------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|--------------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]

293
doc/draft/draft-ietf-dnsop-inaddr-required-01.txt Normal file
View file

@ -0,0 +1,293 @@
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months February 2001
Requiring DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-01.txt
Status of this Memo
This draft, file name draft-ietf-dnsop-inaddr-required-00.txt, is
intended to be become a Best Current Practice RFC. Distribution of
this document is unlimited. Comments should be sent to the Domain
Name Server Operations working group mailing list <dnsop@cafax.se> or
to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000,2001). All Rights Reserved.
1. Introduction
The Domain Name Service has provision for providing mapping of IP
addresses to host names. It is common practice to ensure both name to
address, and address to name mappings are provided for networks. This
practice, while documented, has never been documented as a
requirement placed upon those who control address blocks. This
document fills this gap.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Discussion
Senie [Page 1]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
From the early days of the Domain Name Service [RFC 883] a special
domain has been set aside for resolving mappings of IP addresses to
domain names. This was refined in [RFC1035], describing the .IN-
ADDR.ARPA in use today.
The assignment of blocks of IP Address space was delegated to three
regional registries. Guidelines for the registries are specified in
[RFC2050], which requires regional registries to maintain IN-ADDR
records on the large blocks of space issued to ISPs and others.
ARIN's policy only requires ISPs to maintain IN-ADDR if they have a
/16 or larger allocation [ARIN]. APNIC indicates in their policy
document [APNIC] that those to whom they allocate blocks, and those
further downstream SHOULD maintain IN-ADDR records. RIPE appears to
have the strongest policy in this area [ripe-185] indicating Local
Internet Registries are required to perform IN-ADDR services, and
delegate those as appropriate when address blocks are delegated.
As we can see, the regional registries have their own policies for
requirements for IN-ADDR maintenance. It should be noted, however,
that many address blocks were allocated before the creation of the
regional registries, and thus it is unclear whether any of the
policies of the registries are binding on those who hold blocks from
that era.
Registries allocate address blocks on CIDR [RFC1519] boundaries.
Unfortunately the IN-ADDR zones are based on classful allocations.
Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
exist, but are not always implemented. Providers SHOULD follow these
guidelines and ensure their clients set up zone files to answer the
delegations.
3. Effects of missing IN-ADDR
Many applications use DNS lookups for security checks. To ensure
validity of claimed names, some applications will look up IN-ADDR
records to get names, and then look up the resultant name to see if
it maps back to the address originally known. Failure to resolve
matching names is seen as a potential security concern.
Some popular FTP sites will flat-out reject users, even for anonymous
FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR
lookup when itself resolved, does not match. Some Telnet servers also
implement this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This is
being employed for downloads of crypto software, for example, where
Senie [Page 2]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
export of that software is prohibited to some locales. Credit card
anti-fraud systems also use these methods for geographic placement
purposes.
The popular TCP Wrappers program found on most Unix and Linux systems
has options to enforce IN-ADDR checks and to reject any client which
does not resolve.
Wider-scale implementation of IN-ADDR on dialup, CDPD and other such
client-oriented portions of the Internet would result in lower
latency for queries (due to lack of negative caching), and lower name
server load and DNS traffic.
Some anti-spam (anti junk email) systems use IN-ADDR to verify return
addresses before accepting email.
Many web servers look up the IN-ADDR of visitors to be used in log
analysis. This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed web page accesses for users.
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine who's network is the cause of problems.
4. Requirements
All IP address space which is assigned and in use SHOULD be resolved
by IN-ADDR records. Internet providers and other users to whom a
block of addresses are delegated SHOULD provide for lookup of host
names from IP addresses. This may be provided directly or by
delegation to the user of the address block. The ISP is responsible
for one or the other. In the event of delegation, the user is
responsible for resolution.
Only IP addresses not presently in use within a block, or which are
not valid for use (zeros or ones broadcast addresses) are permitted
to have no mapping. It should be noted that due to CIDR, many
addresses which appear to be otherwise valid host addresses may
actually be zeroes or ones broadcast addresses. As such, attempting
to audit a site's degree of compliance can only be done with a
knowledge of the internal routing structure of the site. However, any
host which originates an IP packet necessarily will have a valid host
address, and must therefore have an IN-ADDR mapping.
Regional Registries and any Local Registries to whom they delegate
SHOULD establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are required. Internet providers and end
Senie [Page 3]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
users with address blocks must verify their own internal networks are
properly represented in IN-ADDR records, either by providing that
service themselves, or delegating it to others.
Those to whom blocks have been delegated SHOULD convey a policy to
degegatees requiring that they too provide IN-ADDR records and
require and delegations below to do the same. ISPs may wish to
provide IN-ADDR records for their clients if the customers are unable
to provide this for themselves.
5. Security Considerations
This document has no negative impact on security. While it could be
argued that lack of PTR record capabilities provides a degree of
anonimity, this is really not valid. Trace routes, whois lookups and
other sources will still provide methods for discovering identity.
6. References
[RFC883] P.V. Mockapetris, "Domain names: Implementation
specification," RFC883, November 1983.
[RFC1035] P.V. Mockapetris, "Domain Names: Implementation
Specification," RFC 1035, November 1987.
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy," RFC 1519, September
1993.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown, http://www.arin.net/regserv/initial-isp.html
[APNIC] "Policies for address space management in the Asia Pacific
Region," Approved October 1999, effective January 2000,
http://www.apnic.net/drafts/add-manage-policy.html
[RIPE185] "European Internet Registry Policies and Procedures,"
ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html
7. Acknowledgements
Senie [Page 4]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Thanks to Peter Koch and Gary Miller for their input, and to many
people who encouraged me to write this document.
8. Author's Address
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740
Phone: (978) 779-6813
EMail: dts@senie.com
Senie [Page 5]

288
doc/draft/draft-ietf-dnsop-keyhand-04.txt Normal file
View file

@ -0,0 +1,288 @@
DNSOP WG Edward Lewis
INTERNET DRAFT NAI Labs
Category: I-D March 2, 2001
Handling of DNS Zone Signing Keys
<draft-ietf-dnsop-keyhand-04.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSOP WG mailing list
dnsop@cafax.se.
This draft expires on September 2, 2001
Copyright Notice
Copyright (C) The Internet Society (1999-2001). All rights reserved.
Abstract
DNS Security Extensions require a greater interaction between zone
administrations sharing a zone cut. The center of the interaction is
the handling of the zone keys of the child and the signature applied
by the parent. DNSSEC does not include a protocol for this, but the
means of this interaction need definition to maintain the security of
DNS.
1 Introduction
This document has existed for quite some time. The purpose of this
document is to capture lessons learned regarding DNSSEC zone keys. In
the past two years numerous workshops have been held, each adding to
the community's lessons learned.
In past editions of this document, the outline consisted of describing
the lifecycle of a key and the steps needed to get it validated by the
parent. In this edition, a new approach is being taken. The lessons
learned are described without regard to fitting into an operations
procedure. The hope is to develop a better explanation of the issues
surrounding what will someday describe a "best current practice."
2 Terminology
Zone keys are explicitly defined in RFC 2535, but there have been
certain phrases that are increasingly used that may cause confusion to
new comers.
A zone key really refers to two cryptographic values, called a public
key and a private key. The two values always work in tandem, hence
the singular reference. The phrase "signing with the zone key" refers
to using the private key to generate digital signatures. The phrase
"verifying with the zone key" refers to the use of the public key to
verify the data and signature.
3 Threats to Keys
The threats to a zone key center on threats to the private key. There
are three ways a zone key can be come useless to the owner (and
possibly an advantage to an attacker). The private key could be come
"exposed," "discovered," or "lost." The latter case, a lost key,
refers to perhaps accidentally deleting the key from storage, and is a
case that is of little concern. (Keys can be replaced easily.)
An "exposed" key refers to a private key that is seen, or copied, by
an unauthorized person. This could happen if the host holding the key
is infiltrated or sloppy transferring of the key (such as in
unencrypted email).
A "discovered key" is one that is found through performing
cryptographic analysis of the public key, data sets and signatures.
Depending on various factors, such as algorithm and key size, a
determined analyst can reverse engineer the private key.
This latter loss is the most troublesome. This kind of loss is what
creates the limited lifetime of a key. Because of this, there is a
need to fully develop key changing (or rollover) procedures.
Unfortunately, there is no current recommendation on how long it would
take to discover a given private key. Such knowledge would be
invaluable in the design on key handling procedures.
4 "Lateral Signing"
Lateral signing refers to the use of key-signing keys and data-signing
keys to balance the need to change keys (avoiding discovery) and the
need to configure new keys in resolvers.
This approach has been developed for the use of TLDs in absence of a
signed root zone. This approach is applicable anywhere in the DNS
hierarchy, and will be needed by the root zone when it is signed.
The thought is as follows. A zone assumes that the parent is not
secured, hence must distribute a public key to all resolvers of
interest. This key is a key-signing key, it will be used to sign as
little as possible to minimize the risk of discovery. Other keys are
used to sign the zone, with these keys changed roughly once a month.
At any one time, the zone's key set will have the one key-signing key
and some number of data-signing keys. The key-signing key will sign
the zone key set, and the other key or keys, the zone data.
A resolver would start with the key-signing key configured. When data
arrives, it does so accompanied by a signature generated by a
data-signing key. The resolver then retrieves the data-signing key as
part of the zone key set, which is signed by the key-signing key.
Hence the chain is from key-signing key to data-signing key (signed by
key-signing key) to data (signed by data-signing key).
The term "lateral" signing comes from the observation that the
key-signing key and the data-signing key are from the same place in
the hierarchy (same owner name).
5 Getting Validation
In order for DNSSEC to scale, zones will need to have their parents
validate the zone keys. This process is the most difficult issue
facing DNSSEC deployment.
Summarizing this needed process, a child zone sends its zone key set
to the parent, the parent signs it and returns the data to the child.
This process is complicated by its volume (number of zones) and its
repetitiveness due - to the key discovery problem.
One important issue that has been raised regarding this process is
what the parent does with the child's keys once they are signed. One
school of thought is that the keys and signature are returned to the
child and are forgotten by the parent. Another school of though is
that the parent retains copies of the keys and signature, perhaps even
entering them into the zone file.
The former idea enables the child to "close the loop" security-wise by
verifying that the parent signed the right keys. It might be possible
for an attacker to intercept the submission and modify the keys.
The latter idea leaves the parent better prepared for a key change in
its zone. If the parent changes keys mid-month, or in an emergency,
children zones (perhaps signed monthly) need to get the new
signatures. On one workshop, this step was mishandled, resulting in
the loss of many delegations.
6 Changing Keys
When the time comes to change a zone's keys, one issue is whether it
is appropriate to retain old keys in the zone or to abruptly change
the key set (with the exception of any key-signing key). The reason
to retain old keys is to enable old but still valid signatures to be
verified in caches. Arguments for abrupt change include the
observation that this is the only way in which DNS can revoke
signatures.
8 Size and validity period
An often-asked question is what is an appropriate key size. As
mentioned earlier, a good guide is lacking. In general, per
algorithm, a longer key compared to a shorter key is more difficult to
discovery but takes longer to use. Longer keys can generally be used
longer, but signing and verification are slower.
The period of time in which a key should be used is an unknown
quantity. This will likely be a decision based upon staffing, and on
a calendar basis. Once a week is likely for zones requiring tight
security, once a month for others.
9 Random Numbers
One easily overlooked issue is the source of random numbers. A good
random number generator is needed to generate truly strong keys. In
the worst case, a random number generator always returning the same
number would result in the same pair of keys being generated. If a
zone generates a pair of keys this way and an attacker gets hold of
the same key generation software, it would be possible to discover the
private key simply by generating a pair of keys. This, by the way,
has already been observed in workshops.
It is unfortunate that some current operating systems have poor random
number generators. While this is improving, the machines used for key
generation and use should be selected carefully.
10 Dynamic Update
Dynamic update raises an issue regarding the protection of private
keys. As mentioned earlier, one threat is the exposure of the private
key. This is possible of the private key is on the same machine as
the name server, or even on any other reachable server. Therefore,
conventional wisdom is to use non-network connected machines (perhaps
behind a firewall) for all signing activity.
Dynamic update requires the server to sign data submitted to it for a
zone. This means the private key must be available to the name server
(on the network).
To counter this, a recommendation is offered to segregate dynamic
update zones from static zones. This limits the risk to static data
if a dynamic update zone key is exposed. In addition, some issues
have been discovered with signed dynamic update zones, particularly
the mechanism by which to refresh signatures, which also call for
separating crucial static data from dynamic data.
11 IANA Considerations
This document does not place any requirements on the assigned numbers
authority.
12 Security Considerations
This entire document is a note on security considerations. If the
zone key is mishandled, in a way that compromises its security, then
the security of its zone is compromised.
13 References
At some point.
14 Author's Address
Edward Lewis
<lewis@tislabs.com>
3060 Washington Rd (Rte 97)
Glenwood, MD 21738
+1(443)259-2352
15 Acknowledgements
The following individuals and groups have made significant input into
the content of this document: the attendees of the NIC-SE work shop on
DNSSEC, May 18 and 19, 1999, also Olafur Gudmundsson, and Brian
Wellington.
A second workshop held by the CAIRN research network September 29 and
30th also provided input to this document. Dan Massey has provided
input based upon this workshop and experience with DNSSEC in CAIRN.
More workshops are to be acknowledged.
16 Full Copyright Statement
Copyright (C) The Internet Society (1999-2001). 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."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis NAI Labs
Phone: +1 443-259-2352 Email: lewis@tislabs.com
Dilbert is an optimist.
Opinions expressed are property of my evil twin, not my employer.

211
doc/draft/draft-ietf-dnsop-parent-sig-00.txt Normal file
View file

@ -0,0 +1,211 @@
Parent's SIG over child's KEY
draft-ietf-dnsop-parent-sig-00.txt
Miek Gieben, Ted Lindgreen
Status of This Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
When dealing with large amounts of keys the procedures to update a zone and
to sign a zone need to be clearly defined and practically possible.
The current idea is to have the KEY RR and the parent's SIG to reside in the
child's zone and perhaps also in the parent's zone. We feel that this would
lead to very complicated procedures for large TLD's. We propose a alternative
scheme in which the parent zone stores the parent's signature over the child's
key and also a copy of the child's key itself.
The advantage of this proposal is that all signatures signed by a key are in
the same zone file as the producing key. This allows for a simple key
rollover and resigning mechanism. For large TLD's this is extremely important.
We further discuss the impact on a secure aware resolver/forwarder.
Table of Contents
Status of This Document....................................
Abstract...................................................
Table of Contents..........................................
1 Introduction.............................................
2 Proposal.................................................
3 Impact on a secure aware resolver/forwarder..............
3.1 Impact of key rollovers on resolver/forwarder..........
4 Key rollovers............................................
4.1 Scheduled key rollover.................................
4.2 Unscheduled key rollover...............................
5 Zone resiging............................................
References................................................
Authors' Addresses........................................
References................................................
1. Introduction
Within a CENTR working group NLnet Labs is researching the impact of
DNSSEC on the ccTLDs and gTLDs.
In this document we are considering a secure zone, somewhere under a secure
entry point and on-tree [1] validation between the secure entry point and the
zone in question. The resolver we are considering is security aware and is
preconfigured with the KEY of the secure entry point.
RFC 2535 [2] states that a zone key must be present in the apex of a zone.
This can be in the at the delegation point in the parent's zonefile
(normally the case for null keys), or in the child's zonefile, or in both.
This key is only valid if it is signed by the parent, so there is also the
question where this signature is located.
The original idea was to have the KEY RR and the parent's SIG to reside
in the child's zone and perhaps also in the parent's zone. There is a
draft proposal [3], that describes how a keyrollover can be handled.
At NLnet Labs we found that storing the parent's signature over the
child's key in the child's zone:
- makes resigning a KEY by the parent difficult
- makes a scheduled keyrollover very complicated
- makes an unscheduled keyrollover virtually impossible
We propose an alternative scheme in which the parent's signature over the
child's key is only stored in the parent's zone, i.e. where the signing key
resides. This would solve the above problems.
2. Proposal
The core of the new proposal is that the parent zone stores the parent's
signature over the child's key and also a copy of the child's key itself.
The child zone also contains its zonekey, where it is selfsigned.
The advantage of this proposal is that all signatures signed by a key are in
the same zone file as the producing key. This allows for a simple key
rollover and resigning mechanism. For large TLD's this is extremely important.
A disadvantage would be that not all the information concerning one zone is
stored at that zone, namely the (parent) SIG RR. Note that the same argument
can be applied to a zone's NULL key, which is also stored at the parent.
3. Impact on a secure aware resolver/forwarder
The resolver must be aware of the fact that the parent is more authoritative
than a child when it comes to deciding whether a zone is secured or not.
Without caching and with on-tree validation, a resolver will always start
its search at a secure entry point. In this way it can determine whether it
must expect SIG records or not.
Considering caching in a secure aware resolver or forwarder. If information
of a secure zone is cached, its validated KEY should also be cached.
If the KEY record expires, because the KEY TTL expires or because the SIG is
no longer valid, the KEY should be discarded. The resolver or forwarder
should then also discard other data concerning the zone because it is no
longer validated and possible bad data should not be cached.
3.1. Impact of key rollovers on resolver/forwarder
When a zone is in the process of a key rollover, there could be a discrepancy
between the KEY and the SIG in the apex of the zone and the KEY and SIG that
are stored in the cache of a resolver.
Suppose a resolver has cached the NS, KEY and SIG records of a zone. Next a
request comes for an A record in that zone. Also the zone is in the process
of a keyrollover and already has new keys in its zone. The resolver receives
an answer consisting of the A record and a SIG over the A record. It uses
the tag field in the SIG to determine if it has a KEY which is suitable to
validate the SIG. If it does not has such a KEY the resolver must ask the
parent of the zone for a new KEY and then try it again. Now the resolver
has 2 keys for the zone, according to the tag field in the SIG it can use
either one.
If the new key also does not validate the SIG the zone is marked bad. If the
KEY found at the parent is the NULL key the resolver knows that the child is
considered insecure. This could for instance be in the case the private key
of the zone is stolen.
4. Key rollovers
Private keys can be stolen or a key can become over used. In both
cases a new a new key must be signed and distributed. This event is
called keyrollover. We further distinguish between a scheduled and an
unscheduled key rollover. A scheduled rollover is announced before hand.
An unscheduled key rollover is needed when a private key is compromised.
4.1. Scheduled key rollover
When the signatures, produced by the key to be rolled over, are all
in one zone file, there are two parties involved. Let us look at an
example where a TLD rolls over its zone key. The new key needs to be
signed with the root's key before it can be used to sign the TLD zone
and the zone keys of the TLD's children. The steps that need to be taken
by TLD and root are:
- the TLD adds the new key to its keyset in its zonefile. This
zone and keyset are signed with the old zonekey
- then the TLD signals the parent
- the root copies the new keyset, consisting of the both new
and the old key, in its zonefile, resigns it and signals the TLD
- the TLD removes the old key from its keyset, resigns its zone
with the new key, and signals the the root
- the root copies the new keyset, now consisting of the new key
only, and resigns it
4.2. Unscheduled key rollover
Although nobody hopes that this will ever happen, we must be able to
cope with possible key compromises. When such an event occurs, an
immediate keyrollover is needed and must be completed in the shortest
possible time. With two parties involved, it will still be awkward, but
not impossible to update two zonefiles overnight. "Out-of-band"
communication between the two parties will be necessary, since the
compromised old key can not be trusted. We think that between two
parties this is doable, but this complicated procedure is beyond the
scope of this document. [4]
5. Zone resigning
Resigning a TLD is necessary before the current signatures expire.
When all SIG records, produced by the TLD's zone key are kept in the
TLD's zonefile, and only there, such a resign session is trivial, as
only one party (the TLD) and one zonefile is involved.
Authors' Addresses
R. Gieben
Stichting NLnet Labs
Kruislaan 419
1098 VA Amsterdam
miek@nlnetlabs.nl
T. Lindgreen
Stichting NLnet Labs
Kruislaan 419
1098 VA Amsterdam
ted@nlnetlabs.nl
References
[1] Lewis, E. "DNS Security Extension Clarification on Zone Status",
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt
[2] Eastlake, D. "DNS Security Extensions", RFC 2535
http://www.ietf.org/rfc/rfc2535.txt?number=2535
[3] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover"
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
[4] Gieben, R. "Chain of trust"
http://secnl.nlnetlabs.nl/thesis/thesis.html