2000.07.18: Gustafsson* released a new draft, axfr-clarify-01. There was some discussion on the censored DNSEXT mailing list: 2 messages from DNSEXT censor Randy Bush, 4 from Gustafsson*, 3 from Eric Hall, 2 from Peter Koch, 4 from Josh Littlefield, and 1 from Paul Vixie*.
``The purpose of this draft is not to change the protocol but to document it in its existing form,'' Gustafsson* said.
2001.03.13: Olafur Gudmundsson issued a DNSEXT last call to put axfr-clarify-01 on the standards track. ``The document formalizes the zone transfer protocol in accordance with the fielded DNS server software,'' he said.
I raised several serious objections, and explained them in detail, in a series of 9 messages. One of my messages was discarded by the DNSEXT censor. The discussion included 2 messages from Mark Andrews*, 2 from Kevin Darcy, 1 from Aaron Durchgaloch, 3 from Gustafsson*, 1 from Koch, 3 from Masataka Ohta, and 2 from Brian Wellington*.
2001.04.04: Several messages from me, a few from Gudmundsson, 4 from Andrews*, 1 from Roy Arends*, 4 from Darcy, 1 from Robert Elz, 1 from Gustafsson*, 2 from Greg Hudson, 1 from Bill Sommerfeld, 4 from independent DNS implementor Sam Trenholme, and 1 from Wellington*.
The discussion began when Olafur Gudmundsson claimed that ``the working group consensus is to advance the document'' once certain minor issues had been addressed. Gudmundsson never provided any justification for this claim.
Trenholme blasted Gudmundsson on another mailing list:
The process for making DNS-related RFCs is open only in name. In reality, the people in the process of making DNS-releated RFCs are not listening to a number of important objections. For example, there was a recently proposed RFC which adds a bunch of arbitrary and, quite frankly, useless, rules to the AXFR (zone transfer) process.Dan, rightly so, brought up a number of objections with this internet draft.
These objections were completely ignored.
2001.06.22: Gustafsson* released a new draft, axfr-clarify-02, with several ``major changes.'' Gudmundsson immediately issued a ``SHORT last call,'' with a deadline of 2001.06.30.
Discussion over the next week included 3 messages from Darcy, 5 from Elz, 7 from Gustafsson*, 1 from Gudmundsson, 1 from Hall, 1 from Koch, 2 from Littlefield, and 4 from Vixie*.
2001.06.30: I returned from vacation. I immediately objected to Gudmundsson's absurd last-call schedule; Gudmundsson extended the deadline to 2001.07.06. I again pointed out that several of my objections had been ignored. ``They were not ignored,'' Gustafsson* said. ``They were considered and rejected.'' I began working on this web page.
2001.07.20: Gustafsson* released a new draft, axfr-clarify-03.
2002.03.05: Gustafsson* released a new draft, axfr-clarify-04.
2002.07: DNSEXT participants at the IETF Yokohama meeting decided that axfr-clarify is ``not ready to go'' because it is ``too BIND-specific.''
2002.08.19: DNSEXT censor Randy Bush wrote, on the basis of private discussions with Gustafsson*: ``the chairs are inclined to declare consensus on this draft. last call was a while ago. so if you have a contrary technical argument, now would be a very good time to make it.'' My objections were, once again, completely ignored.
2002.11.13: Gudmundsson unilaterally wrote to the IESG: ``DNSEXT has completed it's [sic] review of this document and requests that it be advanced to Proposed standard.'' Extensive discussion ensued.
2003.02.10: The IESG issued a ``Last Call'' for axfr-clarify.
Gustafsson* claims that aol.com glue from the princeton.edu AXFR servers may safely be used in referrals below princeton.edu. This claim is false. Suppose, for example, I also happen to be a .com server, and I receive the records
blah.princeton.edu NS dns-01.ns.aol.com
dns-01.ns.aol.com A 128.112.136.10
from the princeton.edu AXFR servers.
It is essential for me to discard the glue A record;
otherwise I will poison caches,
because caches trust dns-01.ns.aol.com information
from .com servers.
To the extent that there's a difference, the princeton.edu servers are wrong. For example, the princeton.edu servers say
cs.princeton.edu NS cs.princeton.edu
cs.princeton.edu NS engram.cs.princeton.edu
while the cs.princeton.edu servers say
cs.princeton.edu NS dns1.cs.princeton.edu
cs.princeton.edu NS dns2.cs.princeton.edu
If someone asks me for the cs.princeton.edu NS records,
I'm going to report dns1 and dns2, not engram.
Note that, when I transfer princeton.edu, I have not yet decided to discard the cs.princeton.edu records from the princeton.edu servers; I don't know at that point whether I'm also transferring cs.princeton.edu. Records are discarded when the transfers are combined.
Gustafsson* and Ohta claim that records are zone-specific: in particular, that the cs.princeton.edu NS engram.cs.princeton.edu record is a valid part of the princeton.edu zone. This is not consistent with the DNS specifications. Here's what RFC 1034 actually says:
axfr-clarify-02 says that an AXFR client ``MUST associate the RRs received in a zone transfer with the specific zone being transferred, and maintain that association for purposes of acting as a master in outgoing transfers.'' I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which discards records as described above when it is scripted in the usual way. This requirement violates RFC 2119, section 6.
The IETF-50 DNSEXT meeting minutes said that there was ``more support'' for BIND 9's ``preservation of zone content'' than for the BIND 8 AXFR behavior. The minutes didn't say exactly how much support there was, or how many people attended, or how packed the room was with people having financial interests in BIND.
Gustafsson* says that the IXFR protocol breaks if AXFR clients discard bad records. Well, that's too bad for the IXFR protocol. IXFR has an official status of Elective, and my users have a better protocol (rsync), so I am not going to support IXFR, and I object to the notion of IXFR-induced complications in the AXFR protocol.
There's absolutely no reason that options like IXFR have to break compatibility. The BIND company can allocate a new BXFR query type; define a BXFR response format with any desired bells and whistles (keeping in mind that BXFR responses can be from unextended servers that treat BXFR as a normal type); require master+slave servers that receive a zone in BXFR response format to provide exactly the same bytes in response to a BXFR request; require master+slave servers to reject BXFR requests if they received the zone in any other format; and, to prevent zones from being horribly mangled by transfer bugs (such as many of the IXFR implementation bugs), use cryptographic hashes to supplement serial numbers. The resulting protocol, unlike IXFR, doesn't demand any AXFR complications.
In particular, if the file includes an address for www.cs.princeton.edu, my AXFR server includes that address in the princeton.edu zone. This does not pose a problem for a working AXFR client. The client discards undesired records, as explained above; so the server doesn't have to.
Unfortunately, the BIND 8.2.3 AXFR client rejects the entire zone transfer as containing ``non-glue records'' if it doesn't see www.cs.princeton.edu in an authoritative NS record inside the princeton.edu zone. This is a current interoperability problem.
RFC 1034 and RFC 1035 don't prohibit zones of this type. The obvious fix for the interoperability problem is for BIND to stop going out of its way to check the NS records.
I could change my AXFR server to work around this BIND bug. However, that would not be sensible engineering: it would take extra code, extra CPU time, and extra disk I/O.
axfr-clarify-01 prohibits records ``from the authoritative data of zones other than the one being transferred.'' This is nonsense: every record is part of the authoritative data of some zone. See RFC 1034, section 4.2.
axfr-clarify-02 prohibits records ``associated with zones other than the one being transferred.'' A record ``is associated with a zone by being loaded from the master file of that zone at the primary master server, or by some other, equivalent method for configuring zone data.''
This is horribly unclear. Is Gustafsson trying to prohibit the whole concept of a single DNS configuration file? I object to the use of BIND-specific notions here; all requirements should be defined in terms of on-the-wire behavior.
I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which takes records from all sections. This requirement violates RFC 2119, section 6.
RFC 1034 does not say ``clients read only the answer section.'' It also does not say ``clients read the entire packet.'' Both methods work correctly.
Everyone agrees that records must never appear outside the answer section. If the server puts records outside the answer section, the server is violating the protocol. (There was consensus on this in a face-to-face meeting, and there has been no dispute on the mailing list.) This does not mean that the client is violating the protocol.
Andrews* says that he might want to extend the zone-transfer protocol by putting new information into the authority section and the answer section. He admits that this extension would be incompatible with my AXFR client, which is deployed at thousands of sites. Does he draw the obvious conclusion that the incompatible protocol should be deployed on a different TCP port? No! He demands that my users and I go to extra effort so that he can run an incompatible protocol on the same port.
Yes, extensibility is often a helpful protocol feature, but it is fifteen years too late to start adding new forms of extensibility to the AXFR protocol. We have an installed base now, and the BIND company does not have the right to break compatibility with the installed base, even if it drops the pretense that it is merely ``clarifying'' the existing protocol.
I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR server, which simply closes the connection. This requirement violates RFC 2119, section 6.
AXFR is a local matter between a master and its authorized slaves. Clients without authorization have no business asking for AXFR.
Andrews* claims that clients cannot pipeline AXFRs on a single connection if servers are allowed to close connections. This claim is false. It is easy to construct a pipelining client that will handle errors properly. (In the real world, client implementors open separate TCP connections for separate transfers.) Felix von Leitner adds the following comment:
Pipelining is a performance hack that only matters once the setup is correct. First comes correctness, then comes performance. So in the real world, there are no AXFR pipelines where part of the domains are not allowed. This makes Andrews' point a straw man.Toni Mueller adds the following comment:
The section on unauthorized clients - requiring an answer packet - may interfere with the operator's wish to cut the name server off specific clients using a firewall. The client has no apparent way (imho) to distinguish this from a network outage, or from a "broken" server, and it doesn't add anything obviously useful.
I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which uses a different method to check for errors. This requirement violates RFC 2119, section 6.
I object to this recommendation, because (1) it is not necessary for interoperability and (2) it discourages the behavior of my AXFR client, which doesn't bother checking the IDs. This recommendation violates RFC 2119, section 6.
Do normal clients check IDs? Yes, they do. ID checking is explicitly listed as part of the recommended resolution algorithm in RFC 1034 section 5.3.3. It is not, however, part of the zone-transfer protocol in section 4.3.5.
``Failing to check the ID opens a server to spoofing,'' Wellington* claims. That's not true. TCP connections already have sequence numbers, and anyone who wants serious security for AXFR can run AXFR over IPSEC or ssh. IPSEC-protected AXFR shouldn't bother with TSIG, so why should it bother checking IDs?
Andrews* points out that AXFR requests can, in theory, be multiplexed over a single TCP connection. I agree that a hypothetical multiplexing AXFR client would have to check IDs. But this has no relevance to the behavior of my AXFR client.
I object to this recommendation, because (1) it is not necessary for interoperability and (2) it discourages the behavior of my AXFR server, which doesn't bother repeating the question.
Wellington* claims that this recommendation is ``an arbitrary decision based on existing practice.'' In fact, it is a pointless recommendation that does not take full account of existing practice.
Felix von Leitner adds the following comment:
What is the point of repeating the request? If it's SHOULD, it is not necessary, so clients have to cope with the server not doing it. It also offers no additional protection or performance benefit, in the contrary: it wastes bandwidth.
I objected to this recommendation. People protecting their communications with IPSEC, for example, should not be encouraged to use TSIG.
This problem was fixed in axfr-clarify-02, which recommends ``a cryptographic mechanism for ensuring authenticity and integrity,'' such as TSIG or IPSEC or TLS.
I objected to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR server, which always sets RD to 0. This requirement violates RFC 2119, section 6.
This problem was fixed in axfr-clarify-02.
I also proposed that RD be prohibited in AXFR requests. RD makes no sense for AXFR and is not used by existing AXFR clients. This proposal was ignored.
This is how my AXFR server works, and it is how BIND 9 works. It is, however, completely out of whack with how most versions of BIND work. I object to this document being fraudulently characterized as a ``clarification,'' a codification of ``existing practice,'' and a description of ``the fielded DNS server software''; it should be labelled and reviewed as a revision of the protocol.
Dean Anderson writes:
While there could be reasons to change something, that isn't what "clarify" means. "Clarify" is where you document what was _done_ when the specifications were vague.It seems highly inappropriate to make seemingly gratiutous changes in a particular commercial product, begin distributing those changes to users, and then attempt to change the standards to reflect the changes, and describing those changes as a "clarification".
This seems more like behind the scenes dirty tricks.