bert hubert writes:
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.
It's amazing how many errors you can pack into one paragraph. Facts:
* My software has zones. It simplifies them for the user, by taking
advantage of the RFC 1034 database-consistency requirements.
Your software (and BIND 8) causes operational problems by not
preserving zone contents.
By incorrectly merging data from child zones you can prevent
a master from sending correct data. You can also prevent slaves
from sending the correct information. You require administators
to worry about silly timing issues. You require administators to
detect when the timing was wrong and update the serial numbers
on zones just to get it retransfered with the original information
because the server couldn't keep the zone contents seperate.
Senario 1.
Server 1 master for example.com and slave for division.example.com.
division.example.com has been updated on it master to have
new delegation information, the zone has not yet refreshed
on server 1 for some reason. You receive email with the
new delegation information. You update example.com adjusting
its serial. You reload example.com. You expect the new
delegation to be advertised in the outgoing zone transfer.
This doesn't happen because the server messed with the zone
contents.
Senario 2.
Server 1 master example.com
Server 2 master division.example.com
Server 3 slave example.com and division.example.com
Server 4 slave example.com using server 3 as a master.
Server 2 the delgation infomation for division.example.com is
update and the parent zone is informed. Server 1 is updated
to contain the new delegation information. Server 3 receives
the updated parent zone before the updated child zone and
notifies Server 4 which transfers example.com WITH THE OLD
DELEGATION INFORMATION. Both masters were updated to have
the new delegation information but it doesn't get distributed
to all the servers.
You want the IETF to believe that this is *correct* AXFR
behaviour. This doesn't pass the giggle test.
This is a common implemention error caused by trying to
stuff all zones into a common database. BIND 4 got it
wrong. BIND 8 got it wrong.
You want us all to keep repeating this mistake.
All that is being asked is that the data in AXFR is preserved
so that it can be used as the data source of another AXFR and
as a dataset to which IXFR deltas can be applied. If you want
to merge the zones for non AXFR requests go ahead.
In otherwords what is entered as the zone data is what is
transmitted as the zone data.
I was very much aware of this issue when I was working as
a systems administrator for CSIRO years before I started
working for ISC. We had to make regular sweeps of the the
CSIRO.AU heirarchy to detect and clean up the errors caused
by nameservers incorrectly merging zone contents. I got
very tired of having to explain to all of the different
system admins what the problem was and how to "fix it" by
incrementing the serial number and getting the zone
re-transfered.
Mark
* The relevant difference between my software and BIND 9 is that,
when my software sees some of the RFC-1034-violating zones allowed
by BIND 9, it boils them down to the RFC-1034-compliant parts.
* BIND 8 does this to some extent too. It would sound pretty stupid
of you to claim that BIND 8 doesn't ``have a zone concept,'' don't
you think?
* The BIND company's ``AXFR clarifications'' try to eliminate the
RFC 1034 database-consistency requirements, allowing data for the
same class+name+type to vary across zones, contrary to RFC 1034,
sections 4.2.1 and 4.2.2.
Furthermore, this zone mismanagement is only one of many problems with
axfr-clarify.
If you decided to imitate BIND 9's database format in your software,
feel free---but stop trying to force me to do the same thing. It isn't
what my users want, and it's not necessary for interoperability.
[ removing duplicates ]
Yes, you could build sophisticated hashes & stuff
Learn to program: ``sort -u''.
As for your suggestion to shift this programming burden to the server:
You aren't thinking straight. There will be BIND 8 servers for the
foreseeable future, so you'll have to continue removing duplicates for
the foreseeable future. You'll be imposing a burden on servers without
removing it from clients. Silly.
I do like to have the ability to add TSIGs to an AXFR in the additional
section, even if that potentially breaks older remotes.
Again, you aren't thinking straight. Servers don't randomly use TSIG;
they use it _upon request_. Random use of TSIG has no benefits; it's a
pointless incompatibility, and there's no reason to allow it. (Besides,
IPSEC does a better job than TSIG.)
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
--
to unsubscribe send a message to
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET:
Mark(_dot_)Andrews(_at_)isc(_dot_)org