Decimal serial numbers in Bind 9?

[Jim Reid]

>>>>> "Simon" == Simon Dodd <simon.dodd at JOINKLLC.COM> writes:

    Simon> I have a question, regarding decimal serial numbers.
    Simon> Albitz/Liu (Ed.4), pp151-152, states that while one CAN
    Simon> place a period in a serial number, BIND 4x interprets the
    Simon> serial number by treating the number trailing a period as a
    Simon> multiplier for the number before the period, then appends
    Simon> the original multiplier, leading to some weird issues
    Simon> (e.g. to BIND 4, 1.1 > 1.10). What neither the Albitz/Liu
    Simon> book, nor a quick web search, has made clear is whether
    Simon> BIND 9x reproduces this behaviour.

Too bad you didn't consult the BIND9 documentation. The migration
notes make it clear that dots in serial numbers are no more. I quote:

	2.2. Periods in SOA Serial Numbers Deprecated

	Some versions of BIND allow SOA serial numbers with an embedded
	period, like "3.002", and convert them into integers in a rather
	unintuitive way.  This feature is not supported by BIND 9; serial
	numbers must be integers.

    Simon> The specification handed down to me is that we want to be
    Simon> using the format date.customer number.revision number,
    Simon> e.g. 20040721.6651.02.

If you must have this, you can include that info in a TXT record. Many
DNS administrators already do something like this with RCS or SCCS
version identifiers for their zone files.

    Simon> surely the proposed serial number convention
    Simon> couldn't possibly work, because BIND will multiply the
    Simon> numbers way above and beyond the 32-bit maximum

Quite frankly, it's unlikely anyone cares what BIND4 or BIND8 would do
in that case. I suspect they just ignored any overflow and used the
bottom 32 bits of whatever was calculated, as documented in RFC1982.
Though the outcome may well depend on what the CPU does if/when an
integer overflow is found. FYI, SOA serial numbers use sequence-space
arithmetic. Their actual values are meaningless. Read the RFC.