[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: axfr-clarify's fraudulent claims of consensus
I'd like to make clear my support for draft-ietf-dnsext-axfr-clarify-05.
With the exception of a single subtle enhancement (the specification of
returning NOTAUTH to an AXFR request about a zone for which the server is
not authoritative), I find that the specification correctly matches my own
interpretation of RFC1034 and RFC1035 and first-hand interoperability
experience.
Regarding zone integrity, I find the specification supports the clear
requirements for the independence of zone data described in RFC1034
(sections 4.1 and 4.2), along with the practical need to ensure that all
authoritative servers for a zone will have an accurate copy of the data for
that zone for a given serial number (RFC1034, Sect. 4.3.5).
As for the requirement to carry zone transfer RRs in the answer section,
this is a completely obvious application of the rules governing all
responses to requests with opcode QUERY (0). RFC1034 clearly states that
the answer section "carries RRs which directly answer the query." I don't
see how anyone could conclude that AXFR clients should look for zone RRs
anywhere else.
I implemented AXFR in 1997 on a server architected to clearly differentiate
each zone's data, as specified (according to my reading) in RFC1034. The
axfr-clarify draft is consistent with that implementation, whose basic
architecture has not changed. This made the implementation of RFC1995
relatively trivial, because the consistency of the baseline AXFR allows the
unambiguous communication of incremental changes to that baseline, even if
the AXFR has been retrieved from one authority, and the IXFR from another,
and regardless of what other zones those servers may know about.
Regards,
Josh Littlefield
--
=====================================================================
Josh Littlefield Cisco Systems, Inc.
joshl@cisco.com 250 Apollo Drive
tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627