Network Working Group J. Dickinson
Internet-Draft Sinodun Internet Technologies
Intended status: Standards Track S. Morris
Expires: April 27, 2011 Internet Systems Consortium
R. Arends
Nominet UK
October 24, 2010
Design for a Nameserver Control Protocol
draft-dickinson-dnsop-nameserver-control-01.txt
Abstract
This document presents a design for a nameserver control protocol
(NSCP).
A common data model for describing the configuration and operation of
a basic, but usable, generic name server is defined. This is
expressed in a formal modeling language (YANG) and can be used as the
basis of a set of NETCONF operations and capabilities.
The data model described is extensible and will allow for the
creation of additional capabilities, ensuring that the protocol can
support all the features of a name server.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 27, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dickinson, et al. Expires April 27, 2011 [Page 1]
Internet-Draft Design for a Nameserver Control Protocol October 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. NSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Use of NETCONF . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. NETCONF Overview . . . . . . . . . . . . . . . . . . . 4
1.3.2. Why NETCONF? . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements notation . . . . . . . . . . . . . . . . . . 6
2. Object Models . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. NSCP Base Capability . . . . . . . . . . . . . . . . . . . 7
2.1.1. Server . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Statistics . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Peer . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Peers . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.6. Panorama . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.7. View . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.8. Access Control List . . . . . . . . . . . . . . . . . 13
2.1.9. Zone . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. NSCP Basic Control Capability . . . . . . . . . . . . . . 15
2.2.1. Methods . . . . . . . . . . . . . . . . . . . . . . . 16
2.3. NSCP Start Control Capability . . . . . . . . . . . . . . 16
2.3.1. Methods . . . . . . . . . . . . . . . . . . . . . . . 16
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Obtaining Configuration Information . . . . . . . . . . . 17
3.2. Modifying Configuration Information . . . . . . . . . . . 18
3.3. Controlling the Name Server . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . . 23
6.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Meeting the Requirements . . . . . . . . . . . . . . 24
A.1. Management Architecture Requirements . . . . . . . . . . . 24
A.1.1. Expected Deployment Scenarios . . . . . . . . . . . . 24
A.1.2. Name Server Types . . . . . . . . . . . . . . . . . . 25
Dickinson, et al. Expires April 27, 2011 [Page 2]
Internet-Draft Design for a Nameserver Control Protocol October 2010
A.2. Management Operation Types . . . . . . . . . . . . . . . . 25
A.2.1. Control Requirements . . . . . . . . . . . . . . . . . 25
A.2.2. Configuration requirements . . . . . . . . . . . . . . 25
A.2.3. Monitoring Requirements . . . . . . . . . . . . . . . 26
A.2.4. Alarm and Event Requirements . . . . . . . . . . . . . 26
A.2.5. Security Requirements . . . . . . . . . . . . . . . . 26
A.2.6. Other Requirements . . . . . . . . . . . . . . . . . . 27
Appendix B. NSCP Capabilities . . . . . . . . . . . . . . . . . . 28
B.1. The NSCP Base Capability . . . . . . . . . . . . . . . . . 28
B.1.1. Capability Name . . . . . . . . . . . . . . . . . . . 28
B.1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . 28
B.1.3. Dependencies . . . . . . . . . . . . . . . . . . . . . 28
B.1.4. Capability Identifier . . . . . . . . . . . . . . . . 28
B.1.5. New Operations . . . . . . . . . . . . . . . . . . . . 28
B.2. The NSCP Basic Control Capability . . . . . . . . . . . . 28
B.2.1. Capability Name . . . . . . . . . . . . . . . . . . . 28
B.2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . 28
B.2.3. Dependencies . . . . . . . . . . . . . . . . . . . . . 29
B.2.4. Capability Identifier . . . . . . . . . . . . . . . . 29
B.2.5. New Operations . . . . . . . . . . . . . . . . . . . . 29
B.3. The NSCP Start Control Capability . . . . . . . . . . . . 29
B.3.1. Capability Name . . . . . . . . . . . . . . . . . . . 29
B.3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . 29
B.3.3. Dependencies . . . . . . . . . . . . . . . . . . . . . 29
B.3.4. Capability Identifier . . . . . . . . . . . . . . . . 29
B.3.5. New Operations . . . . . . . . . . . . . . . . . . . . 29
Appendix C. YANG Data Model for Base NSCP capability . . . . . . 30
Appendix D. YANG Data Model for the NSCP Basic Control
Capability . . . . . . . . . . . . . . . . . . . . . 36
Appendix E. YANG Data Model for the NSCP Start Control
Capability . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Dickinson, et al. Expires April 27, 2011 [Page 3]
Internet-Draft Design for a Nameserver Control Protocol October 2010
1. Introduction
1.1. Background
Management of DNS name servers is currently carried out via vendor-
specific control, configuration and monitoring methods.
Organizations run multiple name server implementations from a variety
of vendors. A common method of name server management can simplify
administration and reduce cost.
The requirements for the management of name servers have been
established and documented
[I-D.ietf-dnsop-name-server-management-reqs]. In essence, the
document describes a set of common operations that name servers are
known to implement.
1.2. NSCP
NSCP is a name server control protocol that meets the requirements
set out in [I-D.ietf-dnsop-name-server-management-reqs]. Based
around NETCONF [RFC4741], NSCP consists of a common data model for
describing the configuration and operation of a basic, generic name
server that is comparable with a subset of the features of existing
name server implementations. This data model, expressed in a formal
modeling language (YANG [RFC6020]), is used as the basis for a set of
NETCONF operations and capabilities.
The basic NSCP data model is extensible and allows for the creation
of additional NETCONF capabilities that will ensure the protocol can
support all the features of a name server.
Using NSCP, a suitable client should be able to communicate with and
manage any name server implementing the protocol.
It is the intention of NSCP that the NSCP data model will be
transformable into a data model suitable for use with a particular
name server implementation. In the longer term it is hoped that name
servers will implement the NSCP data model directly.
1.3. Use of NETCONF
1.3.1. NETCONF Overview
NETCONF is a protocol for the management and configuration of network
devices, where operations are layered on top of a remote procedure
call interface. A client establishes a session with a server via a
secure, connection-oriented transport mechanism (such as SSH).
Dickinson, et al. Expires April 27, 2011 [Page 4]
Internet-Draft Design for a Nameserver Control Protocol October 2010
The operations sent to the server, the replies from it and the
configuration data itself are encoded in XML.
Within NETCONF, capabilities identify sets of functionality that a
client or server may implement. During the setup of the session,
client and server exchange a list capabilities. As each system
ignores capabilities that it does not require or understand, the two
systems can settle on a common set understood by both. These
capabilities allow the client and server to agree on
o New operations
o Modifications to existing operations
o The data model(s) being used.
NETCONF provides a set of simple operations that allow management of
configuration data and retrieval of state information.
1.3.2. Why NETCONF?
There are a number of reasons for using NETCONF as the basis of NSCP:
o It is an established application protocol, allowing reuse of
existing tools and code.
o It is connection-oriented, running over secure links. This
matches anticipated use of NSCP.
o Use of XML allows established transformation methods such as XSLT
to be used to transform the NSCP configuration in to a vendor
specific configuration format.
o Configuration information is opaque to NETCONF, allowing any data
to be transported over it.
o It supports seamless extension of functionality via its
capabilities feature.
It is capabilities that make NETCONF particularly suitable for use as
the basis of NSCP. In particular, three requirements of
[I-D.ietf-dnsop-name-server-management-reqs] (section 5.1) are:
o The management solution must be flexible and be able to
accommodate new future operations.
o It must be possible for vendors to extend the standardized
management model with vendor-specific extensions.
Dickinson, et al. Expires April 27, 2011 [Page 5]
Internet-Draft Design for a Nameserver Control Protocol October 2010
o 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.
Capabilities clearly fit these requirements; by defining extensions
to NSCP - either vendor-specific or standard ones defined at a later
date - as NETCONF capabilities, additional features can be added to
NSCP whilst maintaining backwards compatibility with existing
systems.
1.4. 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].
Dickinson, et al. Expires April 27, 2011 [Page 6]
Internet-Draft Design for a Nameserver Control Protocol October 2010
2. Object Models
NSCP is built up from a set of capabilities. These provide different
parts of the object model as described below.
2.1. NSCP Base Capability
[I-D.ietf-dnsop-name-server-management-reqs] (section 2.1.5) states
that a common data model MUST be defined. This is a very necessary
requirement, since only by establishing a common definition about
what is being managed can management clients and name servers
exchange meaningful information.
During the design of NSCP, several existing name server
implementations were examined and the common details abstracted into
a common model. Inevitably, many detailed features of individual
name servers are not included. However, the capability mechanism of
NETCONF will allow them to be added as vendor-specific extensions.
The following figure shows the overall structure of the object model
within the "basic" capability.
+------------+---Server----+-------------+
|1 |1 |1 |1
| | | |
|1 |1 |1 |1
Peers Panorama Statistics DNSSECPolicy
|1 |1
| |
|* |*
Peer +-----View-----+
|1 |1
| |
|* |1
Zone ACL
(The numbers indicate the cardinality of the associations.) The
following sections describe each object in more detail. For every
object, the following information is provided:
o A discussion of the object - what it represents and its purpose.
o A list of the object's elements - the name of each element and the
contents.
Dickinson, et al. Expires April 27, 2011 [Page 7]
Internet-Draft Design for a Nameserver Control Protocol October 2010
2.1.1. Server
The server object is the root of the configuration tree and serves as
the focus for server-wide operations and repository for server-wide
information.
2.1.2. Statistics
In the base capability it is assumed that the server is capable of
generating the subset of Bind 8 style statistics currently supported
by both NSD and Bind 9.
Additional statistics will be the subject of future capabilities.
o RR
Count of responses received.
o RNXD
Count of NXDomain received
o RDupR
Count of duplicate responses
o RFail
Count of SERVFAIL responses received
o RFErr
Count of FORMERR responses received
o RErr
Count of other errors received
o RAXFR
Count of AXFR initiated
o RLame
Count of lame delegations received
o SSysQ
Count of NS address fetches
o SAns
Count of answers sent
o SFwdQ
Count of queries sent
Dickinson, et al. Expires April 27, 2011 [Page 8]
Internet-Draft Design for a Nameserver Control Protocol October 2010
o SDupQ
Count of queries retried
o RQ
Count of requests received
o SNXD
Count of NXDomain sent
o RUQ
Count of non-recursive queries rejected
o RURQ
Count of recursive queries rejected
o RUXFR
Count of XFR rejected
o RUUpd
Count of updates rejected
2.1.3. DNSSEC Policy
The DNSSEC policy defines a policy for the DNSSEC validation and
signing operations performed by the name server. Any signing policy
will be held in a key and signing policy database (KASP). The
details of KASP are still being developed; for now the data model
will just specify the location of the database as a string. Trusted
keys used for validation will be stored in a manner defined by the
implementation, therefore there will be no need for NSCP to specify a
trusted keys file. It is also assumed that all name servers managed
using NSCP will be DNSSEC-capable.
2.1.3.1. Elements
secure
The name of a domain that must validate as secure. There may be more
than one of these.
nonsecure
The name of a domain that may validate as insecure. There may be
more than one of these.
KASP-database
The name of the KASP database.
Dickinson, et al. Expires April 27, 2011 [Page 9]
Internet-Draft Design for a Nameserver Control Protocol October 2010
2.1.4. Peer
2.1.4.1. Discussion
A Peer is an object representing an external system or systems (since
there is no way to tell if a key or IP address refers to a single
system). A Peer is either a system that participates in the
nameserver service by being a master or a slave, or is a system that
uses the nameserver service. It is identified by a name and must
contain either a key element or an address element, or both. All
references to external systems in the rest of the NSCP object model
refer to a Peer.
2.1.4.2. Elements
o name
A name for this Peer. This name is unique, and is used elsewhere
in the model as a reference to this object.
o address
Describes an IP address. There can be zero or more address
elements in the Peer although, if there are no address elements, a
key element MUST be present. The contents of the address element
are:
* ip
This is mandatory and holds the IP address of the Peer. The IP
address can be either IPV4 or IPV6. The address/network is
represented in standard form (e.g. 192.0.2.0/24 or 2001:
0DB8::/32).
* port
Optional port number.
o key
A TSIG key to be used when talking to this Peer. This is
optional. The contents of a key element are one of:
* hmac-md5
This holds the secret for HMAC-MD5
* hmac-sha1
This holds the secret for HMAC-SHA1
Use of an element per algorithm will allow easy augmentation with
future algorithms.
A Peer allows for the identification of an external systems. Where
Dickinson, et al. Expires April 27, 2011 [Page 10]
Internet-Draft Design for a Nameserver Control Protocol October 2010
only an address element is present, the identification is clear.
Should only a key element be present an external system corresponds
to the Peer if it presents a suitable signature. The combination of
address and key elements allows TSIG transactions to be more
discriminating; an external system corresponds to the Peer if and
only if it presents correct signatures and its address is correct.
2.1.5. Peers
A container for Peer objects. This may be useful as it provides a
point at which a partial lock can be placed [RFC5717] to lock a group
of Peers without affecting the rest of the server.
It is thought that there may be some use for named groups of peers to
be allowed. This will be considered more in future versions of this
draft.
2.1.5.1. Example
The following is an example of a group of Peers.
Server123192.0.2.0/24532001:0DB8::08:EF53OtherServerhQdEr7iwwB8ATMuZAj1YFQ==
2.1.6. Panorama
2.1.6.1. Discussion
The Panorama is a collection of views, it provides a point at which a
partial lock can be placed [RFC5717] to lock all views without
Dickinson, et al. Expires April 27, 2011 [Page 11]
Internet-Draft Design for a Nameserver Control Protocol October 2010
affecting the rest of the server.
2.1.7. View
2.1.7.1. Discussion
The view object can be considered as a virtual server. It groups
zones with similar access characteristics. It is more than just the
association of a zone and an ACL: a view allows the server to send
different replies to clients according to the following criteria
o Source address (and port).
o Destination address (and port).
o Whether or not the query requests recursion.
The replies can differ in terms of
o Which zones are available to a given client.
o The contents of those zones.
o Is recursion available?
o Is validation performed?
o Any configuration parameters of the server or zone.
To aid in the definition of a common object model, a view will always
exist in a NSCP name server configuration, even if the name server
concerned does not implement views. All implementations of NSCP MUST
implement a view named "_default".
In this data model all zones in a given view will have the same
masters and slaves.
2.1.7.2. Elements
o name
A name for the view.
o listen-on
What IP address and port to bind this view to. This can occur
zero or more times.
o recursion
Is recursion enabled in this view ("on" or "off").
Dickinson, et al. Expires April 27, 2011 [Page 12]
Internet-Draft Design for a Nameserver Control Protocol October 2010
o validation
Is DNSSEC validation performed in this view ("on" or "off").
2.1.8. Access Control List
Access to services on the name server are controlled by Access
Control Lists (ACL). Using common nomenclature, an ACL comprises one
or more Access Control Entries (ACEs). Each ACE links an attribute
of the accessor (an "identifier") to one or more access rights to the
resource being controlled.
An ACL is attached to a view. However, it may be useful for it to be
attached to a zone. This will be considered further in a future
version of this draft.
An ACL contains the following elements:
o ace
Zero or more access control entries, each entry defining a match
between an identifier and access modes.
o default
Zero or one default access control entries defining access rights
should no other ACE match.
The order of ACEs within an ACL is important. When checking for
access, the system MUST attempt to match each ACE in turn. If none
match, the system MUST attempt to match a default ACE (a wildcard
that matches any accessor). If there is no default accessor, access
MUST be denied.
2.1.8.1. ace
An ACE links an identifier with one or more access modes. An ACE has
the following sub-elements:
o identifier
This element - of which there must be one and only one - defines
what is accessing the system. The element's value is the name of
a Peer defining one or more external systems.
o access
Access elements define what access rights the accessor has to the
server, such as operations they are able to undertake and data
they are able to see. There are one or more access elements in
each ACE. The value of this element is one of the following:
Dickinson, et al. Expires April 27, 2011 [Page 13]
Internet-Draft Design for a Nameserver Control Protocol October 2010
none No access. This overrides any other type of access,
and denies access to the accessor.
notify Causes the server to take notice of NOTIFY messages
from the accessor.
nonrecursive Allows the accessor to make a non-recursive request
to the server.
recursive Allows the accessor to make a recursive request to the
server.
transfer Allows the accessor to transfer data from the server
(either AXFR or IXFR).
update Causes the server to accept dynamic update messages
from the accessor.
2.1.8.2. default
A default access control entry is consulted only if all explicit ACEs
fail to match. It does not contain an "identifier" clause (being
deemed to match all identifiers), only access elements as described
above.
2.1.8.3. Example
The following ACL would allow any accessor to query the zones in this
view. Any system in the Peer LocalGroup would also be able to AXFR
and IXFR from zones in the view. Systems in the Peer MasterSystem
(which would presumably contain a "key" element defining a TSIG/SIG0
key) could dynamically update the zone.
LocalGrouptransfernonrecursiveMasterSystemupdatenonrecursive
nonrecursive
Dickinson, et al. Expires April 27, 2011 [Page 14]
Internet-Draft Design for a Nameserver Control Protocol October 2010
2.1.9. Zone
2.1.9.1. Discussion
The zone object represents a zone served by the name server and
comprises a collection of resource records. In virtually all cases,
the zone will not be created by an NSCP client, being defined instead
by the contents of a zone file, an external database or by zone
transfer. If it is necessary to define zone contents using NSCP then
the zone contents can be defined using a Zone Data Capability which
will be the subject of a separate draft. This means that with just
the base capability it will only be possible to provision zones via
AXFR (In other words, to create the zone configuration specifying a
master server from which the name server will have to obtain the zone
data).
In this data model it is expected that filenames and directory
structure will be fixed by the implementation. Therefore, a zone
does not have a filename element.
2.1.9.2. Elements
o name
the name of the zone being served. The name of a zone MUST be
unique within a view, although different views may have zones with
the same name.
o master
The identifier of a Peer that can act as a master server for this
zones. This can occur zero or more times.
o slave
The identifier of a Peer that can act as slave server for this
zones. This can occur zero or more times. Note: This says
nothing about whether or not those servers should be sent
notifies. Both master and slave can appear for a single zone.
o notify
The identifier of a Peer to which notifies should be sent to for
this zone. This can occur zero or more times.
2.2. NSCP Basic Control Capability
This capability provides the basic control functions for the
operation of the name server. It adds the following methods
Dickinson, et al. Expires April 27, 2011 [Page 15]
Internet-Draft Design for a Nameserver Control Protocol October 2010
2.2.1. Methods
o server-stop
Stops the server software.
o server-reload
Reloads the zone data
o server-restart
stops and the restarts the server software.
2.3. NSCP Start Control Capability
This capability provides an additional control functions. It has
been added as a separate capability because they will only be
possible if the name server is being managed by an external NSCP
process. It adds the following methods:
2.3.1. Methods
o server-start
Starts the server software.
Dickinson, et al. Expires April 27, 2011 [Page 16]
Internet-Draft Design for a Nameserver Control Protocol October 2010
3. Examples
This section gives some examples of NSCP requests.
3.1. Obtaining Configuration Information
To obtain configuration information from a remote nameserver via
NSCP, a NETCONF operation is used. is used
to retrieve all or part of a configuration. By default it uses
subtree filtering to select the part of the configuration tree to
return. XPath filtering can also be used if the :xpath capability is
supported.
A is required to specify a source configuration data
store. By default NETCONF only specifies the "running"
configuration. However, NSCP implementations are free to add
additional data stores and advertise their-presence via
implementation-specific capabilities (e.g. a "candidate"
configuration, see [RFC4741] section 8.3).
The following example request uses (in an implementation
of NSCP with the :xpath capability) to select a Peer (named "master")
from the configuration.
Dickinson, et al. Expires April 27, 2011 [Page 17]
Internet-Draft Design for a Nameserver Control Protocol October 2010
... and an example of a possible reply is:
master192.0.2.0/24532001:0DB8::08:EF53
3.2. Modifying Configuration Information
Modification of configuration information is achieved via , another standard operation defined by NETCONF [RFC4741]. It
takes an operation attribute that allows the specification of how the
target should be modified; elements can be added or removed, or the
contents of the message can be merged into the target.
The next example updates the NSCP configuration to enables recursion
in a view called my_view. The "replace" attribute ensures that
recursion is enabled, whatever the current state.
myviewon
Dickinson, et al. Expires April 27, 2011 [Page 18]
Internet-Draft Design for a Nameserver Control Protocol October 2010
On success, the reply looks like:
(This is the form of reply expected when the server is merely
acknowledging the completion of an NSCP command and not returning
data. In the following examples, such replies are omitted.)
In the next example, the NSCP configuration is modified to add a new
zone to a secondary. The master is configured to allow AXFR. To
configure a master server one would also use a zone data capability
to upload or point NSCP at the zone data.
_defaultexample.orgpeer1peer4
Dickinson, et al. Expires April 27, 2011 [Page 19]
Internet-Draft Design for a Nameserver Control Protocol October 2010
The next example is the same as the previous one (i.e. the addition
of a zone), but illustrates a server that also supports the
:rollback-on-error capability. By advertising this capability, the
server guarantees that if the requested change fails for some reason,
the existing configuration will be left unaltered; there will be no
partial alteration of the configuration. The :rollback-on-error
capability is one of several capabilities defined in [RFC4741]
rollback-on-error_defaultexample.orgpeer1peer4
3.3. Controlling the Name Server
The following example illustrates how to stop a server if it has the
Basic Control capability
With the Start Control capability, it is possible to start a stopped
server
Dickinson, et al. Expires April 27, 2011 [Page 20]
Internet-Draft Design for a Nameserver Control Protocol October 2010
4. IANA Considerations
This memo includes no request to IANA.
Dickinson, et al. Expires April 27, 2011 [Page 21]
Internet-Draft Design for a Nameserver Control Protocol October 2010
5. Security Considerations
To be completed.
Dickinson, et al. Expires April 27, 2011 [Page 22]
Internet-Draft Design for a Nameserver Control Protocol October 2010
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote
Procedure Call (RPC) for NETCONF", RFC 5717,
December 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
6.2. Informative
[I-D.ietf-dnsop-name-server-management-reqs]
Hardaker, W., "Requirements for Management of Name Servers
for the DNS",
draft-ietf-dnsop-name-server-management-reqs-04 (work in
progress), June 2010.
Dickinson, et al. Expires April 27, 2011 [Page 23]
Internet-Draft Design for a Nameserver Control Protocol October 2010
Appendix A. Meeting the Requirements
This section discusses how NSCP meets the requirement described in
[I-D.ietf-dnsop-name-server-management-reqs]. The requirements are
listed in the same order as those described in that document.
A.1. Management Architecture Requirements
A.1.1. Expected Deployment Scenarios
Nothing in NSCP restricts the range of deployment scenarios. Indeed,
the very nature of NETCONF lends itself to supporting different
scenarios through the use of capabilities.
A.1.1.1. Zone Size Constraints
Nothing in NSCP restricts the size or number of zones served by any
NSCP managed name server.
A.1.1.2. Name Server Discovery
This is not supported in the base NSCP capability. However, nothing
prevents this being added later, either as some kind of capability or
via a different protocol.
A.1.1.3. Configuration Data Volatility
Nothing in NSCP restricts the frequency of changes to the name server
configuration
A.1.1.4. Protocol Selection
It is anticipated that NSCP, along with extensions built using
capabilities, can meet the needs of a full management protocol.
There may however, be occasions where there is an existing protocol
better suited for carrying a particular task. For example, loading
zone contents via AXFR/IXFR.
A.1.1.5. Common Data Model
A common data model is a core part of NSCP and is described in detail
in this document.
A.1.1.6. Operational Impact
It is not anticipated that NSCP will add significant overhead to any
DNS service.
Dickinson, et al. Expires April 27, 2011 [Page 24]
Internet-Draft Design for a Nameserver Control Protocol October 2010
A.1.2. Name Server Types
NSCP, along with extensions built using capabilities will support all
the name server types.
A.2. Management Operation Types
A.2.1. Control Requirements
A.2.1.1. Needed Control Operations
NSCP along with the two control capabilities described in this
document can provide the minimum set of control operations.
Additional operations can be added via new capabilities.
A.2.1.2. Asynchronous Status Notifications
[RFC5277] describes an asynchronous message notification delivery
service for NETCONF. This is an optional capability built on the
base NETCONF definition. It is expected that this will form part of
NSCP and will be considered further in future versions of this draft.
A.2.2. Configuration requirements
A.2.2.1. Served Zone Modification
The base NSCP protocol will be able to add, modify and delete the
configuration about served zones. The ability to configure a zone
with data will be the subject of additional capabilities described in
other drafts. It is anticipated that there may be a variety of zone
data modification capabilities to reflect the variety of methods
possible for sending zone data to a name server. These may include
capabilities that define methods to obtain zone data using DDNS,
AXFR, HTTP, SCP, or even over NETCONF itself.
A.2.2.2. Trust Anchor Management
The base NSCP protocol will be able to add, modify and delete trust
anchors.
A.2.2.3. Security Expectations
The base NSCP capability will be able to configure validation
policies.
Dickinson, et al. Expires April 27, 2011 [Page 25]
Internet-Draft Design for a Nameserver Control Protocol October 2010
A.2.2.4. TSIG Key Management
The base NSCP protocol is able to add, modify and delete peers, which
can be identified by TSIG keys.
A.2.2.5. DNS Protocol Authorization Management
NSCP contains a sophisticated access control mechanism that will
allow control of
o Access to operations on zone data.
o Access to zone data from certain sources.
o Access to specific DNS protocol services.
A.2.3. Monitoring Requirements
It remains to be decided how much monitoring will form part of the
base NSCP capability. Some minimal health monitoring and statistics
gathering are included in the base NSCP capability. Future
capabilities are expected to allow more state to be monitored.
A.2.4. Alarm and Event Requirements
As mentioned before, [RFC5277] describes an asynchronous message
notification delivery service for NETCONF. It is expected that this
will form part of NSCP and will be considered further in future
versions of this draft.
A.2.5. Security Requirements
A.2.5.1. Authentication
Authentication will be provided by the NETCONF transport layer.
A.2.5.2. Integrity Protection
Integrity Protection will be provided by the NETCONF transport layer.
A.2.5.3. Confidentiality
Confidentiality will be provided by the NETCONF transport layer.
A.2.5.4. Authorization
Authorization will be provided by NETCONF or a capability.
Dickinson, et al. Expires April 27, 2011 [Page 26]
Internet-Draft Design for a Nameserver Control Protocol October 2010
A.2.5.5. Solution Impacts on Security
It is believed that NSCP does minimize any security risks introduced
to the name server system. The security is provided by the NETCONF
transport layer and a variety of suitable transports are available
including ssh.
A.2.6. Other Requirements
A.2.6.1. Extensibility
NSCP is flexible and be able to accommodate new future management
operations.
A.2.6.1.1. Vendor Extensions
NSCP does allow vendors to extend the standardized management model
with vendor-specific extensions
A.2.6.1.2. Extension Identification
In NETCONF capabilities are advertised in messages exchanged during
session establishment. If multiple capability are used then the each
define their own xml namespace.
A.2.6.1.3. Namespace Collision Protection
Again, in NETCONF capabilities are advertised in messages exchanged
during session establishment. If multiple capability are used then
the each define their own xml namespace.
Dickinson, et al. Expires April 27, 2011 [Page 27]
Internet-Draft Design for a Nameserver Control Protocol October 2010
Appendix B. NSCP Capabilities
This section defines the NSCP capabilities using the template in
Appendix C of [RFC4741]. NSCP is broken in to several capabilities
to allow for maximum flexibility
B.1. The NSCP Base Capability
B.1.1. Capability Name
NSCP Base
B.1.2. Overview
Exchange of this capability at session set up time indicates that the
client and server both understand the base NSCP data model described
in Section 2.1
B.1.3. Dependencies
None.
B.1.4. Capability Identifier
urn:ietf:dnsop:nscp:1.0
B.1.5. New Operations
None.
B.2. The NSCP Basic Control Capability
B.2.1. Capability Name
NSCP Basic Control
B.2.2. Overview
Exchange of this capability at session set up time indicates that the
client and server both understand the basic NSCP control operations
described in Section 2.2
There is no reconfig operation. It is assumed that this will happen
automatically whenever the configuration is updated or that a form of
commit-confirmed capability such as the one in [RFC4741] (section
8.4) will be used.
Dickinson, et al. Expires April 27, 2011 [Page 28]
Internet-Draft Design for a Nameserver Control Protocol October 2010
B.2.3. Dependencies
NSCP Base
B.2.4. Capability Identifier
urn:ietf:dnsop:nscp-control:1.0
B.2.5. New Operations
Note: Startup of a name server is a separate capability. This is to
account for name servers that have a built in NSCP agent.
Signals the name server to cleanly shutdown.
Signals the name server reload a specified zone or all zones.
Signals the name server to re-start.
B.3. The NSCP Start Control Capability
B.3.1. Capability Name
NSCP Start Control
B.3.2. Overview
Exchange of this capability at session set up time indicates that the
client and server both understand the Start NSCP control operation
described in Section 2.3
B.3.3. Dependencies
NSCP Start Control
B.3.4. Capability Identifier
urn:ietf:dnsop:nscp-start-control:1.0
B.3.5. New Operations
Signals the name server to start up.
Dickinson, et al. Expires April 27, 2011 [Page 29]
Internet-Draft Design for a Nameserver Control Protocol October 2010
Appendix C. YANG Data Model for Base NSCP capability
YANG Data Model for Base NSCP capability
module nscp {
namespace "urn:ietf:dnsop:nscp:1.0";
prefix nscp;
import yang-types { prefix yang; }
import inet-types { prefix inet; }
import ieee-types { prefix ieee; }
organization
"IETF";
description
"Base data model for NSCP.";
container server {
description "root of configuration and data";
container statistics {
description "container to hold statistics elements";
leaf rr {
description "Count of responses received.";
config false;
type yang:counter64;
}
leaf rnxd {
description "Count of NXDomain received";
config false;
type yang:counter64;
}
leaf rdup {
description "Count of duplicate responses";
config false;
type yang:counter64;
}
leaf rfail {
description "Count of SERVFAIL responses received";
config false;
type yang:counter64;
}
leaf rferr {
description "Count of FORMERR responses received";
config false;
type yang:counter64;
}
leaf rerr {
description "Count of other errors received";
Dickinson, et al. Expires April 27, 2011 [Page 30]
Internet-Draft Design for a Nameserver Control Protocol October 2010
config false;
type yang:counter64;
}
leaf raxfr {
description "Count of AXFR initiated";
config false;
type yang:counter64;
}
leaf rlame {
description "Count of lame delegations received";
config false;
type yang:counter64;
}
leaf ssysq {
description "Count of NS address fetches";
config false;
type yang:counter64;
}
leaf sans {
description "Count of answers sent";
config false;
type yang:counter64;
}
leaf sfwdq {
description "Count of queries sent";
config false;
type yang:counter64;
}
leaf sdupq {
description "Count of queries retried";
config false;
type yang:counter64;
}
leaf rq {
description "Count of requests received";
config false;
type yang:counter64;
}
leaf snxd {
description "Count of NXDomain sent";
config false;
type yang:counter64;
}
leaf ruq {
description "Count of non-recursive queries rejected";
config false;
type yang:counter64;
}
Dickinson, et al. Expires April 27, 2011 [Page 31]
Internet-Draft Design for a Nameserver Control Protocol October 2010
leaf rurq {
description "Count of recursive queries rejected";
config false;
type yang:counter64;
}
leaf ruxfr {
description "Count of XFR rejected";
config false;
type yang:counter64;
}
leaf ruupd {
description "Count of updates rejected";
config false;
type yang:counter64;
}
}
container dnssec-policy {
description "DNSSEC policy";
leaf-list secure {
description
"List of domains that are expected to be secure";
type inet:domain-name;
}
leaf-list nonsecure {
description
"List of domains that are expected to be insecure";
type inet:domain-name;
}
leaf KASP-database {
description
"Path or URL (To be decided) to allow the policy
database to be located.";
type string;
}
}
container peers {
description
"Container for peer elements. May be used for partial
locking";
list peer {
key "name";
leaf name {
description
"name - used to refer to this peer elsewhere.";
type string;
}
Dickinson, et al. Expires April 27, 2011 [Page 32]
Internet-Draft Design for a Nameserver Control Protocol October 2010
list address {
description
"Address and port that will identify this peer";
key "ip port";
leaf ip {
type inet:ip-prefix;
}
leaf port {
type inet:port-number;
}
}
container key {
description
"key that will be used to identify this peer. A
choice is used to allow augmentation in
the future";
choice type {
case a {
leaf hmac-md5 {
type string;
}
}
case b {
leaf hmac-sha1 {
type string;
}
}
}
}
}
}
container panorama {
description "A collection of views.";
list view {
key "name";
leaf name {
type string;
}
list listen-on {
description
"Address and port that the nameserver will
listen on.";
key "ip port";
leaf ip {
type inet:ip-address;
}
leaf port {
type inet:port-number;
Dickinson, et al. Expires April 27, 2011 [Page 33]
Internet-Draft Design for a Nameserver Control Protocol October 2010
}
}
leaf recursion {
description "Is recursion enabled for this view?";
type enumeration {
enum on;
enum off;
}
}
leaf validation {
description "Is validation enabled in this view?";
type enumeration {
enum on;
enum off;
}
}
list zone {
description "a zone";
key "zone-name";
leaf zone-name {
description "the name of the zone.";
type string;
}
leaf-list master {
description
"A reference to a peer that will act as a
master for this zone";
type keyref {
path "/server/peers/peer/name";
}
}
leaf-list slave {
description
"A reference to a peer that will act as a
slave for this zone";
type keyref {
path "/server/peers/peer/name";
}
}
leaf-list notify {
description
"A reference to a peer that notifies should
be sent to for this zone";
type keyref {
path "/server/peers/peer/name";
}
}
}
Dickinson, et al. Expires April 27, 2011 [Page 34]
Internet-Draft Design for a Nameserver Control Protocol October 2010
container acl {
description "The acl for this view";
list ace {
description "An access control entry.";
key "identifier";
leaf identifier {
description
"The name of a peer that will get
this access.";
type keyref {
path "/server/peers/peer/name";
}
}
leaf-list access {
description
"The type of access that this peer
will receive.";
type enumeration {
enum none;
enum notify;
enum query;
enum recursion;
enum transfer;
enum update;
}
}
}
}
}
}
}
}
Dickinson, et al. Expires April 27, 2011 [Page 35]
Internet-Draft Design for a Nameserver Control Protocol October 2010
Appendix D. YANG Data Model for the NSCP Basic Control Capability
module nscp-basic-control {
namespace "urn:ietf:dnsop:nscp-basic-control:1.0";
prefix nscp-basic-control;
organization
"IETF";
description
"Adds basic control to NSCP.";
rpc server-stop {
/* Will cause server to stop cleanly. No inputs */
output {
leaf status {
/* Will return something like "server stopping" */
type string;
}
}
}
rpc server-reload {
/* Will cause server to reload the
* running configuration. No inputs */
output {
leaf status {
/* Will return something like "server reloading" */
type string;
}
}
}
rpc server-restart {
/* Will cause server to reload the
*running configuration. No inputs */
output {
leaf status {
/* Will return something like "server restarting" */
type string;
}
}
}
}
Dickinson, et al. Expires April 27, 2011 [Page 36]
Internet-Draft Design for a Nameserver Control Protocol October 2010
Appendix E. YANG Data Model for the NSCP Start Control Capability
module nscp-start-control {
namespace "urn:ietf:dnsop:nscp-start-control:1.0";
prefix nscp-start-control;
import yang-types { prefix yang; }
import inet-types { prefix inet; }
import ieee-types { prefix ieee; }
organization
"IETF";
description
"Adds start control to the base data model for NSCP.";
rpc server-start {
/* Will cause server to stop cleanly. No inputs */
output {
leaf status {
/* Will return something like "server starting" */
type string;
}
}
}
}
Dickinson, et al. Expires April 27, 2011 [Page 37]
Internet-Draft Design for a Nameserver Control Protocol October 2010
Authors' Addresses
John A Dickinson
Sinodun Internet Technologies
Stables 4 Suite 11
Howbery Park
Wallingford, Oxfordshire OX10 8BA
UK
Email: jad@sinodun.com
Stephen Morris
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Email: stephen@isc.org
Roy Arends
Nominet UK
Minerva House
Edmund Halley Road
Oxford Science Park
Oxford, Oxfordshire OX4 4DQ
UK
Email: roy.arends@nominet.org.uk
Dickinson, et al. Expires April 27, 2011 [Page 38]