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

Versions: 00

Network Working Group                                        P. Regnauld
Internet-Draft                                               catpipe ApS
Intended status: Informational                             S. Bortzmeyer
Expires: June 22, 2007                                             AFNIC
                                                       December 19, 2006


         Requirments for the Nameserver Communication protocol
                   draft-regnauld-ns-communication-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 June 22, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).













Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 1]


Internet-Draft          Nameserver communication           December 2006


Abstract

   This document describes the requirments for a protocol to allow DNS
   nameservers to communicate among themselves, possibly outside the
   existing DNS protocol, for purposes of zone discovery and
   provisioning and remote management.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Having a homogeneous view of non-standard zones  . . . . .  5
     3.2.  Exchanging secondary name service with partners  . . . . .  5
     3.3.  Managing remote name servers . . . . . . . . . . . . . . .  5
   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  The requirments  . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Related work  . . . . . . . . . . . . . . . . . . . . 12
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

























Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 2]


Internet-Draft          Nameserver communication           December 2006


1.  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 [3].

   As in other RFC describing requirments (such as [5]), the MUST and
   MUST NOT have to be interpreted in terms of the protocol, not in
   terms of the implementation.  If this document says that the
   protocole MUST do something, it means that the protocol must have a
   way to describe this "something", not that every implementation has
   to implement it or that every running instance has to allow it.  For
   instance, the AXFR zone transfer of the DNS is a MUST of the protocol
   but an implementation may omit it and a specific nameserver is
   certainly free to disable it.




































Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 3]


Internet-Draft          Nameserver communication           December 2006


2.  Introduction

   Administrators of DNS ([1], [2]) Nameservers often need to
   communicate to exchange meta-information, which cannot be distributed
   by the DNS, or to request various administrative tasks such as the
   provisioning of a new zone or querying the list of managed zones.
   Currently, this is done by ad hoc means, often manually.  When a
   formal protocol exists (see Appendix A), it is always proprietary and
   undocumented.  We believe it would be nice to have a "nameserver
   communication" protocol to address these needs.

   This document specifies the requirments for such a protocol.  The
   choice is to define one protocol for all the currently out-of-band
   tasks of nameserver management.  The rationale is that each task is
   quite simple and relatively easy to define so one protocol for each
   task would be overkill.

   The use cases below describe typical scenarios where such a protocol
   would be useful for the nameserver administrators.
































Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 4]


Internet-Draft          Nameserver communication           December 2006


3.  Use cases

3.1.  Having a homogeneous view of non-standard zones

   If an organization uses non-standard zones (such as a purely-local
   TLD, but not only), synchronizing all the nameservers so they all see
   these zones is usually a time-consuming task.  It is even worse if
   two such organizations merge.

   This is typically done, when using BIND ([7]), with "stub" or
   "forward" zones.  But there is no way to ensure automatically that
   all the resolvers have the same set of zones at a given time, as new
   zones may be added locally, without the other nameservers being
   updated to reflect the change.  The problem can be mitigated by
   concentrating DNS queries through a core set of nameservers, but
   these still require to be updated when zones are added on the various
   nameservers.

   Though the architecture described above is not recommended, such
   scenarios do happen in the wild, especially when several large
   organizations are connected together.

3.2.  Exchanging secondary name service with partners

   A large ISP may manage thousands of zones.  For reliability reasons,
   following [4], it should have secondary nameservers placed in widely
   different geographic areas.  A common solution is to establish cross-
   hosting agreeements (zone exchange) with a partner in the "I'll host
   your zones and you'll host mine" fashion.

   In the absence of a standard protocol to discover the available zones
   in the scope of this agreement (one server may be secondary for
   several other organizations), such exchange of service has to be done
   manually, each time a zone is created or deleted, or through
   proprietary means such as email in a structured, authenticated
   format.

   The above is equally true for the management of nameservers within a
   single organization, in order to provision secondary nameservers
   located in affiliate / branch offices from a central location in an
   automatic fashion.

3.3.  Managing remote name servers

   To implement the recommandations of [4], a one-site organization
   typically needs to request secondary hosting located on a distinct
   organization's premises.




Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 5]


Internet-Draft          Nameserver communication           December 2006


   Many ccTLDs do so, for instance.  But, in that case, the
   "outsourcing" organization has typically no control of the
   nameservers.  Changing the IP address of the master nameserver, or
   forcing a reload when a SOA serial number accidentally wrapped is a
   manual operation at the remote site, and may require the
   intervention, and availablity, of the staff at the remote
   organization.












































Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 6]


Internet-Draft          Nameserver communication           December 2006


4.  Terminology

   Since the two participants in a conversation are servers, we use the
   following vocabulary:

   o  Requestor: the server which requests something (an information or
      an action),

   o  Responder: the server which will reply and may be act.










































Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 7]


Internet-Draft          Nameserver communication           December 2006


