



Domain Name System Operations                                   J. Abley
Internet-Draft                                                Cloudflare
Updates: 2136 (if approved)                                 P. Thomassen
Intended status: Standards Track       deSEC, Secure Systems Engineering
Expires: 19 December 2025                                   17 June 2025


       Indicating Non-Availability of Dynamic Updates in the DNS
                  draft-jabley-dnsop-missing-mname-01

Abstract

   The Start of Authority Resource Record in the Domain Name System
   includes 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 clients use Dynamic Update to send DNS UPDATE
   messages.  Many zones do not support the Dynamic Update, 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 support Dynamic
   Update.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-jabley-dnsop-missing-mname/.

   Discussion of this document takes place on the Domain Name System
   Operations Working Group mailing list (mailto:dnsop@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/dnsop/.
   Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ableyjoe/draft-jabley-dnsop-missing-mname.







Abley & Thomassen       Expires 19 December 2025                [Page 1]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use of SOA.MNAME  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  DNS Software  . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Zone Administrators . . . . . . . . . . . . . . . . . . .   4
     4.3.  Dynamic Update Clients  . . . . . . . . . . . . . . . . .   5
   5.  Impact on Deployed Systems and Protocols  . . . . . . . . . .   5
     5.1.  Impact on DNS NOTIFY  . . . . . . . . . . . . . . . . . .   5
     5.2.  Impact on Dynamic Update  . . . . . . . . . . . . . . . .   6
     5.3.  Unintended Consequences . . . . . . . . . . . . . . . . .   6
   6.  Updates to RFC 2136 . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6



Abley & Thomassen       Expires 19 December 2025                [Page 2]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Empty SOA.MNAME Observed in SOA Responses  . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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



Abley & Thomassen       Expires 19 December 2025                [Page 3]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


   [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

4.1.  DNS Software

   DNS software MUST accept an empty value of SOA.MNAME as valid.  This
   includes software that consumes, generates, collects, manages and
   validates DNS messages and software that provides related
   provisioning and user interfaces for zone administrators.

4.2.  Zone Administrators

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








Abley & Thomassen       Expires 19 December 2025                [Page 4]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


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

             Figure 1: SOA Resource Record with empty SOA.MNAME

4.3.  Dynamic Update Clients

   Dynamic Update clients who identify the recipient of DNS UPDATE
   messages from the value of SOA.MNAME SHOULD interpret an empty
   SOA.MNAME as an indication that Dynamic Updates are unsupported by
   that zone.

   Dynamic Update clients SHOULD NOT send DNS UPDATE messages for zones
   whose SOA.NAME is empty.

5.  Impact on Deployed Systems and Protocols

5.1.  Impact on DNS NOTIFY

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

   For zones where the value of SOA.MNAME record corresponds to a
   namserver listed in the apex NS RRSet, making the MNAME field empty
   might cause additional DNS NOTIFY traffic, since DNS NOTIFY messages
   that would have been suppressed towards the nameserver published as
   SOA.MNAME will instead be sent.

   Authoritative DNS infrastructure deployed on a scale where high
   NOTIFY traffic is a concern often uses dedicated zone transfer
   servers, separate from the authoritative nameservers intended to
   receive queries from the Internet, and in that situation no
   additional DNS NOTIFY traffic would be expected.  However, in other
   situations, the operators of the authority-only servers for the zone
   might choose to avoid any unwanted NOTIFY traffic by using an
   explicit notify list.










Abley & Thomassen       Expires 19 December 2025                [Page 5]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


5.2.  Impact on Dynamic 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 SOA.MNAME is intended to
   prevent a Dynamic Update client from finding a server to send DNS
   UPDATE messages to.

5.3.  Unintended Consequences

   Some concern has been raised in the past that an empty SOA.MNAME
   might result in unwanted traffic being sent to root servers, e.g. for
   clients that might interpret the MNAME as a host name and try to use
   the DNS to find addresses for it.

   Use of an empty SOA.MNAME is not new; cursory analysis of passive DNS
   data demonstrates a robust volume of DNS responses that include an
   empty SOA.MNAME for zones across a variety of top-level domains.  No
   negative consequences of this traffic have been identified.  See
   Appendix A for discussion.

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



Abley & Thomassen       Expires 19 December 2025                [Page 6]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


9.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://www.rfc-editor.org/rfc/rfc1996>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/rfc/rfc2136>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

9.2.  Informative References

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

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.














Abley & Thomassen       Expires 19 December 2025                [Page 7]

Internet-Draft     Non-Availability of Dynamic Updates         June 2025


               +========+=========+=======================+
               | source | counter | notes                 |
               +========+=========+=======================+
               | com    | 109328  |                       |
               +--------+---------+-----------------------+
               | net    | 8854    |                       |
               +--------+---------+-----------------------+
               | org    | 1792    |                       |
               +--------+---------+-----------------------+
               | czds   | 964     |                       |
               +--------+---------+-----------------------+
               | imp    | 634     | old gTLDs e.g. aero   |
               +--------+---------+-----------------------+
               | opencc | 111     | see openintel website |
               +--------+---------+-----------------------+

                   Table 1: DNS Responses Observed with
                             empty SOA.MNAME

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

   Joe Abley
   Cloudflare
   Email: jabley@cloudflare.com


   Peter Thomassen
   deSEC, Secure Systems Engineering
   Email: peter@desec.io











Abley & Thomassen       Expires 19 December 2025                [Page 8]
