Network Working Group R. Arends Internet-Draft S. Morris Intended status: Informational J. Dickinson Expires: May 22, 2008 Nominet November 19, 2007 Name Server Control Protocol draft-arends-nscp-00 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 May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes the Name Server Control Protocol (NSCP). The NSCP will permit the management of diverse name server implementations. The NSCP uses NETCONF as framework. Arends, et al. Expires May 22, 2008 [Page 1] Internet-Draft NSCP November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 2. High level requirements . . . . . . . . . . . . . . . . . . . . 3 3. Approaches to Nameserver Control . . . . . . . . . . . . . . . 4 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. A generic model . . . . . . . . . . . . . . . . . . . . . . 4 4.2. A Structured DNS model . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Arends, et al. Expires May 22, 2008 [Page 2] Internet-Draft NSCP November 2007 1. Introduction 1.1. Rationale Operators of name servers often deploy software from multiple different vendors in order to reduce the threat from vulnerabilities found in any single implementation. However, doing so requires understanding a different control interface for each implementation. Additionally, provisioning for name server clusters does not scale well, since it often requires active lower level management of individual hosts. This document defines a DNS name server control protocol which will permit management of multiple different name server implementations via a common interface. The NSCP will use NETCONF [1]as framework. 1.2. Reserved Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. High level requirements The Protocol should: o Enable the operation of all nameserver implementations o Allow the (un)setting of all nameserver configuration parameters o Be able to signal which operations are supported by the implementation being controlled o Allow the collection of any available nameserver statistics o Be extensible to allow implementors to extend to cover new objects and methods. o Be able to handle any dns data that might be seen on the wire, whether or not it is legal. The requirements for the protocol are independent of the actual functions that a nameserver implementation provides. Any operation listed in this document does not require support for this function in an implementation. It is RECOMMENDED however, that functions which are supported by nameservers can be supported by this protocol, either as a core function, or as part of the extentions. The level of feedback, such as state, or statistics that an implementation returns differs per implementation. This document Arends, et al. Expires May 22, 2008 [Page 3] Internet-Draft NSCP November 2007 does not dictate form or grammar of this feedback, but does allow the transfer of this data. The extensibility of the protocol should be rich enough to allow for various forms and ways of aggregating this feedback. 3. Approaches to Nameserver Control There have been several different approaches suggested for controlling nameservers. Possibilities include, but are not limited to, NETCONF, SNMP, some kind of in-band DNS based solution or a totally new protocol. Whilst any of these solutions can work we favor a solution based on NETCONF for the following reasons. o It is based on XML. o It operates persistent connections. o It operates a command/response model. o The protocol describes how error information is returned from the agent to the client. o It is extensible. o It allows a client to discover the set of protocol extensions supported by a server. o It provides a separation of configuration and state data. o It is designed to run on multiple different transports such as ssh which have built-in strong authentication and encryption. o It provides sophisticated searching capabilities. 4. Data Model Netconf treats the contents of its configuration elements as opaque data and assumes that the application will know what to do with it. For this reason it is necessary to define a data model to contain DNS configuration data. This data model will be required for use in NSCP and may be of use to developers of future nameserver implementations. There are several options for doing this, two of which are presented here: 4.1. A generic model A typical nameserver configuration file is made up of sections and configuration items. A possible representation is shown in the following fragment of XML: Arends, et al. Expires May 22, 2008 [Page 4] Internet-Draft NSCP November 2007
10.0.0.1 not available
example.com example.com.zone
4.2. A Structured DNS model Analysis of a range of nameserver configurations leads to a model that is specific to DNS, such as: Server | +------------+------------+ | | PeerGroup Panorama |1 |1 | | |* 1 * |* Peer ACL -------- View -------- Zone |1 1 * |1 | | |* |* ACE RRSet |1 | |1..* RR ^ --[ Inheritance symbol | | Specific RR In the above diagram, the names of the elements correspond to standard DNS concepts, with the following additions: o Peer - either a master or slave of the server in question. o PeerGroup - the collection of Peers. o Panorama - a collection of views. 5. Security Considerations Arends, et al. Expires May 22, 2008 [Page 5] Internet-Draft NSCP November 2007 6. Informative References [1] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. Authors' Addresses Roy Arends Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM Phone: +44 1865 332211 Email: roy@nominet.org.uk Stephen Morris Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM Phone: +44 1865 332211 Email: stephen.morris@nominet.org.uk John Dickinson Nominet 6 Nelson Close OX10 0LG UNITED KINGDOM Phone: +44 7789485308 Email: jad@dickinson.co.uk Arends, et al. Expires May 22, 2008 [Page 6] Internet-Draft NSCP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Arends, et al. Expires May 22, 2008 [Page 7]