Reasons why BIND isn't being upgraded

Fri Feb 2 04:22:32 UTC 2001

[ 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 at acm.org>      <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>