|Network Working Group||P. R. Regnauld|
|Internet Draft||catpipe ApS|
|Intended status: Informational||AFNIC|
|Expires: June 2007||December 2006|
Requirments for the Nameserver Communication protocol
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 in June 2007.
Copyright © The Internet Society (2006). All Rights Reserved.
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.
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 .
As in other RFC describing requirments (such as ), 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.
Administrators of DNS (, ) 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.
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 (), 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.
A large ISP may manage thousands of zones. For reliability reasons, following , 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.
To implement the recommandations of , a one-site organization typically needs to request secondary hosting located on a distinct organization's premises.
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.
Since the two participants in a conversation are servers, we use the following vocabulary:
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.
|||Mockapetris, P., “Domain names - concepts and facilities”, STD 13, RFC 1034, November 1987.|
|||Mockapetris, P., “Domain names - implementation and specification”, STD 13, RFC 1035, November 1987.|
|||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.|
|||Elz, R., Bush, R., Bradner, S., and M.A. Patton, “Selection and Operation of Secondary DNS Servers”, BCP 16, RFC 2182, July 1997.|
|||Newton, A., “Cross Registry Internet Service Protocol (CRISP) Requirements”, RFC 3707, February 2004.|
|||Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, April 2006.|
|||ISC, , “Berkeley Internet Name Domain is an implementation of the Domain Name System (DNS) protocols”, October 2006.|
|||Hubert, , “PowerDNS, an advanced high performance authoritative nameserver”, March 2006.|
PowerDNS () 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.
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.
Copyright © 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.
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 firstname.lastname@example.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).