On Fri, Feb 14, 2003 at 10:32:28AM -0000, D. J. Bernstein wrote: > This ``clarification'' document prohibits several perfectly legitimate, > very widely deployed, AXFR implementation techniques. See my web page > http://cr.yp.to/djbdns/axfr-clarify.html for details. In particular, > this document violates RFC 2119, section 6, in five separate ways. See me not care. Almost all RFCs are mutually contradictory. This is not math, and even there we have Goedel. Some observations. Does this clarify things ------------------------ Well, yes. It also specifies new behaviour. The name is therefore wrong. I'd move to just call this RFC the 'New AXFR RFC' and be done with it. It should then also specify that nameservers should have configuration options to deal with older servers. Otherwise, I'd be more than happy with a non-semantics changing version of this draft, one that just documents how to start an AXFR and how to finish it. The Zone -------- Your software does not know about zones, it appears. Much of your criticism boils down to the fact that you do not have a zone concept and do not want to have one, where 1034 and 1035 simply ooze with zone definitions and they are clearly part of the DNS philosophy. Could you perhaps separate your criticism into the parts that are truly stupid and the parts that just don't fit in with your architecture? At a very early point, PowerDNS also did not have zones but it turns out to be hard to do proper interoperation without them. "Therefore, in a zone transfer the master MUST send exactly those records that are associated with the zone, whether or not their owner names would be considered to be "in" the zone for purposes of resolution, and whether or not they would be eligible for use as glue in responses" I don't really get this one on second or third reading. Does this condone weird data in a zone, data that does not end on the zone name? Like the examples you mention? > Dean Anderson, Len Budney, Felix von Leitner, Kenji Rikitake, Aaron > Swartz, Sam Trenholme (MaraDNS implementor), and me (djbdns > implementor). I object to the naming, this goes beyond clarification. Calling BIND9 behaviour 'existing practice' is bad politics. I hate this part: "and slaves MUST ignore any duplicate RRs received.". I know this is about robustness but it makes an incoming AXFR a O(N^2) operation which sucks. Yes, you could build sophisticated hashes & stuff but why not put the burden on the server supplying the zone. It has had to load the zone at least once anyhow. > is based entirely on the hope that this document will prevent future > interoperability problems, without regard to the huge redeployment costs > that this document is imposing on the users of existing implementations. Stuff changes anyhow. Otherwise we'd still be running NCP and HOSTS.TXT. I do like to have the ability to add TSIGs to an AXFR in the additional section, even if that potentially breaks older remotes. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting