[ On Friday, February 2, 2001 at 02:22:56 (+0100), Pim van Riezen wrote: ]
Subject: Re: [NANOG] Re: Reasons why BIND isn't being upgraded
This is untrue. I expected this same thing. Then I ran into these gems of bogosity while updating 8.2.2-P7 to 8.2.3:
(1) 8.2.3 Doesn't accept the "(" in the SOA string to be on the next line after the IN SOA. Our script-generated zonefiles, about 45000 of them, all had this.
I seem to recall having that problem with much older versions (maybe even 4.9.x) and I've used this format for a very long time now: @ IN SOA localhost. postmaster.localhost. ( 2000041800 ; Serial number (yyyymmddhh) 8h ; Refresh 2h ; Retry 1w ; Expire 3h ) ; Minimum TTL (except of course for the more sensible units of time now allowed)
(2) 8.2.3 Changed the meaning of the last field of the SOA record and needs a $TTL directive to cover the default TTL. This also affected all of our zones (86400 seconds timeout on negative caching is, you must agree, way over the top so not a value you want to propagate).
The use of $TTL was well documented since at least 8.2.1, and indeed recent versions also syslog'ed complaints if it was missing. This is from doc/html/master.html: $TTL Syntax: $TTL <default-ttl> [<comment>] Set the default Time To Live (TTL) for subsequent records with undefined TTL's. Valid TTL's are of the range 0-2147483647. $TTL is defined in RFC 2308. (any specification of units of time can be used in place of a plain integer number of seconds). And of course RFC 2308 is from 1998, so not very new. I've been slowly adding $TTL to manually edited zone files for the past couple of years and didn't have really all that many to fix in the past few days.
(3) 8.2.3 Is unforgiving against errors in zonefiles. Where previously individual records were rejected (or served as-is), bind now insists on dropping the entire zone if something went wrong. Needless to say in a reload of 45K domains it takes a bit of time to fish out the bad ones.
So far as I saw 8.2.2-P7 logged all of these errors and so could have given you ample time to fix up all of the problems just like it did for me. Of course I've had "check-names master fail;" in my options clause for a couple of years too, so I don't notice any difference with 8.2.3. In any case it is far better to drop the entire zone than it is to load a borked one, especially if you don't catch it in time before a half dozen secondaries all tranfer the damage. First off it gives you a much more direct indication of the presense of a problem (your server is suddenly lame for the zone so even if you forget to read the log messages after a reload you'll still find out about the problem). Furthermore your secondaries will still continue to answer authoritatively with the previous revision, at least until they expire, thus preventing unexpected damage (the presense of the old version is expected, at least for some limited amount of time, after all)
When downloading I expected a security upgrade, not a service pack.
As the version number indicated you installed a new release, not a patch (though in the past even BIND patch releases with "-PN" suffixes on their identifiers have often included more than just pure fixes). Any presumptions about what a +0.0.1 version number increment means are likely to be incorrect unless you have intimate knowledge of the project producing the release. Unfortunately there was no patch this time.... I suspect a patch could have been possible, and it seems one may soon be on its way, but given the relative history of the deployment of new releases of BIND, or lack thereof, it does in some ways make sense to only make a new release available. As a developer you no doubt know full well that developing patch releases in conjunction with full releases more than doubles the amount of effort necessary for SCM and QA tasks. Unfortunately BIND has never come with the equivalent of a GNU "NEWS" file to mention explicitly all of the user-visible differences and with all new releases it sometimes a bit of an adventure to discover all the new features and any incompatibilities. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>