Re: Simplistic serial number roll back

[Ondřej Surý]

Well, the serial number arithmetics is there for a reason - you usually don’t want to rollback to previous version of the zone - you can have multiple primaries with different serial numbers. I don’t really consider the two step rollover of the serial number that complicated, so something extra needs to be put in place. And it’s something you don’t really do on a daily basis. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 17. 2. 2023, at 20:34, John Thurston <john.thurs...@alaska.gov> wrote:  That was my first thought, but stopping the secondary would affect all of the published zones. If retransfer ignores serial number, then using "rndc retransfer" would affect only the specifically-named zone in the specifically-named view. Resolution of the other zones, in all of the other views, would be uninterrupted. -- Do things because you should, not just because you can. John Thurston 907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 2/17/2023 10:23 AM, Ondřej Surý wrote: CAUTION: This email originated from outside the State of Alaska mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. Why so complicated? Stop the secondary, purge the zone files and journal, and start the secondary. The zones will get retransfered as there’s no state now. -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 17. 2. 2023, at 20:18, John Thurston <john.thurs...@alaska.gov> wrote:  Assumptions: A primary and several secondaries, with the secondaries using XFR to stay up to date. Scenario: Make a change in the serial number algorithm which will result in newer zone-data being published on an "earlier" serial number. The 'correct' method  is to increase the serial number (by steps not exceeding 0x7FFFFFFF) until it rolls back around to the desired number. These increments are to happen no more frequently than the refresh interval specified in the SOA record. This 'correct' method relies on nothing more than the communication standards defined in RFC. But if we add the assumption: All authorities are running ISC BIND software, and all are under central management. can the whole process be reduced to publishing the new serial number on the primary, and using an "rndc retransfer" on each secondary? The man-file says "retransfer . . . This  command retransfers the given secondary zone from the primary server." It doesn't say serial number is considered, nor does it does it say that it is ignored. I'm thinking it makes sense that it ignores the serial number, but I can't think of  a good way to test this. -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users