BIND problem

[David Kirk]

> However I don't have that much sympathy for computer
> administrators who when asked to give a 32 bit positive integer
> get it wrong. Didn't they think it odd that "dig" gave a
> different answer to what was in the zone file? A little bit of
> practice at arithmetic will be good for them. YYYYMMDDNN is fine
> for the foreseeable future.

I realize that the standard convention for serial numbers is to use
date, as indicated above; I've never been sure, though, what that
actually gains you.

The one requirement is that the serial number be an integer.  Why
not start with 1 and increment upwards?  Some use the serial as
the measure of the date of last change, but generally, in a larger
enterprise, you'll have some manner of version control that you
are using (or, at least, you should) anyway, so why rely on the
serial.  In the UNIX world, for instance, RCS is a good, basic
tool to handle file versioning, and it doesn't take much to learn it.
If the content in the zone file is reasonably dynamic, using the
date as serial seems somewhat impractical.

It seems like using date as serial # - such as in the YYYYMMDDNN
configuration as suggested - you are already set up much closer to the
boundaries of what is valid, whereas using a much smaller integer just
seems to make more sense in avoiding this pitfall.  You're less likely
to violate the constraint, I think, working from a smaller starting point.

I realize that there may be "religious" issues sparked up by these
comments, but I'd definitely be interested to know why the use
of date as serial number is so prevalent and recommended a
practice.