Network Working Group J. Dickinson Internet-Draft S. Dickinson Intended status: Standards Track Sinodun Internet Technologies Expires: September 15, 2011 S. Morris Internet Systems Consortium R. Arends Nominet UK March 14, 2011 A name server Data Model draft-dickinson-dnsop-nameserver-control-02.txt Abstract This document presents a data model for a name server, to be used in the construction of a name server control protocol. 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 September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Dickinson, et al. Expires September 15, 2011 [Page 1] Internet-Draft A name server Data Model March 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. View . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Elements for the default CHAOS class . . . . . . . . . 7 2.3. Access Control List . . . . . . . . . . . . . . . . . . . 7 2.3.1. ACE . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Default . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 2.4.2. Elements . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. PeerGroup . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 10 2.6. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 10 2.7. DNSSECPolicy . . . . . . . . . . . . . . . . . . . . . . . 11 2.7.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 11 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 5.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Dickinson, et al. Expires September 15, 2011 [Page 2] Internet-Draft A name server Data Model March 2011 1. Introduction In the -00 and -01 versions of this draft we discussed a data model for NSCP, the potential use of NETCONF as the transport layer and YANG as a modeling language. In this version, we have removed the text on NETCONF and YANG for the time being so that we can concentrate on the data model. In the future, discussion of possible transports for the data and its transformations may be added to this or a completely new draft on that subject. In addition, this version of the draft concentrates on authoritative servers. Resolvers and validators will be added in future versions. 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. Data Model A key requirement of [I-D.ietf-dnsop-name-server-management-reqs] is the standardisation of a data model representing name servers. With such a model, a protocol can de designed to communicate between a client and a name server. 1.3. 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 September 15, 2011 [Page 3] Internet-Draft A name server Data Model March 2011 2. Data Model This diagram is a refinement on the one in previous versions of this draft in that it shows the relationships between the major elements of the server. Server |1 | |2-* +------View |* |1 | | |* |* ACL Zone----------+ |1 |1 |* | | | |* |* |0-1 ACE---PeerGroup DNSSECPolicy |* | |1-* Peer (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 entity - what it represents and its purpose. o A list of the object's elements - the name of each element and the contents. Every object may have associated statistics elements. These have not been shown in the above diagram for clarity. Some are described in this document but many more are likely to be added to later versions of this draft. In this data model it is expected that filenames and directory structures will be fixed by the implementation. Therefore, for example, a zone does not have a filename element and the server does not have a working directory or pid file specified. At this stage, this draft does not attempt to contain every configuration element in all existing name servers. It is anticipated that vendor specific extensions will be added to allow full configuration of a specific implementation. However, this model Dickinson, et al. Expires September 15, 2011 [Page 4] Internet-Draft A name server Data Model March 2011 (when finished) should be sufficient to allow basic command and control of most name servers. 2.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.1. Elements o Reference to 2 or more Views o Statistics It is assumed that the server is capable of generating the subset of Bind 8 style statistics currently supported by both NSD [NSD] and Bind 9 [BIND9ARM]. These are the statistics relevant at the server level. Additional statistics will be added to other elements in the model. * SAns Count of answers sent * RAXFR Count of AXFR initiated * RQ Count of requests received * SNXD Count of NXDomain sent * RUQ Count of non-recursive queries rejected * RURQ Count of recursive queries rejected * RUXFR Count of XFR rejected * RUUpd Count of updates rejected Dickinson, et al. Expires September 15, 2011 [Page 5] Internet-Draft A name server Data Model March 2011 2.2. View 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 properties of the query packet o Source address (and port). o Destination address (and port). o Whether or not the query requests recursion. (Not used in this version of the draft) In the authoritative server case currently being considered in this draft, the replies can differ in terms of o Which zones are available to a given client. o The contents of those zones. 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 the NSCP data model, even if the name server concerned does not implement views. All implementations of NSCP MUST implement a view named _default" of class IN and a similarly-named view for class CHAOS. (The latter view is required to serve the "version.bind" and "server.id" RRs - see below.) 2.2.1. Elements o Name A name for the view. o Class Which class this view is for. Default is IN. o Reference to 0 or 1 ACL for source address o Reference to 0 or 1 ACL for destination address. o References to 0 or more Zones. o ListenOn What IP address and port to bind this view to. This can occur zero or more times. The IP address can be either IPV4 or IPV6. Dickinson, et al. Expires September 15, 2011 [Page 6] Internet-Draft A name server Data Model March 2011 The address/network is represented in standard form (e.g. 192.0.2.0/24 or 2001:0DB8::/32) o Port Optional port number. 2.2.2. Elements for the default CHAOS class o Version The version of the name server to report in response to a query for the name version.bind, type TXT in the CHAOS class. If set to "none" then the server will not respond. o ServerId The id a server should report in response to a query for id.server, type TXT in the CHAOS class. If set to "none" then the server will not respond. 2.3. 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 referenced by a zone. This will be considered further in a future version of this draft. An ACL contains the following elements: o Name Unique identifier used by a view to refer to the ACL o ACE Reference to zero or more access control entries, each entry defining a match between an identifier and access modes. o Default Zero or one default ACE - the access check will stop on the first match, and a default matches everything: once the default ACE is reached, no more ACEs will be checked. 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 Dickinson, et al. Expires September 15, 2011 [Page 7] Internet-Draft A name server Data Model March 2011 MUST be denied. 2.3.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 PeerGroup 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: 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. 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.3.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.4. Zone 2.4.1. Discussion The zone object represents a zone served by the name server and comprises a collection of resource records. It is anticipated that the zone data will not be created via NSCP, instead being defined by the contents of a zone file or an external database populated and Dickinson, et al. Expires September 15, 2011 [Page 8] Internet-Draft A name server Data Model March 2011 transported to the name server via a different method or in band to DNS via dynamic updates or a zone transfer. If it is necessary to transmit zone contents using NSCP then it is anticipated that this can be defined using an extension to this data model. (This will be the subject of a separate draft.) This means that with this basic data model it will only be possible to provision zones via AXFR by specifying a master server from which the secondary name server will have to obtain the zone data or, in the case of a master name server generation of a zone stub (SOA + 1 NS) to allow dynamic updates. 2.4.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 PeerGroup that can act as a master server for this zones. This can occur zero or more times. o Secondary The identifier of a PeerGroup 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 secondary can appear for a single zone. o Notify The identifier of a PeerGroup to which notifies should be sent to for this zone. This can occur zero or more times. o SOA An SOA RR that is sufficient to allow population of zone via dynamic updates. o NS One or more NS RR that will be sufficient to allow population of zone via dynamic updates. o References to 0 or 1 DNSSECPolicies 2.5. PeerGroup Named groups of peers. A group may consist of one or more peers. All references to external systems will be by reference to a PeerGroup. The components of a PeerGroup are: Dickinson, et al. Expires September 15, 2011 [Page 9] Internet-Draft A name server Data Model March 2011 2.5.1. Elements o Name A name for a PeerGroup. This name is unique, and is used elsewhere in the model as a reference to external systems. o References to 1 or more Peers. 2.6. Peer A Peer is an object representing any external system or systems. It either participates in the authoritative name server service by being a master or a secondary, or is a system that uses the name server service. A Peer can be identified by a combination of: o As the holder of a particular TSIG key. o By address range (including an address range indicating a single address) and optional port. Where 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 For maximum flexibility Peers do not exist in isolation. Instead, they are members of at least one PeerGroup (even if that group comprises only the Peer). 2.6.1. Elements o Name A name for this Peer. This name is unique. 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). Dickinson, et al. Expires September 15, 2011 [Page 10] Internet-Draft A name server Data Model March 2011 * 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. 2.7. DNSSECPolicy The DNSSEC policy defines a policy for any DNSSEC signing operations performed by a name server. It is based on the kasp.xml file in OpenDNSSEC [KASP]. 2.7.1. Elements o Name The name for this policy. This must be unique. It will be referred to by zones to specify how the zone will be signed. o Signatures Parameters for the signatures created using the policy. * Resign The re-sign interval. * Refresh The refresh interval, detailing when a signature should be refreshed. * Validity + Default Validity interval for all RRSIG records except those related to NSEC or NSEC3 records. + Denial Validity interval for all RRSIG records related to NSEC or NSEC3 records. Dickinson, et al. Expires September 15, 2011 [Page 11] Internet-Draft A name server Data Model March 2011 * Jitter Value added to or extracted from the expiration time of signatures to ensure that not all signatures expire at the same time. * InceptionOffset Duration subtracted from the time at which a record is signed to give the start time of the record. * Denial This includes one element, either NSEC3 (as shown) or an empty NSEC element. + NSEC Instruction to use the NSEC scheme for authenticated denial of existence, described in [RFC4034]. This element MUST not occur alongside an NSEC3 element. + NSEC3 Instruction to use the NSEC3 scheme for authenticated denial of existence, described in [RFC5155]. This element MUST not occur alongside an NSEC element - OptOut If present, enable an "opt out" optimisation that means that NSEC3 records are only created for authoritative data or for secure delegations; insecure delegations have no NSEC3 records. - Resalt The interval between generating new salt values for the hashing algorithm. - Hash Values for parameters of the hashing algorithm, as described in RFC 5155. o Algorithm Integer specifying the algorithm listed in the IANA DNSSEC NSEC3 Hash Algorithms registry. o Iteration The number of additional times the hash function will be performed. o SaltLength The length of the Salt field in octets, ranging in value from 0 to 255 Dickinson, et al. Expires September 15, 2011 [Page 12] Internet-Draft A name server Data Model March 2011 * Keys + TTL The time-to-live value for the DNSKEY resource records. + RetireSafety This interval is the safety margin added to calculated timing values to ensure that keys are retired without there being a chance of signatures created with the keys being considered invalid. + PublishSafety This interval is the safety margin added to calculated timing values to ensure that keys are published without there being a chance of signatures created with the keys being considered invalid. + ShareKeys If multiple zones are associated with a policy, the presence of ShareKeys indicates that a key can be shared between zones. + Purge If Purge is present, keys marked as dead will be automatically purged from the database after this interval. * KSK + Algorithm Determines the algorithm used for the key (the numbers reserved for each algorithm can be found in the appropriate IANA registry). + Lifetime Determines how long the key is used for before it is rolled. + Respository Determines the location of the keys. Keys are stored in repositories which are either hardware or software security modules that conform to the PKCS#11 standard [PKCS#11]. + ManualRollover If present, indicate thats the key rollover will only be initiated on the command of the operator. * ZSK Dickinson, et al. Expires September 15, 2011 [Page 13] Internet-Draft A name server Data Model March 2011 + Algorithm Determines the algorithm used for the key (the numbers reserved for each algorithm can be found in the appropriate IANA registry). + Lifetime Determines how long the key is used for before it is rolled. + Respository Determines the location of the keys. Keys are stored in repositories which are either hardware or software security modules that conform to the PKCS#11 standard. * Zone + PropagationDelay The amount of time needed for information changes at the master server for the zone to work its way through to all the secondary nameservers. + SOA Values of parameters for the SOA record in the signed zone. - TTL TTL of the SOA record. - Minimum Value for the SOA's "minimum" parameter. - Serial The format of the serial number in the signed zone (either counter, datecounter, unixtime or keep). * Parent + PropagationDelay The interval between the time a new KSK is published in the zone and the time that the DS record appears in the parent zone. + DS Information about the DS record in the parent. - TTL TTL of the DS record in the parent zone. Dickinson, et al. Expires September 15, 2011 [Page 14] Internet-Draft A name server Data Model March 2011 + SOA Information about parameters of the parent's SOA record. - TTL TTL of the SOA record. - Minimum Value for the SOA's "minimum" parameter. Dickinson, et al. Expires September 15, 2011 [Page 15] Internet-Draft A name server Data Model March 2011 3. IANA Considerations This memo includes no request to IANA. Dickinson, et al. Expires September 15, 2011 [Page 16] Internet-Draft A name server Data Model March 2011 4. Security Considerations To be completed. Dickinson, et al. Expires September 15, 2011 [Page 17] Internet-Draft A name server Data Model March 2011 5. References 5.1. Normative References [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-05 (work in progress), January 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. 5.2. Informative References [BIND9ARM] "BIND 9 Administrator Reference Manual", . [KASP] "OpenDNSSEC Documentation: kasp.xml", . [NSD] "NSD README file", . [PKCS#11] "PKCS #11: Cryptographic Token Interface Standard", . Dickinson, et al. Expires September 15, 2011 [Page 18] Internet-Draft A name server Data Model March 2011 Authors' Addresses John A Dickinson Sinodun Internet Technologies Stables 4 Suite 11 Howbery Park Wallingford, Oxfordshire OX10 8BA UK Email: jad@sinodun.com Sara A Dickinson Sinodun Internet Technologies Stables 4 Suite 11 Howbery Park Wallingford, Oxfordshire OX10 8BA UK Email: sara@sinodun.com Stephen Morris Internet Systems Consortium 950 Charter Streed Redwood City CA 94063 USA 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 September 15, 2011 [Page 19]