DNSOP W. Hardaker
Internet-Draft Sparta, Inc.
Intended status: Informational August 25, 2008
Expires: February 26, 2009
Requirements for Management of Name Servers for the DNS
draft-ietf-dnsop-name-server-management-reqs-00.txt
Status of this Memo
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.
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.
This Internet-Draft will expire on February 26, 2009.
Abstract
Management of name servers for the Domain Name Service (DNS) has
traditionally been done using vendor-specific monitoring,
configuration and control methods. Although some service monitoring
platforms can test the functionality of the DNS itself there is not a
interoperable way to manage (monitor, control and configure) the
internal aspects of a name server itself.
This document discusses the requirements of a management system for
DNS name servers. A management solution that is designed to manage
the DNS can use this document as a shopping list of needed features.
Hardaker Expires February 26, 2009 [Page 1]
Internet-Draft Name Server Management Requirements August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. Document Layout and Requirements . . . . . . . . . . . 5
2. Management Architecture Requirements . . . . . . . . . . . . . 5
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Namespace Collision Protection . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
Hardaker Expires February 26, 2009 [Page 2]
Internet-Draft Name Server Management Requirements August 2008
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Hardaker Expires February 26, 2009 [Page 3]
Internet-Draft Name Server Management Requirements August 2008
1. Introduction
Management of name servers for the Domain Name Service (DNS)
[RFC1034] [RFC1035] has traditionally been done using vendor-specific
monitoring, configuration and control methods. Although some service
monitoring platforms can test the functionality of the DNS itself
there is not a interoperable way to manage (monitor, control and
configure) the internal aspects of a name server itself.
Previous standardization work within the IETF resulted in the
creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
to achieve significant implementation and deployment. The perceived
reasons behind the failure for the two MIB modules are further
documented in [RFC3197].
This document discusses the requirements of a management system for
DNS name servers. A management solution that is designed to manage
the DNS can use this document as a shopping list of needed features.
Specifically out of scope for this document are requirements
associated with management of stub resolvers. It is not the intent
of this document to document stub resolver requirements, although
some of the requirements listed are applicable to stub resolvers as
well.
Also out of scope for this document is management of the host or
other components of the host upon which the name server software is
running. This document only discusses requirements for managing the
name server component of a system.
The task of creating a management system for managing DNS servers is
not expected to be a small one. It is likely that components of the
solution will need to be designed in parts over time and these
requirements take this into consideration. In particular,
Section 5.1 discusses the need for future extensibility of the base
management solution. This document is intended to be a road-map
towards a desired outcome and is not intended to define an "all-or-
nothing" system. Successful interoperable management of name servers
even in part is expected to be beneficial to network operators
compared to the entirely custom solutions that are used at the time
of this writing.
1.1. Requirements notation
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 [RFC2119].
Hardaker Expires February 26, 2009 [Page 4]
Internet-Draft Name Server Management Requirements August 2008
1.1.1. Terminology
This document is consistent with the terminology defined in Section 2
of [RFC4033]. Additional terminology needed for this document are
described below:
Name Server: When we are discussing servers that don't fall into a
more specific type of server category defined in other documents,
this document will refer to them generically as "name servers".
In particular "name servers" can be considered to be any valid
combination of authoritative, recursive, validating, or security-
aware. The more specific name server labels will be used when
this document refers only to a specific type of server. However,
the term "name server", in this document, will not include stub
resolvers.
1.1.2. Document Layout and Requirements
The document is written so that each numbered section will contain
only a single requirement if it contains one at all. Each
requirement will contain needed wording from the terminology
described in Section 1.1. Subsections, however, might exist with
additional related requirements. The document is laid out in this
way so that a specific requirement can be uniquely referred to using
the section number itself and the document version from which it
came.
2. Management Architecture Requirements
This section discusses requirements that reflect the needs of the
expected deployment environments.
2.1. Expected Deployment Scenarios
DNS zones vary greatly in the type of content published within them.
Name Servers, too, are deployed with a wide variety of configurations
to support the diversity of the deployed content. It is important
that a management solution trying to meet the criteria specified in
this document consider supporting the largest number of potential
deployment cases as possible. Further deployment scenarios that are
not used as direct examples of specific requirements are listed in
Appendix A.
2.1.1. Zone Size Constraints
The management solution MUST support both name servers that are
serving a small number of potentially very large zones (e.g. Top
Hardaker Expires February 26, 2009 [Page 5]
Internet-Draft Name Server Management Requirements August 2008
Level Domains (TLDs)) as well as name servers that are serving a very
large number of small zones. These scenarios are both commonly seen
deployments.
2.1.2. Name Server Discovery
Large enterprise network deployments may contain multiple name
servers operating within the boundaries of the enterprise network.
These name servers may each be serving multiple zones both in and out
of the parent enterprise's zone. Finding and managing large
quantities of name servers would be a useful feature of the resulting
management solution. The management solution MAY support the ability
to discover previously unknown instances of name servers operating
within a deployed network.
2.1.3. Configuration Data Volatility
Configuration data is defined as data that relates only to the
configuration of a server and the zones it serves. It specifically
does not include data from the zone contents that is served through
DNS itself. The solution MUST support servers that remain fairly
statically configured over time as well as servers that have numerous
zones being added and removed within an hour. Both of these
scenarios are also commonly seen deployments.
2.1.4. Protocol Selection
There are many requirements in this document for many different types
of management operations (see Section 3 for further details). It is
possible that no one protocol will ideally fill all the needs of the
requirements listed in this document and thus multiple protocols
might be needed to produce a completely functional management system.
Multiple protocols might be used to create the complete management
solution, but the number of protocols used SHOULD be reduced to a
reasonable minimum number.
2.1.5. Common Data Model
Defining a standardized protocol (or set of protocols) to use for
managing name servers would be a step forward in achieving an
interoperable management solution. However, just defining a protocol
to use by itself would not achieve the complete end goal of a
complete interoperable management solution. Devices also need to
represent their internal management interface using a common
management data model. The solution MUST create a common data model
that management stations can make use of when sending or collecting
data from a managed device so it can successfully manage equipment
from vendors as if they were generic DNS servers. This common data
Hardaker Expires February 26, 2009 [Page 6]
Internet-Draft Name Server Management Requirements August 2008
model is needed for of the operations discussion in section
Section 3. Note that this does not preclude the fact that name
server vendors might provide additional management infrastructure
beyond a base management specification, as discussed further in
Section 5.1.
2.1.6. Operational Impact
It is impossible to add new features to an existing server (such as
the inclusion of a management infrastructure) and not impact the
existing service and/or server in some fashion. At a minimum, for
example, more memory, disk and/or CPU resources will be required to
implement a new management system. However, the impact to the
existing DNS service MUST be minimized since the DNS service itself
is still the primary service to be offered by the modified name
server.
2.2. Name Server Types
There are multiple ways in which name servers can be deployed. Name
servers can take on any of the following roles:
o Master Servers
o Slave Servers
o Recursive Servers
The management solution SHOULD support all of these types of name
servers as they are all equally important. Note that "Recursive
Servers" can be further broken down by the security sub-roles they
might implement, as defined in section 2 of [RFC4033]. These sub-
roles are also important to support within any management solution.
The requirements in this document explicitly exclude dealing with
management of stub resolvers. Management of stub resolvers is
considered specifically out of scope of this document.
3. Management Operation Types
Management operations can traditionally be broken into four
categories:
o Control
o Configuration
Hardaker Expires February 26, 2009 [Page 7]
Internet-Draft Name Server Management Requirements August 2008
o Health and Monitoring
o Alarms and Events
This section discusses requirements for each of these for management
types in detail.
3.1. Control Requirements
The management solution MUST be capable of performing basic service
control operations.
3.1.1. Needed Control Operations
These operations SHOULD include, at a minimum, the following
operations:
o Starting the name server
o Reloading the service configuration
o Reloading zone data
o Restarting the name server
o Stopping the name server
Note that no restriction is placed on how the management system
implements these operations. In particular, at least "starting the
name server" will require a minimal management system component to
exist independently of the name server itself.
3.1.2. Asynchronous Status Notifications
Some control operations might take a long time to complete. As an
example, some name servers take a long time to perform reloads of
large zones. Because of these timing issues, the management solution
SHOULD take this into consideration and offer a mechanism to ease the
burden associated with awaiting the status of a long-running command.
This could, for example, result in the use of asynchronous
notifications for returning the status of a long-running task or it
might require the management station to poll for the status of a
given task using monitoring commands. These and other potential
solutions need to be evaluated carefully to select one that balances
the result delivery needs with the perceived implementation costs.
Also, see the related discussion in Section 3.4 which discusses
notification messages for supporting delivery of alarm and event
Hardaker Expires February 26, 2009 [Page 8]
Internet-Draft Name Server Management Requirements August 2008
messages.
3.2. Configuration Requirements
Many features of name servers need to be configured before the server
can be considered functional. The management solution MUST be able
to provide name servers with configuration data. The most important
data to be configured, for example, is the served zone data itself.
3.2.1. Served Zone Modification
The ability to add, modify and delete zones being served by name
servers is needed. Although there are already solutions for zone
content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
might be used as part of the final management solution, the
management system SHOULD still be able to natively create a new zone
(with enough minimal data to allow the other mechanisms to function
as well) as well as delete a zone. This might be, for example, a
management operation that at least allows for the creation of the
initial SOA record for a new zone as that's the minimum amount of
zone data needed for the other operations to function.
3.2.2. Trust Anchor Management
The solution SHOULD support the ability to add, modify and delete
trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
[RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
anchors might be configured using the data from the DNSKEY Resource
Records (RRs) themselves or by using Delegation Signer (DS)
fingerprints.
3.2.3. Security Expectations
DNSSEC Validating resolvers need to make policy decisions about the
requests being processed. For example, They need to be configured
with a list of zones expected to be secured by DNSSEC. The
management solution SHOULD be able to add, modify and delete
attributes of DNSSEC security policies.
3.2.4. TSIG Key Management
TSIG [RFC2845] allows transaction level authentication of DNS
traffic. The management solution SHOULD be able to add, modify and
delete TSIG keys known to the name server.
Hardaker Expires February 26, 2009 [Page 9]
Internet-Draft Name Server Management Requirements August 2008
3.2.5. DNS Protocol Authorization Management
The management solution SHOULD have the ability to add, modify and
delete authorization settings for the DNS protocols itself. Do not
confuse this with the ability to manage the authorization associated
with the management protocol itself, which is discussed later in
Section 4.4. There are a number of authorization settings that are
used by a name server. Example authorization settings that the
solution might need to cover are:
o Access to operations on zone data (e.g. DDNS)
o Access to certain zone data from certain sources (e.g. from
particular network subnets)
o Access to specific DNS protocol services (e.g. recursive service)
Note: the above list is expected to be used as examples and is not a
complete list of needed authorization protections.
3.3. Monitoring Requirements
Monitoring is the process of collecting aspects of the internal state
of a name server at a given moment in time. The solution MUST be
able to monitor the health of a name server to determine its
operational status, load and other internal attributes. Example
management tasks that the solution might need to cover are:
o Number of requests sent, responses sent, average response latency
and other performance counters
o Server status (e.g. "serving data", "starting up", "shutting
down", ...)
o Access control violations
o List of zones being served
o Detailed statistics about clients interacting with the name server
(e.g. top 10 clients requesting data).
Note: the above list is expected to be used as examples and is not a
complete list of needed monitoring operations. In particular, some
monitoring statistics are expected to be computationally or resource
expensive and are considered to be "nice to haves" as opposed to
"necessary to have".
Hardaker Expires February 26, 2009 [Page 10]
Internet-Draft Name Server Management Requirements August 2008
3.4. Alarm and Event Requirements
Events occurring at the name server that trigger alarm notifications
can quickly inform a management station about critical issues. A
management solution SHOULD include support for delivery of alarm
conditions.
Example alarm conditions might include:
o The server's status is changing. (e.g it is starting up, reloading
configuration, restarting or shutting down)
o A needed resource (e.g. memory or disk space) is exhausted or
nearing exhaustion
o An authorization violation was detected
o The server has not received any data traffic (e.g. DNS requests
or NOTIFYs) recently (AKA the "lonely warning"). This condition
might indicate a problem with its deployment.
4. Security Requirements
The management solution will need to be appropriately secured against
attacks on the management infrastructure.
4.1. Authentication
The solution MUST support mutual authentication. The management
client needs to be assured that the management operations are being
transferred to and from the correct name server. The managed name
server needs to authenticate the system that is accessing the
management infrastructure within itself.
4.2. Integrity Protection
Management operations MUST be protected from modification while in
transit from the management client to the server.
4.3. Confidentiality
The management solution MUST support message confidentiality. The
potential transfer of sensitive configuration is expected (such as
TSIG keys or security policies). The solution does not, however,
necessarily need to provide confidentiality to data that would
normally be carried without confidentiality by the DNS system itself.
Hardaker Expires February 26, 2009 [Page 11]
Internet-Draft Name Server Management Requirements August 2008
4.4. Authorization
The solution SHOULD be capable of providing a fine-grained
authorization model for any management protocols it introduces to the
completed system. This authorization differs from the authorization
previously discussed in Section 3.2.5 in that this requirement is
concerned solely with authorization of the management system itself.
There are a number of authorization settings that might be used by a
managed system to determine whether the managing entity has
authorization to perform the given management task. Example
authorization settings that the solution might need to cover are:
o Access to the configuration that specifies which zones are to be
served
o Access to the management system infrastructure
o Access to other control operations
o Access to other configuration operations
o Access to monitoring operations
Note: the above list is expected to be used as examples and is not a
complete list of needed authorization protections.
4.5. Solution Impacts on Security
The solution MUST minimize the security risks introduced to the
complete name server system. It is impossible to add new
infrastructure to a server and not impact the security in some
fashion as the introduction of a management protocol alone will
provide a new avenue for potential attack. Although the added
management benefits will be worth the increased risks, the solution
still needs to minimize this impact as much as possible.
5. Other Requirements
5.1. Extensibility
The management solution is expected to change and expand over time as
lessons are learned and new DNS features are deployed. Thus, the
solution MUST be flexible and be able to accommodate new future
management operations. The solution might, for example, make use of
protocol versioning or capability description exchanges to ensure
that management stations and name servers that weren't written to the
Hardaker Expires February 26, 2009 [Page 12]
Internet-Draft Name Server Management Requirements August 2008
same specification version can still interoperate to the best of
their combined ability.
5.1.1. Vendor Extensions
It MUST be possible for vendors to extend the standardized management
model with vendor-specific extensions to support additional features
offered by their products.
5.1.2. Extension Identification
It MUST be possible for a management station to understand which
parts of returned data are specific to a given vendor or other
standardized extension. The data returned needs to be appropriately
marked through the use of name spaces or similar mechanisms to ensure
that the base management model data can be logically separated from
extension data without needing to understand the extension data
itself.
5.1.3. Namespace Collision Protection
It MUST be possible to protect against multiple extensions
conflicting with each other. The use of name-space protection
mechanisms for communicated management variables is common practice
to protect against problems. Name-space identification techniques
also frequently solve the "Extension Identification" requirement
discussed in Section 5.1.2 as well.
6. Security Considerations
Any management protocol that meets the criteria discussed in this
document needs to support the criteria discussed in Section 4 in
order to protect the management infrastructure itself. The DNS is a
core Internet service and management traffic that protects it could
be the target of attacks designed to subvert that service. Because
the management infrastructure will be adding additional interfaces to
that service, it is critical that the management infrastructure
support adequate protections against network attacks.
7. IANA Considerations
No action is required from IANA for this document.
Hardaker Expires February 26, 2009 [Page 13]
Internet-Draft Name Server Management Requirements August 2008
8. Document History
A requirement gathering discussion was held at the December 2007 IETF
meeting in Vancouver, BC, Canada and a follow up meeting was held at
the March 2008 IETF meeting in Philadelphia. This document is a
compilation of the results of those discussions as well as
discussions on the DCOMA mailing list.
9. Acknowledgments
This draft is the result of discussions within the DCOMA design team
chaired by Jaap Akkerhuis. This team consisted of a large number of
people all of whom provided valuable insight and input into the
discussions surrounding name server management. The text of this
document was written from notes taken during meetings as well as from
contributions sent to the DCOMA mailing list. This work documents
the consensus of the DCOMA design team.
In particular, the following team members contributed significantly
to the text in the document:
Stephane Bortzmeyer
Stephen Morris
Phil Regnauld
10. References
10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
Hardaker Expires February 26, 2009 [Page 14]
Internet-Draft Name Server Management Requirements August 2008
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
10.2. Informative References
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
RFC 1611, May 1994.
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
RFC 1612, May 1994.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997.
[RFC3197] Austein, R., "Applicability Statement for DNS MIB
Extensions", RFC 3197, November 2001.
Appendix A. Deployment Scenarios
This appendix documents some additional deployment scenarios that
Hardaker Expires February 26, 2009 [Page 15]
Internet-Draft Name Server Management Requirements August 2008
have been traditionally difficult to manage. They are provided as
guidance to protocol developers as data points of real-world name
server management problems.
A.1. Non-Standard Zones
If an organization uses non-standard zones (for example a purely-
local TLD), synchronizing all the nameservers for these zones is
usually a time-consuming task. It is made worse when two
organizations with conflicting zones merge. This situation is not a
recommended deployment scenario (and is even heavily discouraged) but
it is, unfortunately, seen in the wild.
It is typically implemented using "forwarding" zones. But there is
no way to ensure automatically that all the resolvers have the same
set of zones to forward at any given time. New zones might be added
to a local forwarding recursive server, for example, without
modifying the rest of the deployed forwarding servers. It is hoped
that a management solution which could handle the configuration of
zone forwarding would finally allow management of servers deployed in
this fashion.
A.2. Redundancy Sharing
For reliability reasons it is recommended that zone operators follow
the guidelines documented in [RFC2182] which recommends that multiple
name servers be configured for each zone and that the name servers
are separated both physically and via connectivity routes. A common
solution is to establish DNS-serving partnerships: "I'll host your
zones and you'll host mine". Both entities benefit from increased
DNS reliability via the wider service distribution. This frequently
occurs between cooperating but otherwise unrelated entities (such as
between two distinct companies) as well as between affiliated
organizations (such as between branch offices within a single
company).
The configuration of these relationships are currently required to be
manually configured and maintained. Changes to the list of zones
that are cross-hosted are manually negotiated between the cooperating
network administrators and configured by hand. A management protocol
with the ability to provide selective authorization, as discussed in
Section 4.4, would solve many of the management difficulties between
cooperating organizations.
Hardaker Expires February 26, 2009 [Page 16]
Internet-Draft Name Server Management Requirements August 2008
Author's Address
Wes Hardaker
Sparta, Inc.
P.O. Box 382
Davis, CA 95617
US
Phone: +1 530 792 1913
Email: ietf@hardakers.net
Hardaker Expires February 26, 2009 [Page 17]
Internet-Draft Name Server Management Requirements August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hardaker Expires February 26, 2009 [Page 18]
