2

I am again managing a BIND installation with manual edits of the zone files.
After performing an update of adding one A record to a forward file and the corresponding PTR to a reverse file I asked a peer to review to ensure I did nothing stupid in the edits (never underestimate the ability to miss a trailing. or incorrect serial). He has rejected my updates because the zone files have the same serial (2017100201) he says they must be unique to each other - IE, one can be 2017100201 but then the other should be 2017100202.

Not having any fun finding reference to something that I've never heard of before. I really don't want to assign incremented serials to each zone updated - who has a reference on this?

  • 3
    The same serial is completely fine across millions of zone files (if it were not, where is the global lock to ensure that no two zone files ever share the same number?) – thrig Oct 2 '17 at 16:33
5

He is completely and utterly wrong. The serial number is part of the zone; it is no more unique between separate zones than any other record.

RFC 1035, section 5, states this clearly:

SERIAL          The unsigned 32 bit version number of the original copy
                of the zone.  Zone transfers preserve this value.  This
                value wraps and should be compared using sequence space
                arithmetic.

It says the zone, not "the entirety of all zones on the server".

Since you're running ISC BIND, you could also ask him to show you where in the Bind Administrator's Manual it says that no zone files on the server may have the same serial number. (Spoiler: Nowhere.)

  • Thanks - too often we have to try to prove a negative. Proving serials do not need to be unique is one of them as you pointed out, there is nothing in the documentation about this. I ended up distributing the minor update, issuing a named reload, following it immediately with a dig of both new records and the successful resolution of them. I emailed and attached the shell session contents to my peer and put it in the Git comments then merged the pull request. I hate merging my own pull reqs but when the only other approver on staff is thinking a false constraint applies..... – Rothweiler Oct 4 '17 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.