5.  The requirments

   The protocol:

   1.   MUST allow the requestor to authenticate the responder and vice-
        versa.

   2.   MUST allow the communication to be hidden from snoopers (relying
        on a transport like TLS - [6] - is possible).

   3.   MUST provide anti-replay protection (making all the requests
        idempotent is a possible way),

   4.   MUST provide a standard vocabulary to express the types of zones
        ("master" or "slave" but also the non-standard terms "stub" and
        "forward" in BIND, zones for which the responder is
        authoritative but does not have the data itself).

   5.   MUST honor existing definition of views based on predefined
        shared key or IP address scope, so that information specific to
        a particular view, and only this information, will be returned
        to the requestor if the requestor's credentials match those of
        the defined view (for example, a zone may be of type master in
        one view, and forward in another).  DISCUSSION: a requestor can
        manage views where its IP address would show it another view.
        May be explicitely naming views would be better?

   6.   MUST provide a way to query a responder on the zones it serves
        with authority.  The response format MUST allow to carry other
        information besides the zone name, such as the type of the zone.

   7.   MUST provide a way to request the provisioning of a new zone.
        It MUST allow for at least the following parameters:

        1.  IP address(es) of the master(s),

        2.  type of the zone,

        3.  and may be contact information?

   8.   MUST allow a way to tell the responder, if it is acting as a
        slave, to reload a zone, regardless of the current value of the
        SOA serial number.

   9.   SHOULD be implementable as a one request / one response system
        where the request is self-sufficient and carries all the
        information that the responder needs.  Such a system would allow
        for various transports such as email or simple TCP mapping.



Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 8]


Internet-Draft          Nameserver communication           December 2006


   10.  MAY provide a standard vocabulary to express protections (ACL)
        for a zone.  DISCUSSION: it would be a very good thing but
        standardizing ACL language may be a daunting task.  A simpler
        solution may be simply to have a boolean telling if the zone is
        private (internal to an organization) or public.  Additionnally,
        it may be required to implement a concept of scope, so that it
        can be specified which agreement the zone is bound to (in the
        case of many-to-many secondary cross-hosting relationships).
        (Another way to implement scope could be to use the identity of
        the requestor, since it is authenticated.  See the next
        requirment.)








































Regnauld & Bortzmeyer     Expires June 22, 2007                 [Page 9]


Internet-Draft          Nameserver communication           December 2006


6.  Security Considerations

   Allowing remote configuration of a nameserver is a very sensitive
   issue, particularly when said server may be serving other third-party
   zones.  Therefore the security requirments listed above (allowing
   reciprocal authentication and protection against snoopers) are a
   MUST.

   There are no other requirments for the protocol itself but, for the
   implementations, it is reasonable to ask that, by default, all
   requests via this protocol must be denied.

   In the same way, authorisation of requestors, once they are
   authentified by the protocol, is up to the implementations.  They
   should allow fine-grained configuration of permissions.  Implementors
   should be warned that the authorized requestors of a responder may
   not trust each other.


































Regnauld & Bortzmeyer     Expires June 22, 2007                [Page 10]


Internet-Draft          Nameserver communication           December 2006


7.  References

7.1.  Normative References

   [1]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [4]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and
        Operation of Secondary DNS Servers", BCP 16, RFC 2182,
        July 1997.

   [5]  Newton, A., "Cross Registry Internet Service Protocol (CRISP)
        Requirements", RFC 3707, February 2004.

   [6]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
        Protocol Version 1.1", RFC 4346, April 2006.

   [7]  ISC, "Berkeley Internet Name Domain is an implementation of the
        Domain Name System (DNS) protocols", October 2006,
        <http://www.isc.org/index.pl?/sw/bind/>.

   [8]  Hubert, "PowerDNS, an advanced high performance authoritative
        nameserver", March 2006, <http://wiki.powerdns.com/>.




















Regnauld & Bortzmeyer     Expires June 22, 2007                [Page 11]


Internet-Draft          Nameserver communication           December 2006


Appendix A.  Related work

   PowerDNS ([8]) has a proprietary protocol, Supermaster, which allows
   remote provisioning of zones: See
   <http://doc.powerdns.com/slave.html#SUPERMASTER>.

   Microsoft AD/DNS and Infoblox also have such a protocol: a zone
   created on the master can be created automatically on the slaves.











































Regnauld & Bortzmeyer     Expires June 22, 2007                [Page 12]


Internet-Draft          Nameserver communication           December 2006


Appendix B.  Acknowledgements

   The original idea came from Bert Hubert.  Edward Lewis, by its nice
   explanations on the bind-users mailing list, helped a lot.  Useful
   comments from Mohsen Souissi were integrated.














































Regnauld & Bortzmeyer     Expires June 22, 2007                [Page 13]


Internet-Draft          Nameserver communication           December 2006


Authors' Addresses

   Phil Regnauld
   catpipe ApS
   Snaregade 12, 2tv
   Copenhagen K  1205
   Denmark

   Email: regnauld@catpipe.net


   Stephane Bortzmeyer
   AFNIC
   Immeuble International
   Saint-Quentin-en-Yvelines  78181
   France

   Phone: +33 1 39 30 83 46
   Email: bortzmeyer+ietf@nic.fr
   URI:   http://www.afnic.fr/































Regnauld & Bortzmeyer     Expires June 22, 2007                [Page 14]


Internet-Draft          Nameserver communication           December 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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).





Regnauld & Bortzmeyer     Expires June 22, 2007                [Page 15]


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