Inline-signing feature request: Directly set the signed zone's serial number
Hi, After reinitialising the inline-signing process (for example by removing the journal files or redeploying the master server) the freshly signed zone's serial number will usually be behind the authoritative version on the slaves causing transfers to fail — possibly leading to expired signatures, zone expiry, etc. Currently, bumping the serial number of the unsigned zones to exceed that of the slaves is required, however it would be /convenient/ to have a one-shot method (perhaps via rndc) for specifying the signed zone serial number such that this doesn't require edits to the unsigned zone files. This is especially useful in bootstrapping scenarios where the zone data is held under strict revision control or generated by some provisioning system that owns the serial number. Am I on my own with this or would others find this useful? Thanks, Terry ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 10/7/2014 9:49 AM, Terry Burton wrote: This is especially useful in bootstrapping scenarios where the zone data is held under strict revision control or generated by some provisioning system that owns the serial number. By setting the number backwards, you are breaking all of your slave servers and causing no-end of problems getting all of THEM corrected. Seems better to set the number correctly (as in higher than the number that was being used in the signed zones before the change) in your version/provisioning system. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 7 Oct 2014 18:42, Alan Clegg a...@clegg.com wrote: On 10/7/2014 9:49 AM, Terry Burton wrote: This is especially useful in bootstrapping scenarios where the zone data is held under strict revision control or generated by some provisioning system that owns the serial number. By setting the number backwards, you are breaking all of your slave servers and causing no-end of problems getting all of THEM corrected. You've misunderstood. I'm not attempting to decrease the serial number. With inline signing you have a hidden serial number in the unsigned zone and an exposed serial number in the signed versions which your slaves track. After redeployment (following DR, emergency relocation, elastic capacity expansion, etc.) I want to be able to bump the exposed serial number (once) back to an appropriate value without having to modify the unsigned zones. (For context, the unsigned zone serial number matches the revision number in a VCS to which the DNS infrastructure hosts and administrators have read-only access, i.e. mandatory separation of infrastructure and data access rights.) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 10/7/14 11:03 AM, Terry Burton wrote: With inline signing you have a hidden serial number in the unsigned zone and an exposed serial number in the signed versions which your slaves track. After redeployment (following DR, emergency relocation, elastic capacity expansion, etc.) I want to be able to bump the exposed serial number (once) back to an appropriate value without having to modify the unsigned zones. (For context, the unsigned zone serial number matches the revision number in a VCS to which the DNS infrastructure hosts and administrators have read-only access, i.e. mandatory separation of infrastructure and data access rights.) * Check out the unmodified version of the unsigned zone * Increase the serial number in the checked out copy to be past the one in the signed zone * rndc reload * Delete the modified version of the zone file, and revert to the master copy ... all of which is not to say that your request is not reasonable, just letting you know that a solution exists. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 7 Oct 2014 21:44, Doug Barton do...@dougbarton.us wrote: On 10/7/14 11:03 AM, Terry Burton wrote: With inline signing you have a hidden serial number in the unsigned zone and an exposed serial number in the signed versions which your slaves track. After redeployment (following DR, emergency relocation, elastic capacity expansion, etc.) I want to be able to bump the exposed serial number (once) back to an appropriate value without having to modify the unsigned zones. (For context, the unsigned zone serial number matches the revision number in a VCS to which the DNS infrastructure hosts and administrators have read-only access, i.e. mandatory separation of infrastructure and data access rights.) * Check out the unmodified version of the unsigned zone * Increase the serial number in the checked out copy to be past the one in the signed zone * rndc reload * Delete the modified version of the zone file, and revert to the master copy ... all of which is not to say that your request is not reasonable, just letting you know that a solution exists. Sure, this is the approach that is currently taken. As stressed in my request, this is purely for convenience... and a little bit of obsessive data purity - load what you're given without additional processing, etc. Thanks all the same! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 10/7/2014 2:03 PM, Terry Burton wrote: On 7 Oct 2014 18:42, Alan Clegg a...@clegg.com mailto:a...@clegg.com wrote: On 10/7/2014 9:49 AM, Terry Burton wrote: This is especially useful in bootstrapping scenarios where the zone data is held under strict revision control or generated by some provisioning system that owns the serial number. By setting the number backwards, you are breaking all of your slave servers and causing no-end of problems getting all of THEM corrected. You've misunderstood. I'm not attempting to decrease the serial number. With inline signing you have a hidden serial number in the unsigned zone and an exposed serial number in the signed versions which your slaves track. After redeployment (following DR, emergency relocation, elastic capacity expansion, etc.) I want to be able to bump the exposed serial number (once) back to an appropriate value without having to modify the unsigned zones. Ok, I'm aware of the difference between unsigned and signed zones in an in-line signing configuration and am more and more curious about your terminology of appropriate value for the signed zones. If the data hasn't changed, the serial is appropriate. If the data has changed, the signed data serial number is going to be incremented the next time you transfer (bump in the wire) or reload (on box) the data. As Doug said, edit the data and when you reload it's going to do the right thing but you should never get into this predicament to begin with from my limited understanding of DNS. Now, the problem with his added step is that the next time you edit the file that you have in your version control system, the serial number is now going to match (if you treat it as just a number) the one that you edited OUTSIDE OF THE PROCEDURE and you won't get correct zone transfers. I'd recommend adding one step to the DR/whatever procedure: bump serial number in version control in to complete process. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Inline-signing feature request: Directly set the signed zone's serial number
-Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users- boun...@lists.isc.org] On Behalf Of Alan Clegg Sent: Wednesday, 8 October 2014 8:35 AM To: bind-users@lists.isc.org Subject: Re: Inline-signing feature request: Directly set the signed zone's serial number snip I'd recommend adding one step to the DR/whatever procedure: bump serial number in version control in to complete process. AlanC Alan and Doug, how would you do this if you didn't control the zone, i.e. it was an external or customer master? Terry, I think this is a good feature suggestion. Stuart ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 7 Oct 2014 22:35, Alan Clegg a...@clegg.com wrote: On 10/7/2014 2:03 PM, Terry Burton wrote: On 7 Oct 2014 18:42, Alan Clegg a...@clegg.com mailto:a...@clegg.com wrote: On 10/7/2014 9:49 AM, Terry Burton wrote: This is especially useful in bootstrapping scenarios where the zone data is held under strict revision control or generated by some provisioning system that owns the serial number. By setting the number backwards, you are breaking all of your slave servers and causing no-end of problems getting all of THEM corrected. You've misunderstood. I'm not attempting to decrease the serial number. With inline signing you have a hidden serial number in the unsigned zone and an exposed serial number in the signed versions which your slaves track. After redeployment (following DR, emergency relocation, elastic capacity expansion, etc.) I want to be able to bump the exposed serial number (once) back to an appropriate value without having to modify the unsigned zones. Ok, I'm aware of the difference between unsigned and signed zones in an in-line signing configuration and am more and more curious about your terminology of appropriate value for the signed zones. Currently advertised serial +1. If the data hasn't changed, the serial is appropriate. If the data has changed, the signed data serial number is going to be incremented the next time you transfer (bump in the wire) or reload (on box) the data. BIND on a reinitialised signing master doesn't know about the external serial number until you tell it either by updating the unsigned zone data (fine when you control this) or update the signing state by some other method, as I propose. As Doug said, edit the data and when you reload it's going to do the right thing but you should never get into this predicament to begin with from my limited understanding of DNS. Separate the data provider and DNS infrastructure provider and this predicament ensues. Now, the problem with his added step is that the next time you edit the file that you have in your version control system, the serial number is now going to match (if you treat it as just a number) the one that you edited OUTSIDE OF THE PROCEDURE and you won't get correct zone transfers. I'd recommend adding one step to the DR/whatever procedure: bump serial number in version control in to complete process. That sounds ideal however in this case it's not possible to redefine access to the VCS in this fashion due to the integrity constraints of the current procedures. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 10/7/2014 7:39 PM, Terry Burton wrote: Separate the data provider and DNS infrastructure provider and this predicament ensues. Ah, but here-in lies trouble. You are becoming the data provider as soon as you do the signing on the data. But I digress. What about rndc sign -force that would cause a resigning (which is really what you are looking for) even if the data does not appear to the signing server to have changed. That would maintain the integrity of the source data by not needing to change it at all and would also do the right thing with the serial number. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
