Network Working Group                                           J. Abley
Internet-Draft                                            Afilias Canada
Intended status: BCP                                       June 27, 2008
Expires: December 29, 2008


       Indicating Non-Availability of Dynamic Updates in the DNS
                  draft-jabley-dnsop-missing-mname-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 December 29, 2008.

Abstract

   The Start of Authority (SOA) Resource Record (RR) in the Domain Name
   System (DNS) specifies various parameters related to the handling of
   data in DNS zones.  These parameters are variously used by authority-
   only servers, caching resolvers and DNS clients to guide them in the
   way that data contained within particular zones should be used.

   One particular field in the SOA RR is known as MNAME, which is used
   to specify the "Primary Master" server for a zone.  This is the
   server to which Dynamic Updates are sent by clients.  Many zones do
   not accept updates using the Dynamic Update mechanism, and any such
   DNS UPDATE messages which are received provide no usual purpose.  For
   such zones it may be preferable not to receive updates from clients



Abley                   Expires December 29, 2008               [Page 1]

 
Internet-Draft     Non-Availability of Dynamic Updates         June 2008


   at all.

   This document proposes a convention by which a zone operator can
   signal to clients that a particular zone does not accept Dynamic
   Updates.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Use of the MNAME Field  . . . . . . . . . . . . . . . . . . . . 3
   3.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Impact on DNS NOTIFY  . . . . . . . . . . . . . . . . . . . . . 4
   5.  Impact on DNS UPDATE  . . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Change History . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7































Abley                   Expires December 29, 2008               [Page 2]

 
Internet-Draft     Non-Availability of Dynamic Updates         June 2008


.  Introduction

   [RFC2136] specifies a mechanism for clients to update zones in the
   DNS dynamically.  This mechanism is widely-deployed by many end-
   station operating systems, where it is used (for example) to update
   DNS records in response to a local change of IP address.

   Many zones, however, do not accept dynamic updates from clients as a
   matter of policy.  For such zones, specifying a DNS server name in
   the MNAME field of an SOA record has no benefit, and in fact may well
   cause unwanted traffic (DNS UPDATE messages) to be received by the
   named server.

   This document proposes a convention by which a zone operator can
   signal to clients that a particular zone does not accept Dynamic
   Updates.


.  Use of the MNAME Field

   The Start of Authority (SOA) Resource Record (RR) is defined in
   [RFC1035].  The MNAME field of the SOA RDATA is defined in that
   document as "The <domain-name> of the name server that was the
   original or primary source of data for this zone."

   [RFC1035] includes no specific guidance on the use of the MNAME
   field, although the general tone in which SOA RDATA are discussed
   suggests that its intended purpose was for the management of zone
   transfers between authority-only servers.  There are no
   implementations of authority-only servers known to the author which
   use the MNAME field to manage or perform zone transfers, however; for
   bootstrapping reasons, commonly-deployed implementations require
   master servers to be specified explicitly, usually by address rather
   than name.

   The MNAME field was subsequently referred to in [RFC1996], as part of
   the definition of the term "Primary Master".  The server specified in
   the MNAME field was, by default, to be excluded from the set of
   servers to which DNS NOTIFY messages would be sent.

   In [RFC2136] the MNAME field was again used to provide a definition
   for the term "Primary Master", in this case for the purpose of
   identifying the server towards which dynamic updates for that zone
   should be sent.

   There have been no other references to the use of the MNAME in the
   RFC series.




Abley                   Expires December 29, 2008               [Page 3]

 
Internet-Draft     Non-Availability of Dynamic Updates         June 2008


   This document specifies a convention by which a zone operator may
   include an empty MNAME field in order to deliberately specify that
   there is no appropriate place for Dynamic Updates to be sent.


.  Operations

   Zone administrators who do not wish to receive Dynamic Updates from
   clients for a particular zone may specify an empty MNAME field in
   that zone's SOA RDATA.  The textual representation of an empty field
   in the canonical representation of zone data is a single ".", as
   illustrated in Figure 1.

    @       1800    IN      SOA     jabley.automagic.org. . (
                                        20080622    ; serial
                                        1800        ; refresh
                                        900         ; retry
                                        10800       ; expire
                                        1800 )      ; negative cache TTL

                                 Figure 1

   Dynamic Update clients who identify the Primary Master server as the
   recipient of DNS UPDATE messages from the MNAME field in SOA RDATA
   should interpret an empty MNAME field as an indication that no
   attempt to send a DNS UPDATE message should be made for the zone
   containing the SOA record.


.  Impact on DNS NOTIFY

   [RFC1996] specifies that the Primary Server, which is derived from
   the MNAME field of the SOA RDATA, be excluded from the set of servers
   to which NOTIFY messages should be sent.

   For zones whose SOA record contains an MNAME field which corresponds
   to a server listed in the apex NS set, making the MNAME field empty
   might well cause additional NOTIFY traffic.  If this is a concern,
   the operators of the authority-only servers for the zone might choose
   to specify an explicit notify list.


.  Impact on DNS UPDATE

   The goal of the convention specified in this document is to prevent
   Dynamic Update clients from sending DNS UPDATE messages for
   particular zones.  The use of an empty MNAME field is intended to
   prevent a Dynamic Update client from finding a server to send DNS



Abley                   Expires December 29, 2008               [Page 4]

 
Internet-Draft     Non-Availability of Dynamic Updates         June 2008


   UPDATE messages to.


.  IANA Considerations

   This document makes no requests of the IANA.


.  Security Considerations

   The convention described in this document provides no additional
   security risks to DNS zone or server administrators.

   Name servers which do not support Dynamic Updates for the zones they
   host might experience a security benefit from reduced DNS UPDATE
   traffic, the absence of that traffic provides additional headroom in
   network bandwidth and server capacity for legitimate query types.


.  Normative References

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

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.


Appendix A.  Change History

   This section to be removed prior to publication.

   00 Initial draft, circulated as draft-jabley-dnsop-missing-mname-00.














Abley                   Expires December 29, 2008               [Page 5]

 
Internet-Draft     Non-Availability of Dynamic Updates         June 2008


Author's Address

   Joe Abley
   Afilias Canada Corp.
   Suite 204, 4141 Yonge Street
   Toronto, ON  M2P 2A8
   Canada

   Phone: +1 416 673 4176
   Email: jabley@ca.afilias.info









































Abley                   Expires December 29, 2008               [Page 6]

 
Internet-Draft     Non-Availability of Dynamic Updates         June 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.











Abley                   Expires December 29, 2008               [Page 7]