[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/