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",
<http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/
Bv9ARM.html>.
[KASP] "OpenDNSSEC Documentation: kasp.xml", <http://
trac.opendnssec.org/wiki/Signer/Using/Configuration/kasp>.
[NSD] "NSD README file",
<http://www.nlnetlabs.nl/svn/nsd/trunk/doc/README>.
[PKCS#11] "PKCS #11: Cryptographic Token Interface Standard",
<http://www.rsa.com/rsalabs/node.asp?id=2133>.
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]