Indicating Non-Availability of Dynamic Updates in the DNS

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 https://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 19 December 2025.¶

Copyright Notice

Copyright (c) 2025 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[RFC2136] specifies a mechanism for clients to update zones in the DNS dynamically. This Dynamic Update mechanism is widely-deployed and is used, for example, to update DNS records in response to a local change of IP address.¶

Many zones, however, do not support Dynamic Update 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 DNS UPDATE traffic 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 support Dynamic Update.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document assumes familiarity with the terminology of the Domain Name System as described in [RFC9499].¶

This document uses the abbreviation SOA.MNAME to mean the MNAME field of the RDATA of an SOA Resource Record.¶

This document uses the phrase "Dynamic Update" to describe the general facility used by clients to request changes to DNS data published by authority servers, and "DNS UPDATE" to refer to the particular DNS messages used to make that happen. See [RFC2136] for more information about Dynamic Update.¶

3. Use of SOA.MNAME

The Start of Authority (SOA) Resource Record (RR) is defined in [RFC1035]. The MNAME field of the SOA RDATA (SOA.MNAME) 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 SOA.MNAME, 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 known implementations of authority-only servers known to the author which use SOA.MNAME 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.¶

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

In [RFC2136] SOA.MNAME was again used to provide a definition of the term "Primary Master", in this case for the purpose of identifying the server towards which DNS UPDATE messages relating to that zone should be sent.¶

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

This document specifies a convention by which a zone operator may include an empty SOA.MNAME in order to deliberately specify that there is no appropriate place for Dynamic Update messages to be sent, i.e. that the corresponding zone does not support Dynamic Update.¶

4. Operations

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

5. Impact on Deployed Systems and Protocols

6. Updates to RFC 2136

[RFC2136] is updated to reflect the interpretation of an empty SOA.MNAME to mean that the enclosing zone does not support Dynamic Update.¶

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 Update for the zones they host might experience a security benefit from reduced DNS UPDATE traffic by including an empty SOA.MNAME in those zones, since the absence of that unwanted traffic might provide additional headroom in network bandwidth and server capacity for legitimate and intended DNS traffic.¶

Clients that normally send DNS UPDATE messages might see a security benefit from not leaking the information contained within those messages to nameservers that are not configured to receive them.¶

8. IANA Considerations

This document makes no requests of the IANA.¶

9. References

Appendix A. Empty SOA.MNAME Observed in SOA Responses

A quick check using a variety of passive DNS datasets relating to observed traffic on 2024-10-30 reveals examples of responses with empty SOA.MNAME in the real world, as illustrated in Table 1. This perhaps suggests that a study with normalisation and a longer time base might be useful to include in a future revision of this draft.¶

Acknowledgments

Various participants in the DNSOP working group provided feedback to this idea when it was originally circulated in 2008. The names of the people have concerned have long since faded from memory, but the authors thank them generally and anonymously, regardless.¶

Raffaele Sommese helped quantify existing observed use of SOA responses with empty MNAME fields in a variety of passive DNS datasets, as summarised briefly in Appendix A.¶

Authors' Addresses