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 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
2.  Use of the MNAME Field
3.  Operations
4.  Impact on DNS NOTIFY
5.  Impact on DNS UPDATE
6.  IANA Considerations
7.  Security Considerations
8.  Normative References
Appendix A.  Change History
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

[RFC2136] (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.) 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.

2.  Use of the MNAME Field

The Start of Authority (SOA) Resource Record (RR) is defined in [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). 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] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) 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] (Vixie, P., “A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY),” August 1996.), 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] (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.) 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.

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.

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

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.

4.  Impact on DNS NOTIFY

[RFC1996] (Vixie, P., “A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY),” August 1996.) 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.

5.  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 UPDATE messages to.

6.  IANA Considerations

This document makes no requests of the IANA.

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

8. Normative References

Appendix A.  Change History

This section to be removed prior to publication.

00

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

Author's Address

Full Copyright Statement

Copyright © 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.