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