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?

Improve this question
1
  • 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
    Commented Oct 2, 2017 at 16:33

1 Answer 1

Reset to default
6

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

Improve this answer
1
  • 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
    Commented Oct 4, 2017 at 11:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .