[NANOG] Re: Reasons why BIND isn't being upgraded

Pim van Riezen pi at vuurwerk.nl
Fri Feb 2 01:22:56 UTC 2001


On Fri, 2 Feb 2001, Simon Waters wrote:

> So in answer to the question - are people too busy to upgrade BIND -
> clearly 35% of admins found time to do it already. Those who had
> upgraded to 8.2.2-P7 to avoid the previous DoS bugs should have had
> nothing more to do than replace the binaries and test at 8.2.3, so I
> think the time excuse is a bit thin.

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.
(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).
(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.

When downloading I expected a security upgrade, not a service pack. The
extra traffic that new serial numbers for this amount of domains generate
is probably well-measurable. The webpage, nor any of the obvious
documentation (README, CHANGES) mentions any of these problems and I've
been bitten by them. Yes we're running 8.2.3-REL fine now, but it took a
couple of _expensive_ reloads to get everything right. If ISC wants my
trust in the future of their codebase, they will have to work on seeing
the difference between an "architecture upgrade" and a "security patch".

Yes, the information was out there, but in the context it was presented
(update now or the internet will die) I think they should make a stronger
point out of the pitfalls. And you can certainly expect more people to run
into these problems, then shrug and roll back to 8.2.2P7 because they
bumped into the same wall.

Cheers,
Pi






More information about the NANOG mailing list