> 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@ops.ietf.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.Andrews@isc.org