AXFR message type for DNS NOTIFY
draft-pels-dnsop-axfr-notify-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Martin Pels , Florian Obser | ||
| Last updated | 2026-08-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pels-dnsop-axfr-notify-01
Network Working Group M. Pels
Internet-Draft F. Obser
Updates: 5936 (if approved) RIPE NCC
Intended status: Standards Track 10 August 2026
Expires: 11 February 2027
AXFR message type for DNS NOTIFY
draft-pels-dnsop-axfr-notify-01
Abstract
This document defines a new AXFR message type for DNS NOTIFY
messages, together with an accompanying subtype for the ZONEVERSION
EDNS(0) option. The message instructs a secondary server to perform
an AXFR zone transfer of a zone.
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 11 February 2027.
Copyright Notice
Copyright (c) 2026 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.
Pels & Obser Expires 11 February 2027 [Page 1]
Internet-Draft AXFR NOTIFY August 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol details . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Primary server behaviour . . . . . . . . . . . . . . . . 3
3.1.1. Initiation . . . . . . . . . . . . . . . . . . . . . 3
3.1.2. AXFR query processing . . . . . . . . . . . . . . . . 3
3.2. Secondary server behaviour . . . . . . . . . . . . . . . 4
4. The ZONETIMESTAMP ZONEVERSION Type . . . . . . . . . . . . . 5
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
DNS NOTFY[RFC1996] describes a method to inform secondary name
servers that a zone has changed. Upon receipt of a NOTIFY(SOA)
message, a secondary will query the primary server for the SOA of the
zone, and perform an IXFR[RFC1995] or AXFR[RFC5936] zone transfer if
the SOA SERIAL has been incremented since the last time the zone was
fetched.
There are cases when it is desirable to force a secondary server to
perform an AXFR zone transfer. Example scenarios are an incorrectly
synchronized database on a secondary server due to a software bug, a
signer implementation refreshing DNSSEC signatures or adding a ZONEMD
RRset without incrementing the SOA SERIAL, or an operator
incidentally wanting to propagate changes to a zone without updating
the SOA record.
Most authoritative DNS server software supports performing a forced
AXFR zone transfer. However, this can only be initiated by the
operator of the DNS server, and secondary servers for a zone may not
be managed by the same operator as the primary server(s). This
document defines a new NOTIFY(AXFR) message type, used to initiate
forced AXFR transfers by secondary servers from a primary server of a
zone. Additionally, a loop prevention mechanism is specified, using
a new ZONETIMESTAMP subtype for the ZONEVERSION EDNS(0)
option[RFC9660].
Pels & Obser Expires 11 February 2027 [Page 2]
Internet-Draft AXFR NOTIFY August 2026
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.
3. Protocol details
The below sections describe the implementation of forced AXFR zone
transfer support on primary and secondary servers.
Although the QTYPE used is AXFR, implementations SHOULD transfer the
zone over whatever protocol they have been configured to use, which
includes both AXFR over DNS/TCP and AXFR over TLS[RFC9103]. Note
that IXFR transfers, which requires serial number alignment, MUST NOT
be used.
3.1. Primary server behaviour
3.1.1. Initiation
When a primary server wants its secondary servers to perform an AXFR
zone transfer, it sends a NOTIFY message with the following
characteristics to each secondary server:
query ID: (new)
op: NOTIFY (4)
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_AXFR
The server SHOULD locally store the current number of seconds since
the Unix Epoch[IEEE_1003.1_2024] at the moment the NOTIFY was
generated. This value is from here on referred to as the
ZONETIMESTAMP.
3.1.2. AXFR query processing
When a primary server receives an AXFR request with an empty
ZONEVERSION option in the EDNS(0) OPT pseudo-RR of the query and a
stored ZONETIMESTAMP is available, it MUST include this value in a
ZONEVERSION option in the response (see Section 4).
Pels & Obser Expires 11 February 2027 [Page 3]
Internet-Draft AXFR NOTIFY August 2026
This updates section 2.2 of [RFC5936].
3.2. Secondary server behaviour
When a secondary server receives a NOTIFY(AXFR) request from one of
its locally designated primaries for the zone enclosing the given
QNAME, with QTYPE=AXFR and QR=0, it SHOULD perform an AXFR zone
transfer from one of its configured primary servers. The AXFR query
SHOULD contain an empty ZONEVERSION option in the EDNS(0) OPT pseudo-
RR.
The secondary server will also send a NOTIFY response back to the
NOTIFY request's source, with the following characteristics:
query ID: (same)
op: NOTIFY (4)
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_AXFR
If the AXFR response from the primary server includes a ZONEVERSION
option of type ZONETIMESTAMP, the following procedure MUST be
followed.
* If no locally stored ZONETIMESTAMP value is available or if the
received ZONETIMESTAMP value is higher than the local value:
1. Process the AXFR response
2. Replace the locally stored ZONETIMESTAMP value with the
ZONETIMESTAMP value from the AXFR response
3. If the secondary server, for the zone enclosing the given
QNAME, is configured as a primary server for other secondary
servers, send a NOTIFY(AXFR) request to each of its configured
secondaries
* If the received ZONETIMESTAMP value is lower than or equal to the
local value:
1. Do not process the AXFR response
2. If any other primary servers are available that have not yet
been tried, attempt an AXFR zone transfer from the next
primary
Pels & Obser Expires 11 February 2027 [Page 4]
Internet-Draft AXFR NOTIFY August 2026
If no ZONETIMESTAMP is included in the AXFR response, the response is
processed but no configured secondaries are notified.
The above procedure ensures that an entire chain of secondary servers
is synchronized in concert, while preventing a loop of AXFR queries.
Secondary servers MAY optimize this procedure by sending a SOA query
with an empty ZONEVERSION option to a primary server and comparing
the returned ZONETIMESTAMP value with their locally stored value,
before attempting a full AXFR.
4. The ZONETIMESTAMP ZONEVERSION Type
This document defines a new ZONEVERSION option TYPE with the
following characteristics.
* The value for this type is "<TBD>"
* The mnemonic for this type is "ZONETIMESTAMP"
* The EDNS(0) OPTION-LENGTH for this type MUST be set to "8" in
responses
* The VERSION value for the ZONETIMESTAMP type MUST be a 64-bit
unsigned integer, representing a number of seconds since the Unix
Epoch[IEEE_1003.1_2024]
5. IANA considerations
This document registers the following entry in the "ZONEVERSION TYPE
Values Registry", following the format defined in [RFC9660]:
+==================+===============+===========+
| ZONEVERSION TYPE | Mnemonic | Reference |
+==================+===============+===========+
| <TBD> | ZONETIMESTAMP | RFCYYYY |
+------------------+---------------+-----------+
Table 1
6. Security considerations
A NOTIFY(AXFR) request with a forged IP/UDP source address can cause
a secondary to send spurious AXFR requests to its primary servers,
leading to a denial of service attack if the forged requests are sent
very often. To counter this, NOTIFY(AXFR) requests MUST be secured
using TSIG[RFC8945].
Pels & Obser Expires 11 February 2027 [Page 5]
Internet-Draft AXFR NOTIFY August 2026
If a primary server has many secondaries, requesting all of them to
perform an AXFR simultaneously may cause the primary to become
overloaded. The sending out of NOTIFY(AXFR) requests to secondary
servers SHOULD be splayed to reduce this thundering herd effect.
Secondary servers SHOULD rate-limit how often they will request an
AXFR from their primaries.
7. Normative References
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[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/info/rfc1996>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[RFC9660] Salgado, H., Vergara, M., and D. Wessels, "The DNS Zone
Version (ZONEVERSION) Option", RFC 9660,
DOI 10.17487/RFC9660, October 2024,
<https://www.rfc-editor.org/info/rfc9660>.
8. Informative References
[IEEE_1003.1_2024]
IEEE, "IEEE/Open Group Standard for Information
Technology--Portable Operating System Interface (POSIX™)
Base Specifications, Issue 8", IEEE 1003-1-2024,
DOI 10.1109/IEEESTD.2024.10555529, 12 June 2024,
<https://ieeexplore.ieee.org/document/10555529>.
[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/info/rfc2119>.
Pels & Obser Expires 11 February 2027 [Page 6]
Internet-Draft AXFR NOTIFY August 2026
[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/info/rfc8174>.
[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer over TLS", RFC 9103,
DOI 10.17487/RFC9103, August 2021,
<https://www.rfc-editor.org/info/rfc9103>.
Appendix A. Acknowledgements
The authors would like to thank the following people for contributing
ideas and feedback to this document:
* Anand Buddhdev
* Peter van Dijk
* Philip Homburg
* Shane Kerr
* Stefan Ubbink
* Wes Hardaker
Authors' Addresses
Martin Pels
RIPE NCC
Netherlands
Email: mpels@ripe.net
Florian Obser
RIPE NCC
Netherlands
Email: fobser@ripe.net
Pels & Obser Expires 11 February 2027 [Page 7]