BIND problem

[Brad Knowles]

At 11:45 PM -0400 8/1/01, David Kirk wrote:

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

	So long as no humans are *ever* involved in any aspect of the 
process of maintaining DNS data, then you can use whatever you want, 
so long as it follows the rules and you always monotonically increase 
the integer that you use.

	However, when it comes to human involvement, especially with 
debugging, it is much, much easier to use numbers that appear to have 
some particular semantic meaning, even if it is just by convention.


	Besides, YYYYMMDDNN would allow you to have a hundred updates in 
a single day before you would potentially have problems, and will 
continue working just fine until sometime in the year 2038 (when the 
32-bit integer quantity would overflow).

	If you still want to use a format that has some meaning, but you 
need to allow more updates than this, you could go to YYYYJJJNNN, 
where "JJJ" is the Julian day of the year.  This would allow you up 
to a thousand updates per day.


	Basically, it's just a convention designed to help make more 
sense to us humans, and unless you've got a particular pressing need 
to use anything else, or you use automatic DNS maintenance tools that 
make it difficult to use this format, then you probably should not be 
using anything else.

-- 
Brad Knowles, <brad.knowles at skynet.be>

H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA