Network Working Group J. Dickinson
Internet-Draft
Intended status: Standards Track S. Morris
Expires: April 30, 2009 R. Arends
Nominet UK
October 27, 2008
Design for a Nameserver Control Protocol
draft-dickinson-dnsop-nameserver-control-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 April 30, 2009.
Dickinson, et al. Expires April 30, 2009 [Page 1]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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.
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 . . . . . . . . . . . . . . 16
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. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Meeting the Requirements . . . . . . . . . . . . . . 24
A.1. Management Architecture Requirements . . . . . . . . . . . 24
Dickinson, et al. Expires April 30, 2009 [Page 2]
Internet-Draft Design for a Nameserver Control Protocol October 2008
A.1.1. Expected Deployment Scenarios . . . . . . . . . . . . 24
A.1.2. Name Server Types . . . . . . . . . . . . . . . . . . 25
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
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Dickinson, et al. Expires April 30, 2009 [Page 3]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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.hardaker-dnsops-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.hardaker-dnsops-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 [I-D.ietf-netmod-yang]), 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 30, 2009 [Page 4]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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.hardaker-dnsops-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 30, 2009 [Page 5]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 6]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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.hardaker-dnsops-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 30, 2009 [Page 7]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 8]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 9]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 10]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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
[I-D.ietf-netconf-partial-lock] 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.
<peers>
<peer>
<name>Server123</name>
<address>
<ip>192.0.2.0/24</ip>
<port>53</port>
</address>
<address>
<ip>2001:0DB8::08:EF</ip>
<port>53</port>
</address>
</peer>
<peer>
<name>OtherServer</name>
<key>
<hmac-sha1>hQdEr7iwwB8ATMuZAj1YFQ==</hmac-sha1>
</key>
</peer>
</peers>
2.1.6. Panorama
Dickinson, et al. Expires April 30, 2009 [Page 11]
Internet-Draft Design for a Nameserver Control Protocol October 2008
2.1.6.1. Discussion
The Panorama is a collection of views, it provides a point at which a
partial lock can be placed [I-D.ietf-netconf-partial-lock] to lock
all views without 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
Dickinson, et al. Expires April 30, 2009 [Page 12]
Internet-Draft Design for a Nameserver Control Protocol October 2008
zero or more times.
o recursion
Is recursion enabled in this view ("on" or "off").
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
Dickinson, et al. Expires April 30, 2009 [Page 13]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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:
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.
Dickinson, et al. Expires April 30, 2009 [Page 14]
Internet-Draft Design for a Nameserver Control Protocol October 2008
<acl>
<ace>
<identifier type="peer">LocalGroup</identifier>
<access>transfer</access>
<access>nonrecursive</access>
</ace>
<ace>
<identifier type="peer">MasterSystem</identifier>
<access>update</access>
<access>nonrecursive</query>
</ace>
<default>
<access>nonrecursive</query>
</default>
</acl>
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.
Dickinson, et al. Expires April 30, 2009 [Page 15]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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
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 30, 2009 [Page 16]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 <get-config> operation is used. <get-config> 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 <get-config> 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 <get-config> (in an implementation
of NSCP with the :xpath capability) to select a Peer (named "master")
from the configuration.
<rpc message-id="101">
<get-config>
<source>
<running/>
</source>
<filter type="xpath" select="server/peers/peer[name='master']"/>
</get-config>
</rpc>
Dickinson, et al. Expires April 30, 2009 [Page 17]
Internet-Draft Design for a Nameserver Control Protocol October 2008
... and an example of a possible reply is:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<peer xmlns="urn:ietf:nscp:1.0">
<name>master</name>
<address>
<ip>192.0.2.0/24</ip>
<port>53</port>
</address>
<address>
<ip>2001:0DB8::08:EF</ip>
<port>53</port>
</address>
</peer>
</data>
</rpc-reply>
3.2. Modifying Configuration Information
Modification of configuration information is achieved via <edit-
config>, 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 <edit-config> 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.
<rpc message-id="102">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<server xmlns="urn:ietf:nscp:1.0">
<panorama>
<view>
<name>myview</name>
<recursion xc:operation="replace">on</recursion>
</view>
</panorama>
</server>
</config>
</edit-config>
</rpc>
Dickinson, et al. Expires April 30, 2009 [Page 18]
Internet-Draft Design for a Nameserver Control Protocol October 2008
On success, the reply looks like:
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
(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.
<rpc message-id="103"">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<server xmlns="urn:ietf:nscp:1.0">
<panorama>
<view>
<name>_default</name>
<zone xc:operation="create">
<name>example.org</name>
<master>peer1</master>
<notify>peer4</notify>
</zone>
</view>
</panorama>
</server>
</config>
</edit-config>
</rpc>
Dickinson, et al. Expires April 30, 2009 [Page 19]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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]
<rpc message-id="104"">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<server xmlns="urn:ietf:nscp:1.0">
<panorama>
<view>
<name>_default</name>
<zone xc:operation="create">
<name>example.org</name>
<master>peer1</master>
<notify>peer4</notify>
</zone>
</view>
</panorama>
</server>
</config>
</edit-config>
</rpc>
3.3. Controlling the Name Server
The following example illustrates how to stop a server if it has the
Basic Control capability
<rpc message-id="105"">
<server-stop/>
</rpc>
With the Start Control capability, it is possible to start a stopped
server
<rpc message-id="106"">
<server-start/>
</rpc>
Dickinson, et al. Expires April 30, 2009 [Page 20]
Internet-Draft Design for a Nameserver Control Protocol October 2008
4. IANA Considerations
This memo includes no request to IANA.
Dickinson, et al. Expires April 30, 2009 [Page 21]
Internet-Draft Design for a Nameserver Control Protocol October 2008
5. Security Considerations
To be completed.
Dickinson, et al. Expires April 30, 2009 [Page 22]
Internet-Draft Design for a Nameserver Control Protocol October 2008
6. Normative References
[I-D.hardaker-dnsops-name-server-management-reqs]
Hardaker, W., "Requirements for Management of Name Servers
for the DNS",
draft-hardaker-dnsops-name-server-management-reqs-03 (work
in progress), May 2008.
[I-D.ietf-netconf-partial-lock]
Lengyel, B. and M. Bjorklund, "Partial Lock RPC for
NETCONF", draft-ietf-netconf-partial-lock-03 (work in
progress), August 2008.
[I-D.ietf-netmod-yang]
Bjorklund, M., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-01 (work in progress),
August 2008.
[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.
Dickinson, et al. Expires April 30, 2009 [Page 23]
Internet-Draft Design for a Nameserver Control Protocol October 2008
Appendix A. Meeting the Requirements
This section discusses how NSCP meets the requirement described in
[I-D.hardaker-dnsops-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 30, 2009 [Page 24]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 25]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 26]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 27]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 28]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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.
<stop>
Signals the name server to cleanly shutdown.
<reload>
Signals the name server reload a specified zone or all zones.
<restart>
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
<start>
Signals the name server to start up.
Dickinson, et al. Expires April 30, 2009 [Page 29]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 30]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 31]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 32]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 33]
Internet-Draft Design for a Nameserver Control Protocol October 2008
}
}
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 30, 2009 [Page 34]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 35]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 36]
Internet-Draft Design for a Nameserver Control Protocol October 2008
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 30, 2009 [Page 37]
Internet-Draft Design for a Nameserver Control Protocol October 2008
Authors' Addresses
John A Dickinson
6 Nelson Close
Wallingford, Oxfordshire OX10 0LG
UK
Email: jad@jadickinson.co.uk
Stephen Morris
Nominet UK
Minerva House
Edmund Halley Road
Oxford Science Park
Oxford, Oxfordshire OX4 4DQ
UK
Email: stephen.morris@nominet.org.uk
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 30, 2009 [Page 38]
Internet-Draft Design for a Nameserver Control Protocol October 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.
Dickinson, et al. Expires April 30, 2009 [Page 39]