BIND file serials - unique to all zones or to self only?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
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?
dns bind
asked Oct 2 '17 at 16:04
Rothweiler
132
add a comment |Â
up vote
2
down vote
favorite
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?
dns bind
asked Oct 2 '17 at 16:04
Rothweiler
132
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
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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?
dns bind
asked Oct 2 '17 at 16:04
Rothweiler
132
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?
dns bind
dns bind
asked Oct 2 '17 at 16:04
Rothweiler
132
asked Oct 2 '17 at 16:04
Rothweiler
132
asked Oct 2 '17 at 16:04
Rothweiler
132
asked Oct 2 '17 at 16:04
Rothweiler
132
asked Oct 2 '17 at 16:04
Rothweiler
132
132
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
add a comment |Â
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
3
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
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
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
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.)
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
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
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
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.)
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
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
add a comment |Â
up vote
5
down vote
accepted
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.)
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
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
add a comment |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
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.)
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
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.)
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
answered Oct 2 '17 at 17:54
Jenny D
10.2k22742
10.2k22742
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
add a comment |Â
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
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
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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f395684%2fbind-file-serials-unique-to-all-zones-or-to-self-only%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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