AW: Simplistic serial number roll back
Yes it does. I guess all name servers offer a command to force a transfer of the zone without checking the serial. The ones I use support that: Bind: rndc retransfer NSD: nsd-control force_transfer PowerDNS: pdns_control retrieve Knot: knotc zone-retransfer regards Klaus > -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von John > Thurston > Gesendet: Freitag, 17. Februar 2023 21:43 > An: bind-users@lists.isc.org > Betreff: Re: Simplistic serial number roll back > > Agreed. > > > I'm not considering rolling back to old zone data, but considering > changing the algorithm used to generate the serial number for new zone > data. The new algorithm would result in the new data being published > with serial numbers which would be ignored as being "older" if they were > generated with the old algorithm. But I feel like we've wandered off the > path. > > > My question is seeking clarification of the behavior of "rndc > retransfer" - does this command perform the transfer, regardless of what > serial number it has or finds? > > > > > > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov <mailto:john.thurs...@alaska.gov> > Department of Administration > State of Alaska > On 2/17/2023 10:46 AM, Ondřej Surý wrote: > > > 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. -- 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
Re: Simplistic serial number roll back
Agreed. I'm not considering rolling back to old zone data, but considering changing the algorithm used to generate the serial number for new zone data. The new algorithm would result in the new data being published with serial numbers which would be ignored as being "older" if they were generated with the old algorithm. But I feel like we've wandered off the path. My question is seeking clarification of the behavior of "rndc retransfer" - does this command perform the transfer, regardless of what serial number it has or finds? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 2/17/2023 10:46 AM, Ondřej Surý wrote: 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.-- 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
Re: Simplistic serial number roll back
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 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 Thurston907-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 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 0x7FFF) 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 Thurston907-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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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
Re: Simplistic serial number roll back
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 Thurston907-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 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 0x7FFF) 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 Thurston907-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
Re: Simplistic serial number roll back
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 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 0x7FFF) 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 Thurston907-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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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
Simplistic serial number roll back
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 0x7FFF) 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 Thurston907-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
