RFC 5936
DNS Zone Transfer Protocol (AXFR)
RFC 5936: DNS Zone Transfer Protocol (AXFR) 🦋
okay bestie, this is RFC 5936 💖 It's called "DNS Zone Transfer Protocol (AXFR)" and it's from the IETF (Internet Engineering Task Force). It's a Standards Track document, ISSN 2070-1721, published June 2010. The authors are E. Lewis from NeuStar, Inc. and A. Hoenes, Ed. from TR-Sys 🫶 It updates RFC 1034 and RFC 1035 ✨ and the header doesn't list anything it obsoletes, so nothing gets replaced, just upgraded.
Abstract 🌸
so DNS keeps its zone's authoritative name servers in sync with three mechanisms 🔄 Authoritative Transfer (AXFR) is one of them, and it's defined in RFC 1034 and RFC 1035.
the problem is the AXFR definition isn't detailed enough 😭 so implementers had to guess at stuff, and that messed up interoperability. BUT the good news is that we now have a set of implementations that actually work together 🎉 This document is a new definition of AXFR, new in the sense that it writes down an accurate definition of an interoperable AXFR mechanism 💅
Status of This Memo 🧾
this is an Internet Standards Track document ✨
it's a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5936 🦋
Copyright Notice 💜
Copyright (c) 2010 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, which you can find at http://trustee.ietf.org/license-info as they stood on the date this was published. Please actually read those, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💀
heads up: this document might have material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright on some of that stuff may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
Table of Contents 📖
1. Introduction ....................................................4
1.1. Definition of Terms ........................................4
1.2. Scope ......................................................5
1.3. Context ....................................................5
1.4. Coverage and Relationship to Original AXFR Specification ...5
2. AXFR Messages ...................................................6
2.1. AXFR Query .................................................8
2.1.1. Header Values .......................................8
2.1.2. Question Section ...................................10
2.1.3. Answer Section .....................................10
2.1.4. Authority Section ..................................10
2.1.5. Additional Section .................................10
2.2. AXFR Response .............................................11
2.2.1. Header Values ......................................12
2.2.2. Question Section ...................................14
2.2.3. Answer Section .....................................14
2.2.4. Authority Section ..................................14
2.2.5. Additional Section .................................14
2.3. TCP Connection Aborts .....................................15
3. Zone Contents ..................................................15
3.1. Records to Include ........................................15
3.2. Delegation Records ........................................16
3.3. Glue Records ..............................................18
3.4. Name Compression ..........................................19
3.5. Occluded Names ............................................19
4. Transport ......................................................20
4.1. TCP .......................................................20
4.1.1. AXFR Client TCP ....................................21
4.1.2. AXFR Server TCP ....................................22
4.2. UDP .......................................................22
5. Authorization ..................................................22
6. Zone Integrity .................................................23
7. Backwards Compatibility ........................................24
7.1. Server ....................................................24
7.2. Client ....................................................25
8. Security Considerations ........................................25
9. IANA Considerations ............................................25
10. Internationalization Considerations ...........................25
11. Acknowledgments ...............................................25
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................281. Introduction ✨
okay so DNS has three standard tools for keeping the servers for a zone coherent 🧚 Authoritative Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities" [RFC1034] (we'll call that RFC 1034 in this doc) and "Domain Names - Implementation and Specification" [RFC1035] (henceforth RFC 1035) 📜 Incremental Zone Transfer (IXFR) is defined in "Incremental Zone Transfer in DNS" [RFC1995] 🔁 and the prompt zone change heads-up, NOTIFY, is defined in "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996] 🔔 The whole point of all three is to help a set of DNS name servers stay coherently authoritative for a given zone 💜
this document re-specifies AXFR the way it's actually deployed across the Internet at large, hopefully with the precision you'd expect from modern Internet Standards 🎀 so it updates RFC 1034 and RFC 1035 💅
1.1. Definition of Terms 📝
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [BCP14] 🌸
"newer" / "new" and "older" / "old" DNS just means implementations written after and before this document got published 🕰️
"General-purpose DNS implementation" means DNS software built for widespread use 🌍 That includes resolvers and servers that are freely available as libraries and standalone processes. It also includes proprietary implementations that are only used to support DNS service offerings 💼
"Turnkey DNS implementation" means custom-made, single-use DNS implementations 🎀 These are software that uses the DNS protocol message format but doesn't cover the whole range of DNS functionality 🙃
the terms "AXFR session", "AXFR server", and "AXFR client" get introduced in the first paragraph of Section 2, once there's some more context 🦋
1.2. Scope 🔭
so, in general, authoritative name servers for a zone can use different ways to keep the zone contents they serve coherent 🔄 For example, some DNS implementations build their answers from data in relational databases (instead of master files) and rely on the database's non-DNS methods to keep the database instances in sync 🗄️ Some of those non-DNS solutions do interoperate in some way 🤝 But AXFR, IXFR, and NOTIFY are the only protocol-defined in-band mechanisms for keeping a set of name servers coherent, and they're the only mechanisms the IETF has specified 👑
this document does not cover incoherent DNS situations 🙅♀️ Some DNS applications are deliberately designed so their servers for a zone are incoherent. For those setups, a coherency mechanism like the one described here would be unsuitable 😬
a DNS implementation is not required to support AXFR, IXFR, and NOTIFY, but it should have some means of maintaining name server coherency 💖 A general-purpose DNS implementation will likely support AXFR (and, in the same vein, IXFR and NOTIFY), but turnkey DNS implementations may exist without AXFR 🧃
1.3. Context 🌈
it's not just about the mechanisms themselves, you also have to think about the context they operate in 🧐 In the initial specs for AXFR (and IXFR and NOTIFY), security and privacy got very little thought 😭 Since the original AXFR definition, new opinions have popped up about who should have access to an entire zone's contents 🔐 So in this document, the basic mechanisms get discussed separately from the permission to use them ✨
1.4. Coverage and Relationship to Original AXFR Specification 📚
this document is all about the definition of AXFR, nothing else 🎯 Any effort to update the specs for IXFR or NOTIFY is left to different documents 💅
the original "specification" for the AXFR sub-protocol is scattered across RFC 1034 and RFC 1035 🗺️ Section 2.2 of RFC 1035 (on page 5) shows the scenario AXFR was designed for 🎬 Section 4.3.5 of RFC 1034 covers zone synchronization strategies in general and the rules for invoking a full zone transfer via AXFR, and its fifth paragraph has a very short sketch of the AXFR protocol 🥺 Section 5.5 of RFC 2181 fixed a significant flaw in that spec 🔧 Section 3.2.3 of RFC 1035 assigned the code point for the AXFR QTYPE (see Section 2.1.2 below for more details) 🔢 Section 4.2 of RFC 1035 talks about how DNS uses the transport layer and briefly explains why UDP transport is considered inappropriate for AXFR 🚫 The last paragraph of Section 4.2.2 gives details on TCP connection management for AXFR 🔌 And finally, the second paragraph of Section 6.3 in RFC 1035 mandates server behavior when zone data changes happen during an ongoing AXFR zone transfer ⚠️
this document will update the AXFR spec, and it fully specifies the record formats and processing rules for AXFR 🧩 It mostly expands on paragraph 5 of Section 4.3.5 of RFC 1034, and it details the transport considerations for AXFR, which amends Section 4.2.2 of RFC 1035 🚚 It also discusses backward-compatibility issues, gives policy and management considerations, and covers the specific security considerations for AXFR 🛡️ The goal is to define AXFR the way the DNS community understands it to exist today 🦋✨
2. AXFR Messages ✨
okay so this is where the actual AXFR stuff starts 🦋 an AXFR session is just an AXFR query message plus the whole stack of AXFR response messages that come back for it. in this doc the AXFR client is the one sending the query and the AXFR server is the one responding. (master, slave, primary, and secondary don't really matter for defining AXFR, so no drama there 💅) when we just say "session" with no extra words, we mean an AXFR session. 🌸
big thing to keep in mind: AXFR is restricted to TCP [RFC0793] (more on that in Section 4 🎀). the whole AXFR process has design features that just don't port nicely to UDP [RFC0768], so that's not a vibe we're chasing. 🙈
the basic format of an AXFR message is the DNS message from Section 4 ("MESSAGES") of RFC 1035 [RFC1035], but it's been updated by a bunch of other docs too 📚
- The "Basic" DNS specification:
- "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- "Clarifications to the DNS Specification" [RFC2181]
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers" [RFC4635]
- "Domain Name System (DNS) IANA Considerations" [RFC5395]
- Further additions related to the DNS Security Extensions (DNSSEC), defined in these base documents:
- "DNS Security Introduction and Requirements" [RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)" [RFC4509]
- "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155]
- "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC" [RFC5702]
- "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
these docs are all about the syntax and semantics of DNS messages. they don't get in AXFR's way, and they're super helpful for figuring out what's actually going to be carried over AXFR 🧚
here's the synopsis of the DNS message header from [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]), reproduced informally so you can vibe-check the layout ✨
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+this doc uses the field names exactly as they show up in that diagram 🎀 and the sections in the body of DNS messages get capitalized here for clarity, like "Additional section" 💜
the DNS message size limit from [RFC1035] for DNS over UDP (plus its EDNS0 extension from [RFC2671]) is not relevant for AXFR, as Section 4 explains 🙅♀️ the upper limit over TCP is only set by the TCP framing from Section 4.2.2 of RFC 1035. that's a two-octet message length field, read as unsigned, so you get a cap of 65535 octets. EDNS0 doesn't change this limit at all 🔥
also, the TC (truncation) bit is never set by an AXFR server, and an AXFR client doesn't consider or read it 🫶
2.1. AXFR Query
a client sends an AXFR query whenever it has a reason to ask 💖 that could be scheduled or triggered zone maintenance (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], respectively), or just a command line request, like for debugging 🍓
2.1.1. Header Values
these are the DNS message header values for an AXFR query, so take notes bestie 📝
ID Selected by client; see Note a)
QR MUST be 0 (Query)
OPCODE MUST be 0 (Standard Query)
Flags:
AA "n/a" -- see Note b)
TC "n/a" -- see Note b)
RD "n/a" -- see Note b)
RA "n/a" -- see Note b)
Z "mbz" -- see Note c)
AD "n/a" -- see Note b)
CD "n/a" -- see Note b)
RCODE MUST be 0 (No error)
QDCOUNT Number of entries in Question section; MUST be 1
ANCOUNT Number of entries in Answer section; MUST be 0
NSCOUNT Number of entries in Authority section; MUST be 0
ARCOUNT Number of entries in Additional section -- see Note d)Notes:
a) the ID can be set to any value the client isn't already using with the same server 🌈 there's no specific way to pick it. (and remember, AXFR only happens over TCP connections, see Section 4, "Transport" 💅)
A server MUST reply using messages that use the same message ID, so a client can have multiple queries outstanding at once over the same TCP connection. see Note a) in Section 2.2.1 for more details ✨
b) "n/a" means the value in this field has no meaning for AXFR query messages 🙃 for the client, it is RECOMMENDED that the value be zero. the server MUST ignore this value.
c) "mbz" means the client MUST set this bit to 0, and the server MUST ignore it 🧚♀️
d) the client MUST set this field to the number of resource records it places into the Additional section. unless there's an explicit spec for new RRs carried in the Additional section of AXFR queries, the value MAY be 0, 1, or 2. see Section 2.1.5, "Additional Section", for the RRs that currently apply 🦋
2.1.2. Question Section
the Question section of the AXFR query MUST conform to Section 4.1.2 of RFC 1035, and it has to contain a single resource record with these values 🎀
QNAME the name of the zone requested
QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
[DNSVALS]
QCLASS the class of the zone requested [DNSVALS]2.1.3. Answer Section
the Answer section MUST be empty. no vibes, no records 🫧
2.1.4. Authority Section
the Authority section MUST be empty too 🌸
2.1.5. Additional Section
right now, two kinds of resource records can show up in the Additional section of AXFR queries and responses: EDNS and DNS transaction security 🔐 future specs that define RRs for normal DNS transactions will need to explicitly describe how they work with AXFR, if anyone wants that 💜
the client MAY include one OPT resource record [RFC2671]. if the server doesn't support EDNS0, the client MUST send this section without an OPT resource record when it retries. the catch is that the protocol doesn't define an explicit way for a server to say "I don't support EDNS0" 🙈 the client has to infer it. usually the server will send back a FormErr(1) that might be related to the OPT resource record. also, at the time of writing, only the EXTENDED-RCODE field of the OPT RR is meaningful for AXFR. future specs for EDNS flags and/or EDNS options must describe their usage in the context of AXFR, if it applies 🍓
the client MAY include one transaction integrity and authentication resource record, which is currently a choice of TSIG [RFC2845] or SIG(0) [RFC2931]. if the server says it doesn't recognize the resource record, and the error really is caused by that record, the client probably should not try again. taking the security data off when you hit an obstacle should only happen with full awareness of what that means 🚨
heads up: dropping security records to get past an error is a big decision. only do it if you really understand the implications 💀
in general, if an AXFR client knows an AXFR server doesn't support a particular mechanism, the client SHOULD NOT try to engage the server using that mechanism (or engage the server at all) 🙅♀️ a client could find out about a server's abilities through a configuration setting or some other (as yet) undefined means 🧚
the range of permissible resource records that MAY appear in the Additional section might change over time 🌈 if an existing record gets changed (like the OPT RR for EDNS) or a new Additional section record gets created, the new definitions ought to discuss how they apply to AXFR and what impact they have on it. future records in the Additional section might have an effect that's orthogonal to AXFR, so they can just ride through the session as opaque data 🦋 in that case, a "wise" implementation ought to be able to pass those records through without disruption 👑
2.2. AXFR Response ✨
okay so an AXFR response is gonna be one or more messages 💅 The weird case where the server just closes the TCP connection without sending any response is covered in Section 2.3 🙈
When the response is actually transferring the zone's contents, it's a series of DNS messages (a series can be length 1, no cap). The first message MUST begin with the SOA resource record of the zone, and the last message MUST conclude with that same SOA resource record. Intermediate messages MUST NOT contain the SOA resource record. The AXFR server MUST copy the Question section from the matching AXFR query message into the first response message's Question section. For the subsequent messages, it MAY do the same or leave the Question section empty. 🫶
The AXFR protocol treats the zone contents as an unordered collection (the mathy term is a "set") of RRs 🌸 Except for the rule that the transfer has to begin and end with the SOA RR, there's no requirement to send the RRs in any particular order or to group them into response messages in any particular way. Servers usually do try to send related RRs together (like the RRs forming an RRset, and the RRsets of a name) as a contiguous group or, when there's message space, in the same response message. But they are not required to do that, and clients MUST accept any ordering and grouping of the non-SOA RRs. Each RR SHOULD be transmitted only once, and AXFR clients MUST ignore any duplicate RRs they receive. 🔥
Each AXFR response message SHOULD contain enough RRs to reasonably amortize the per-message overhead, up to the largest number that will fit within a DNS message. That's taking the required content of the other sections into account, as described below. ✨
Some old AXFR clients expect each response message to contain only a single RR 💀 To interoperate with those clients, the server MAY restrict response messages to a single RR. There's no standard way to automatically detect such clients, so this typically requires manual configuration at the server. 🧚
To indicate an error in an AXFR response, the AXFR server sends a single DNS message when it detects the error condition, with the response code set to the appropriate value for that condition. That message terminates the AXFR session. It MUST contain a copy of the Question section from the AXFR query in its Question section, but including the terminating SOA resource record is not necessary. 😭
An AXFR server may send a number of AXFR response messages free of an error condition before it sends the message indicating an error. 🎀
2.2.1. Header Values
these are the DNS message header values for AXFR responses 💖
ID MUST be copied from request -- see Note a)
QR MUST be 1 (Response)
OPCODE MUST be 0 (Standard Query)
Flags:
AA normally 1 -- see Note b)
TC MUST be 0 (Not truncated)
RD RECOMMENDED: copy request's value; MAY be set to 0
RA SHOULD be 0 -- see Note c)
Z "mbz" -- see Note d)
AD "mbz" -- see Note d)
CD "mbz" -- see Note d)
RCODE See Note e)
QDCOUNT MUST be 1 in the first message;
MUST be 0 or 1 in all following messages;
MUST be 1 if RCODE indicates an error
ANCOUNT See Note f)
NSCOUNT MUST be 0
ARCOUNT See Note g)Notes, bestie 📝
a) Because some old implementations behave differently than is now desired, the requirement on this field is spelled out in detail. New DNS servers MUST set this field to the value of the AXFR query ID in each AXFR response message for the session. AXFR clients MUST be able to manage sessions resulting from multiple outstanding queries, whether those are AXFR queries or other DNS queries. A client SHOULD discard responses that don't correspond (via the message ID) to any outstanding queries. 🦋
Unless the client is sure the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to issue any other queries until the end of the zone transfer. A client MAY become aware of a server's abilities via a configuration setting. 👑
b) If the RCODE is 0 (no error), then the AA bit MUST be 1. For any other RCODE value, the AA bit MUST be set according to the rules for that error code. If in doubt, it is RECOMMENDED that it be set to 1. It is RECOMMENDED that the value be ignored by the AXFR client. 🌈
c) It is RECOMMENDED that the server set the value to 0, and the client MUST ignore this value. 🍓
The server MAY set this value according to local policy about recursive service, but doing so might confuse the interpretation of the response, since AXFR cannot be retrieved recursively. A client MAY note the server's policy on recursive service from this value, but SHOULD NOT conclude that the AXFR response was obtained recursively, even if the RD bit was 1 in the query. 🙈
d) "mbz" -- The server MUST set this bit to 0, and the client MUST ignore it. 💜
e) In the absence of an error, the server MUST set the value of this field to NoError(0). If a server is not authoritative for the queried zone, the server SHOULD set the value to NotAuth(9). (Reminder: consult the appropriate IANA registry [DNSVALS].) If a client receives any other value in response, it MUST act according to that error. For example, a malformed AXFR query or the presence of an OPT resource record sent to an old server will result in a FormErr(1) value. This value is not set as part of the AXFR-specific response processing. The same is true for other values indicating an error. 💅
f) The count of answer records MUST equal the number of resource records in the AXFR Answer section. When a server is aware that a client will only accept response messages with a single resource record, then the value MUST be 1. A server MAY be made aware of a client's limitations via configuration data. 🧁
g) The server MUST set this field to the number of resource records it places into the Additional section. In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR response messages, the value MAY be 0, 1, or 2. See Section 2.1.5 above for details on the currently applicable RRs, and Section 2.2.5 for additional considerations specific to AXFR servers. ✨
2.2.2. Question Section
in the first response message, this section MUST be copied from the query. In subsequent messages, this section MAY be copied from the query, or it MAY be empty. However, in an error response message (see Section 2.2), this section MUST be copied as well. The content of this section MAY be used to determine the context of the message, that is, the name of the zone being transferred. 🎀
2.2.3. Answer Section
the Answer section MUST be populated with the zone contents. See Section 3 below on encoding zone contents. 🍓
2.2.4. Authority Section
the Authority section MUST be empty. 🫧
2.2.5. Additional Section
the contents of this section MUST follow the guidelines for the OPT, TSIG, and SIG(0) RRs, or whatever other future record is possible here. The contents of Section 2.1.5 apply analogously as well. 🧚
The following considerations specifically apply to AXFR responses 👑
If the client has supplied an EDNS OPT RR in the AXFR query, and the server supports EDNS as well, it SHOULD include one OPT RR in the first response message and MAY do so in subsequent response messages (see Section 2.2). The specifications of EDNS options to be carried in the OPT RR may impose stronger requirements. 💖
If the client has supplied a transaction security resource record (currently a choice of TSIG and SIG(0)) and the server supports the method chosen by the client, it MUST place the corresponding resource record into the AXFR response message(s), according to the rules specified for that method. 🔥
2.3. TCP Connection Aborts 💔
If an AXFR client sends a query on a TCP connection and the connection is closed at any point, the AXFR client MUST consider the AXFR session terminated. The message ID MAY be used again on a new connection, even if the question and AXFR server are the same. 🦋
Facing a dropped connection, a client SHOULD try to make some determination as to whether the closure was the result of network activity or a decision by the AXFR server. This determination is not an exact science 🙈 It's up to the AXFR client to react, but the reaction it implements SHOULD NOT be either an endless cycle of retries or an increasing (in frequency) retry rate. 😭
An AXFR server implementer should take into consideration the dilemma described above when a connection is closed with an outstanding query in the pipeline. For this reason, a server ought to reserve this course of action for situations in which it believes beyond a doubt that the AXFR client is attempting abusive behavior. 🚨
3. Zone Contents 🌈
The objective of the AXFR session is to request and transfer the contents of a zone, so the AXFR client can faithfully rebuild the zone as it exists at the primary server for the given zone serial number 🧚 Here "exists" means the externally visible behavior, meaning the zone content that's actually being served (handed out to clients). It does NOT mean the persistent representation in a zone file or database the server uses. For consistency, the AXFR client should then serve that content in an identical manner. ✨
Over time, the definition of a zone has evolved. It started as a static set of records, then grew to cover a dynamically updated set, and then a potentially continually regenerated set as well. That last kind includes RRs synthesized "on the fly" from rule sets or database lookup results in other forms than RR format 🍓
3.1. Records to Include 📚
In the Answer section of AXFR response messages, the resource records within a zone for the given serial number MUST appear. The definition of what belongs in a zone is described in RFC 1034, Section 4.2, "How the database is divided into zones" (in particular Section 4.2.1, "Technical considerations"), and it has been clarified in Section 6 of RFC 2181. 💜
Zones for which it is impractical to list the entire zone for a serial number are not suitable for AXFR retrieval. A typical (but not limiting) description of such a zone is one made of responses generated via other database lookups and/or computed from ever-changing data. 🙈
3.2. Delegation Records 💅
okay so RFC 1034 Section 4.2.1 has this line 👀 (ngl the "should" in it is older than [BCP14], so see Section 1.1 🙈):
The RRs that describe cuts ... should be exactly the same as the corresponding RRs in the top node of the subzone.
this line has caused some drama 💀 about which NS resource records get included in a zone transfer. so let's sort it out 🎀
"that describe cuts" points at the NS set and the applicable glue records. it does NOT mean the cut point and the apex have identical records ✨ the SOA resource record, for example, only lives at the apex. this section only talks about the NS resource record set and glue, since those are the ones that "describe cuts" 🦋
DNSSEC records have their own special rules for where they show up at a zone cut and at the apex of a zone 🔐 this was first described in Sections 5.3 ff. and 6.2 of RFC 2181 (the initial DNSSEC spec), and some parts of RFC 2181 are now historical 📜 the current DNSSEC core document set (see second bullet in Section 2 above) has the full details for DNSSEC(bis) record placement, and Section 3.1.5 of RFC 4035 normatively specifies how they get treated during AXFR 💖 the alternate NSEC3 resource record defined later in RFC 5155 behaves exactly like the NSEC RR for AXFR purposes, so it's the same vibe ✨
informally, here's the tea ☕
- The DS RRSet only occurs at the parental side of a zone cut and is authoritative data in the parent zone, not the secure child zone.
- The DNSKEY RRSet only occurs at the apex of a signed zone and is part of the authoritative data of the zone it serves.
- Independent RRSIG RRSets occur at the signed parent side of a zone cut and at the apex of a signed zone; they are authoritative data in the respective zone; simple queries for RRSIG resource records may return both RRSets at once if the same server is authoritative for the parent zone and the child zone (Section 3.1.5 of RFC 4035 describes how to distinguish these RRs); this seeming ambiguity does not occur for AXFR, since each such RRSIG RRset belongs to a single zone.
- Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records equally may occur at the parental side of a zone cut and at the apex of a zone; each such resource record belongs to exactly one of these zones and is to be included in the AXFR of that zone.
here's the messy part 🙃 sometimes the NS resource records for a zone are different at a cut point in the parent and at the apex of the zone. sometimes that's an error, and sometimes it's part of an ongoing change in name servers 🔄 the DNS is robust enough to handle inconsistencies, all the way up to (but not including) the point where no parent-indicated NS resource record references a server that can serve the child zone 💪 this robustness is a big part of why the DNS has been so successful 👑 still, an inconsistency is an error state, so steps need to be taken to make it visible if it was unplanned 🚨
another wrinkle: the AXFR server could be authoritative for a different set of zones than the AXFR client 🤯 it's possible that the AXFR server is authoritative for both halves of an inconsistent cut point, while the AXFR client is only authoritative for the parent side of that cut point.
so when a cut point's NS resource records don't match the authoritative set, the big question is whether an AXFR server responds with the NS resource record set that's in the zone being transferred, or the one at the authoritative location 🤔
The AXFR response MUST contain the cut point NS resource record set registered with the zone whether it agrees with the authoritative set or not.
"registered with" can be read pretty widely 🌸 it can cover data in the zone file for that particular serial number (in zone file environments), or any data configured to be in the zone (database), whether it's static or dynamic.
the reasons for this are:
- The AXFR server might not be able to determine that there is an inconsistency given local data; hence, requiring consistency would mean a lot more needed work and even network retrieval of data. An authoritative server ought not be required to perform any queries. 😩
- By transferring the inconsistent NS resource records from a server that is authoritative for both the cut point and the apex to a client that is not authoritative for both, the error is exposed. For example, an authorized administrator can manually request the AXFR and inspect the results to see the inconsistent records. (A server authoritative for both halves would otherwise always answer from the more authoritative set, concealing the error.) 🕵️♀️
- The inconsistent NS resource record set might indicate a problem in a registration database. 🗂️
- This requirement is necessary to ensure that retrieving a given (zone, serial) pair by AXFR yields the exact same set of resource records, no matter which of the zone's authoritative servers is chosen as the source of the transfer. 🫶
if an AXFR server were allowed to respond with the authoritative NS RRset of a child zone instead of a parent-side NS RRset in the zone being transferred, the set of records returned could change depending on whether or not the server happened to be authoritative for the child zone as well 🙈 not it 🙅♀️
a given (zone, serial) pair needs to correspond to a single, well-defined set of records, and that's necessary for incremental transfer protocols like IXFR [RFC1995] to work properly 🦋 for example, a client might retrieve a zone by AXFR from one server, then apply an incremental change obtained by IXFR from a different server. if the two servers have different ideas about the zone contents, the client can end up trying to add records that already exist or delete records that don't exist 💀
3.3. Glue Records 🧚
as quoted in the previous section, Section 4.2.1 of RFC 1034 gives guidance and reasoning for including glue records as part of an AXFR response ✨ and, as argued in the previous section of this document too, even if there's an inconsistency between the address in a glue record and the authoritative copy of the name server's address, the glue resource record that is registered as part of the zone for that serial number is the one to include 💜
this applies to glue records for any address family [IANA-AF] 🌈
The AXFR response MUST contain the appropriate glue records as registered with the zone. The interpretation of "registered with" in the previous section applies here. Inconsistent glue records are an operational matter. 🛠️
3.4. Name Compression 🎀
compression of names in DNS messages is described in RFC 1035, Section 4.1.4, "Message compression" 📦 the thing we're highlighting here is a comment in RFC 1034, Section 3.1, "Name space specifications and terminology", which says:
When you receive a domain name or label, you should preserve its case.
("should" in the quote predates [BCP14].) 🙈
okay so here's why this one's spicy 🌶️ the main goal of AXFR is for the client to serve the same zone content as the server. normal DNS responses are expected to preserve the case from the query, but a zone transfer has to keep the case of the labels in the zone content 💖 so name compression in an AXFR message SHOULD be done in a case-preserving manner, which is NOT how it's done for "normal" DNS responses ✨ yes, when you're comparing a domain name for matching, "a" equals "A". but when you're comparing for message compression in AXFR, "a" is NOT equal to "A" 🤯 this isn't the usual definition of name comparison in the DNS protocol, and it's a new understanding of the requirement on AXFR servers, so bestie, take note 📝
Rules governing name compression of RDATA in an AXFR message MUST abide by the specification in "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name Compression". 🌈
3.5. Occluded Names 🙈
Dynamic Update [RFC2136] operations, and especially how they interact with DNAME [RFC2672], can have a side effect of occluding names in a zone 🫥 adding a delegation point via dynamic update renders all subordinate domain names in a kind of limbo: they're still part of the zone, but the lookup process can't reach them. adding a DNAME resource record has the same impact. those subordinate names are called "occluded" 👻
Occluded names MUST be included in AXFR responses. An AXFR client MUST be able to identify and handle occluded names. the reason is so that recovery is speedy if the dynamic update operation was a mistake and needs to be undone 🔙💅
4. Transport 🚚
AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC 1034, which says:
Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests.
the TCP restriction is also mentioned in Section 6.1.3.2 of "Requirements for Internet Hosts - Application and Support" [RFC1123] 📚
the most common scenario is an AXFR client opening a TCP connection to the AXFR server, sending an AXFR query, receiving the AXFR response, and then closing the connection 🔌 but variations of that simple scenario are legit and pretty likely, like sending a query for the zone's SOA resource record first over the same TCP connection, or reusing an existing TCP connection for other queries ✨
so the assumption that a TCP connection is dedicated to a single AXFR session is incorrect 🙅♀️ that wrong assumption has led to implementation choices that block either multiple concurrent zone transfers or using an open connection for other queries 😤
since the early days of the DNS, operators with sets of name servers authoritative for a common set of zones have wanted multiple concurrent zone transfers in progress 🏃♀️💨 that way, a name server doesn't have to wait for one zone transfer to finish before the next can start. RFC 1035 didn't rule this out, but legacy implementations didn't support it efficiently over a single TCP connection 🐢 since those legacy implementations are still around, new general-purpose client implementations still need options for graceful fallback to the old behavior when they support concurrent DNS transactions and AXFR sessions on a single TCP connection 🫶
4.1. TCP ✨
okay so the original spec kinda ASSUMED (probably by accident) that one TCP connection gets used for exactly one AXFR session 🙈 you can tell because it never explicitly says to copy the Question section or message ID into responses, there's no ordering info across AXFR response messages, and there's no flag saying "hey, the zone transfer keeps going in the next message." bestie that's a LOT of vibes-based design 💀
this section is all about making AXFR run smoother, like letting DNS message exchanges (zone transfer sessions included) get multiplexed 🧚 and giving some guidance for playing nice with older software 🫶. the older-software guidance is generally useful for new AXFR clients too. and if it's an older AXFR client talking to a newer server? the server ought to act within the spec for an older server 💅
4.1.1. AXFR Client TCP
An AXFR client MAY request a connection to an AXFR server for any reason. ✨ It SHOULD close the connection when there's no apparent need to keep it open for some time. The AXFR server ought not have to keep idle connections around 🙅, so closing up is on the client. What counts as "apparent need" is a judgment call for the AXFR client and the DNS client. if the connection is used for multiple sessions, or sessions are coming, or other query/response traffic is expected or already on the open connection, then yep, there's "apparent need" 💜
An AXFR client can cancel delivery of a zone only by closing the connection 😬 but that also cancels all the other outstanding activity on it. there's no other way to cancel an AXFR response, period.
When a TCP connection gets closed remotely (from the client's point of view), whether by the AXFR server or because of a network event, the AXFR client MUST cancel all outstanding sessions and non-AXFR transactions. 😭 recovery is not straightforward. if it was a spurious blip, retrying the connection is proper. if it was a failure that turned out to be persistent, the client is wise not to burn too many resources rebuilding. and if the connection got dropped because of a policy at the AXFR server (which can happen with older AXFR servers), the client is wise not to retry at all. unfortunately you can't know for certain which of those three (momentary disruption, failure, policy) it was. you can only guess with heuristics 🔮 this is the general mess for clients in connection-oriented protocols that don't get meaningful error responses.
An AXFR client MAY use an already opened TCP connection to start an AXFR session. Using an existing open connection is RECOMMENDED over opening a new one. (non-AXFR session traffic can share an open connection too 🦋) If the client realizes the responses can't be properly told apart (like mismatched query IDs), or the connection got terminated for a remote reason, the AXFR client SHOULD NOT attempt to reuse an open connection with that specific AXFR server until the server is updated (which, obvs, isn't an event the DNS protocol can capture 🙃).
4.1.2. AXFR Server TCP
An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, plus other query/response transactions over it too 👑
If a TCP connection is closed remotely, the AXFR server MUST cancel all AXFR sessions in place. no retry activity is needed on its end, because that's initiated by the AXFR client 🙌
Local policy MAY dictate that a TCP connection is to be closed. Such an action SHOULD be a reaction to limits, like the ones placed on the number of outstanding open connections. Closing a connection in response to a suspected security event SHOULD be done only in extreme cases, when the server is certain the action is warranted 🚨 An isolated request for a zone not on the AXFR server SHOULD receive a response with the appropriate response code and not see the connection broken 💅
4.2. UDP 🌈
with EDNS0 in the picture, and apps that need lots of small zones (like web hosting and some ENUM setups), AXFR sessions over UDP now seem kinda desirable 👀 but there are still a bunch of AXFR session aspects that don't translate easily to UDP 😵
so this document does not update RFC 1035 in this respect: AXFR sessions over UDP transport are not defined. 🚫
5. Authorization 🔐
A zone administrator has the option to restrict AXFR access to a zone. this wasn't envisioned in the original DNS design but has emerged as a requirement as DNS has evolved 🌸 Restrictions could be for various reasons, like a desire (or in some cases a legal requirement 😬) to keep the bulk version of the zone concealed, or to stop servers from handling the load AXFR creates. it's been argued these reasons are questionable, but this document, driven by the desire to build on the interoperable practice that's evolved since RFC 1035, acknowledges the factual requirement to provide mechanisms to restrict AXFR 🫶
A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients. ✨
An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address could be spoofed. Combining this with techniques like Virtual Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be effective 💖
A general-purpose implementation is RECOMMENDED to implement access controls based upon "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931]. 🔑
A general-purpose implementation SHOULD allow access to be open to all AXFR requests. that means an operator ought to be able to let any AXFR query be granted 🌍
A general-purpose implementation SHOULD NOT have a default policy for AXFR requests to be "open to all". for example, a default could be restricting transfers to addresses selected by the DNS administrator(s) for zones on the server 🔒
6. Zone Integrity 🛡️
An AXFR client MUST ensure that only a successfully transferred copy of the zone data can be used to serve this zone. previous description and implementation practice came up with a two-stage model of the whole zone synchronization procedure: upon a trigger event (like polling an SOA resource record and detecting a change in the SOA serial number, or receiving a DNS NOTIFY request [RFC1996]), the AXFR session is initiated, and the zone data gets saved in a zone file or database (this step is needed anyway to make sure the server restarts properly). upon successful completion of the AXFR operation and some sanity checks, that data set gets "loaded" and made available for serving the zone in an atomic operation, and flagged "valid" for use during the next restart of the DNS server. if any error is detected, this data set MUST be deleted, and the AXFR client MUST continue to serve the previous version of the zone, if it did before. 🥲 The externally visible behavior of an AXFR client implementation MUST be equivalent to that of this two-stage model. ✨
If an AXFR client rejects data obtained in an AXFR session, it SHOULD remember the serial number and MAY attempt to retrieve the same zone version again. the reason the same retrieval could make sense is that the rejection could be rooted in an implementation detail of one AXFR server used for the zone and not present in another AXFR server used for the zone 🧐
Making sure an AXFR client doesn't accept a forged copy of a zone is super important for zone security 🚨 If a zone operator has the opportunity, protection can come from dedicated links, physical or virtual via a VPN among the authoritative servers. but there are instances where zone operators have no choice but to run AXFR sessions over the global public Internet 🌐
Besides best attempts at securing TCP connections, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the contents. These techniques MAY also be used for authorization. ✅
7. Backwards Compatibility 🧁
Describing backwards compatibility is tricky because of the lack of specifics in the original definition 🌀 this section gives some hints for building in backwards compatibility, mostly repeated from the relevant earlier sections.
Backwards compatibility is not necessary, but the greater the extent of an implementation's compatibility, the greater its interoperability. for turnkey implementations this usually isn't a concern. for general-purpose implementations, it takes on varying levels of importance, depending on how much the implementer wants to maintain interoperability.
It's unfortunate that a need to fall back to older behavior can't be discovered, and so has to be noted in a configuration file 😩 An implementation SHOULD, in its documentation, encourage operators to periodically review the AXFR clients and servers it has made notes about repeatedly, since old software gets updated from time to time 🔄
7.1. Server
An AXFR server has the luxury of reacting to an AXFR client's abilities, with one exception: knowing whether the client can accept multiple resource records per AXFR response message. that can't be discovered, so it has to be set by configuration 🙃
An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, the necessity to revert to a single resource record per message; in that case, the default SHOULD be to use multiple records per message. ✨
7.2. Client
An AXFR client has the opportunity to try other features (i.e., ones not defined by this document) when querying an AXFR server 🧩
Attempting to issue multiple DNS queries over a TCP transport for an AXFR session SHOULD be aborted if it interrupts the original request, and SHOULD take into consideration whether the AXFR server intends to close the connection immediately upon completion of the original (connection-causing) zone transfer. 🫠
8. Security Considerations 🔒
This document is a clarification of a mechanism outlined in RFCs 1034 and 1035, and as such does not add any new security considerations 🙌 RFC 3833 [RFC3833] is devoted entirely to security considerations for the DNS; its Section 4.3 delineates zone transfer security aspects from the security threats addressed by DNSSEC 📚
Concerns regarding authorization, traffic flooding, and message integrity are mentioned in "Authorization" (Section 5), "TCP" (Section 4.1), and "Zone Integrity" (Section 6). go re-read those, bestie 💀
9. IANA Considerations 🎀
IANA has added a reference to this RFC in the AXFR (252) row of the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry. 🧚
10. Internationalization Considerations ✨
okay so the AXFR protocol is basically transparent to the parts of DNS zone content that could get tangled up in internationalization stuff 🌍 It's giving "not my problem, someone else already handled it." The assumption here is that DNS labels and domain names are sorted out by "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] or whatever successor(s) come after it 💅
11. Acknowledgments 🫶
okay bestie, the earlier draft versions were edited by Andreas Gustafsson 🖊️ In his latest draft he gave a shoutout to everyone who helped out, and the list was: Bob Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, and Brian Wellington. 🥰
The people who commented on the later drafts were Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly, Bill Manning, and the other participants of the DNSEXT working group 👑 Big comments from the wider IETF also came from Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani 🌸
And Edward Lewis was the sole document editor for two years, patiently listening to everyone the whole time 🧚 he is literally a saint 😭
12. References 📚
okay so all "RFC" references below, like all RFCs, plus info about the RFC series, can be found on the RFC Editor website at http://www.rfc-editor.org 🦋
12.1. Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message
Authentication Code, Secure Hash Algorithm) TSIG
Algorithm Identifiers", RFC 4635, August 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702, October
2009.12.2. Informative References
[DNSVALS] IANA Registry "Domain Name System (DNS) Parameters",
http://www.iana.org/.
[IANA-AF] IANA Registry "Address Family Numbers",
http://www.iana.org/.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and
Implementation Notes for DNSSECbis", Work in Progress,
March 2010.Authors' Addresses 💌
Edward Lewis
46000 Center Oak Plaza
Sterling, VA 20166
US
EMail: ed.lewis@neustar.biz
Alfred Hoenes, Editor
TR-Sys
Gerlinger Str. 12
Ditzingen D-71254
Germany
EMail: ah@TR-Sys.de📦 where this page comes from
- ietf: rfc5936 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms