moving DNSSEC to a hidden master
Is there a recommended order of operations when moving DNSSEC-enabled nameservers to a hidden-master setup? I'm hoping it's just as simple as moving all these files into place on the hidden master: *.key *.private managed-keys.bind *.jbk *.jnl *.signed *.signed.jnl If not, what do I need to do? In theory I suppose I could crank all TTLs down to 0 and generate new keys on the hidden master and generate new DS keys for the registrar, but is that necessary? This is all on bind 9.9.4. Thanks. dn ___ 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: moving DNSSEC to a hidden master
On 10/1/13 2:16 PM, David Newman wrote: > Is there a recommended order of operations when moving DNSSEC-enabled > nameservers to a hidden-master setup? Actually, this is really a more general question: Is there a recommended order of operations when migrating zones between any two DNSSEC-enabled nameservers, assuming the same version of bind on each? thanks dn > > I'm hoping it's just as simple as moving all these files into place on > the hidden master: > > *.key > *.private > managed-keys.bind > *.jbk > *.jnl > *.signed > *.signed.jnl > > If not, what do I need to do? In theory I suppose I could crank all TTLs > down to 0 and generate new keys on the hidden master and generate new DS > keys for the registrar, but is that necessary? > > This is all on bind 9.9.4. > > Thanks. > > dn > > ___ > 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 > ___ 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: moving DNSSEC to a hidden master
On Oct 1, 2013, at 8:27 PM, David Newman wrote: > On 10/1/13 2:16 PM, David Newman wrote: >> Is there a recommended order of operations when moving DNSSEC-enabled >> nameservers to a hidden-master setup? > > Actually, this is really a more general question: Is there a recommended > order of operations when migrating zones between any two DNSSEC-enabled > nameservers, assuming the same version of bind on each? Eh... I'm not sure what the complexity here is. Set the "new" machine up as a slave, use the standard axfr mechanism to replicate the zones, move the keying material and then convert the new system form slave to master while taking the existing master off-line. What am I missing? AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: moving DNSSEC to a hidden master
On 02/10/13 02.47, Alan Clegg wrote: > On Oct 1, 2013, at 8:27 PM, David Newman wrote: > >> On 10/1/13 2:16 PM, David Newman wrote: >>> Is there a recommended order of operations when moving DNSSEC-enabled >>> nameservers to a hidden-master setup? >> Actually, this is really a more general question: Is there a recommended >> order of operations when migrating zones between any two DNSSEC-enabled >> nameservers, assuming the same version of bind on each? > Eh... I'm not sure what the complexity here is. > > Set the "new" machine up as a slave, use the standard axfr mechanism to > replicate the zones, move the keying material and then convert the new system > form slave to master while taking the existing master off-line. > > What am I missing? I believe that was the question, what is missing here - if anything. Seems too easy, there has to be a catch. Anything to do to catch up on internal states, How to be sure the new master will continue exactly as the old one had done. Maybe it is that simple, that would be great, but if you are not sure, it is a good question to ask. > > 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 -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ 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: moving DNSSEC to a hidden master
On Oct 1, 2013, at 9:04 PM, Sten Carlsen wrote: > > On 02/10/13 02.47, Alan Clegg wrote: >> On Oct 1, 2013, at 8:27 PM, David Newman >> wrote: >> >> >>> On 10/1/13 2:16 PM, David Newman wrote: >>> Is there a recommended order of operations when moving DNSSEC-enabled nameservers to a hidden-master setup? >>> Actually, this is really a more general question: Is there a recommended >>> order of operations when migrating zones between any two DNSSEC-enabled >>> nameservers, assuming the same version of bind on each? >>> >> Eh... I'm not sure what the complexity here is. >> >> Set the "new" machine up as a slave, use the standard axfr mechanism to >> replicate the zones, move the keying material and then convert the new >> system form slave to master while taking the existing master off-line. >> >> What am I missing? > I believe that was the question, what is missing here - if anything. Seems > too easy, there has to be a catch. > Anything to do to catch up on internal states, How to be sure the new master > will continue exactly as the old one had done. Maybe it is that simple, that > would be great, but if you are not sure, it is a good question to ask. Fair enough. David: I've done this quite a few times and haven't had issues. I guess there _could_ be an issue if you are not careful, take too long getting the new master online and allow RRSIGs to expire. If you've been careful previously and don't take over 10 days to get the new master online (assuming default signature lifetime), all should be fine. The original post mentioned moving .jnl files, etc. which I would not recommend. Don't try to "replicate" the initial master by moving all of the files; allow the protocol to do the work replicating the zone data and you should be able to just copy the keying material across. Of course, you will need to make sure that you have the new master configured to do the signing in the same way as you did on the "being-retired" master server. (and as a side note, never use zero TTLs) AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: moving DNSSEC to a hidden master
As Alan said copy the .key and .private files over. Disable updating on the old master. Transfer the zone contents by setting up as a slave using "masterfile-format text"; or using by using dig. This will give you the most up to date version of the zone. dig axfr zone +onesoa @oldmaster Check that the new server is working and you can update the zone by using nsupdate. Convert the old master server into a slave. Update the other slaves to talk to a new master. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Recursive server forwarding dynamic updates
Hi, I'm looking for a way to setup a recursive/forwarding named server to forward dynamic updates. I know this is not something that RFC2136 allows, but wondering if it can be done or someone else needs this functionality? Basically, instead of returning NOTAUTH a recursive server (or forwarding) should find the authoritative server for that domain/zone and forward the dynamic update. Thanks, Bojan ___ 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: Recursive server forwarding dynamic updates
On 10/02/2013 07:51 AM, Bojan Tomic wrote: Hi, I'm looking for a way to setup a recursive/forwarding named server to forward dynamic updates See "allow-update-forwarding" in the ARM. Obviously you will lose source IP / TSIG key info, so will need to perform access checks at the forwarding server, and allow everything you need at the target server from the source/key of the forwarder. ___ 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
