Re: moving DNSSEC to a hidden master
On Oct 13, 2013, at 9:03 PM, David Newman dnew...@networktest.com wrote:
This is where things fall apart. I run 'rndc freeze' and
increment the zone file's serial number (or make any other
change), and then run 'rndc thaw' and 'rndc reload'.
So, I'm going to jump back a bit here If the configuration that you posted
is what is actually running, you should get the following when you try to rndc
freeze:
root@server00:/etc/namedb# rndc freeze example.com
rndc: 'freeze' failed: not dynamic
root@server00:/etc/namedb#
With the associated logging:
14-Oct-2013 17:36:00.310 received control channel command 'freeze example.com'
You have views... is the definition of the internal one different from the
external one (which you posted)?
So, I re-created your zone with the following zone entry:
zone example.com in {
type master;
file master/example.com;
allow-query { any; };
allow-transfer { any; };
notify yes;
key-directory keys/;
inline-signing yes;
auto-dnssec maintain;
};
This zone isn't dynamic based on what you have posted.
It also works fine when I make changes (no freeze/thaw needed):
== Commands typed ==
root@server00:/etc/namedb# ls
bind.keys keys master named.conf rndc.key
root@server00:/etc/namedb# cd master
root@server00:/etc/namedb/master# ls
example.com example.com.jbk example.com.signed example.com.signed.jnl
root@server00:/etc/namedb/master# vi example.com
root@server00:/etc/namedb/master# rndc reload example.com
zone reload queued
root@server00:/etc/namedb/master#
== Logging produced ==
14-Oct-2013 17:39:26.565 received control channel command 'reload example.com'
14-Oct-2013 17:39:26.571 zone example.com/IN (unsigned): loaded serial 2
14-Oct-2013 17:39:26.571 zone example.com/IN (signed): serial 4 (unsigned 2)
And for those of you that have taken the DNS and BIND class, yes, I'm really
using the very same lab environment that you used in class to test things... it
works!
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 Oct 14, 2013, at 7:43 PM, Alan Clegg a...@clegg.com wrote: == Commands typed == root@server00:/etc/namedb# ls bind.keys keys master named.conf rndc.key root@server00:/etc/namedb# cd master root@server00:/etc/namedb/master# ls example.com example.com.jbk example.com.signed example.com.signed.jnl root@server00:/etc/namedb/master# vi example.com root@server00:/etc/namedb/master# rndc reload example.com zone reload queued root@server00:/etc/namedb/master# And, I get the following after the signing happens: root@server00:/etc/namedb/master# ls -al total 32 drwxr-xr-x 2 root root 4096 Oct 14 17:49 . drwxr-xr-x 4 root root 4096 Oct 14 17:38 .. -rw-r--r-- 1 root root 135 Oct 14 17:39 example.com -rw-r--r-- 1 root root 512 Oct 14 17:31 example.com.jbk -rw-r--r-- 1 root root 723 Oct 14 17:39 example.com.jnl -rw-r--r-- 1 root root 2245 Oct 14 17:49 example.com.signed -rw-r--r-- 1 root root 4730 Oct 14 17:39 example.com.signed.jnl root@server00:/etc/namedb/master# 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 [SOLVED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Alan,
Thanks very much for your responses. Per my comments inline below,
this actually wasn't broken to begin with, but I just wasn't seeing it.
On 10/14/13 10:43 AM, Alan Clegg wrote:
On Oct 13, 2013, at 9:03 PM, David Newman dnew...@networktest.com
wrote:
This is where things fall apart. I run 'rndc freeze' and
increment the zone file's serial number (or make any other
change), and then run 'rndc thaw' and 'rndc reload'.
So, I'm going to jump back a bit here If the configuration that
you posted is what is actually running, you should get the
following when you try to rndc freeze:
When I said I used 'rndc freeze' and 'rndc reload', those really were
the commands I used. I did not use 'rndc command zone'
specifically because this is a static zone, and as you note that
doesn't work.
In case you couldn't tell by now, I don't use dynamic zones. If the
freeze/thaw commands are superfluous here, please let me know.
My (admittedly limited) understanding is that DNSSEC inline signing
copies the contents of the static zone into a dynamic zone and then
serves that, leaving the static zone unchanged.
It sounds as though you're saying I don't need the freeze/thaw
commands with static zones. Yes?
root@server00:/etc/namedb# rndc freeze example.com rndc: 'freeze'
failed: not dynamic root@server00:/etc/namedb#
With the associated logging:
14-Oct-2013 17:36:00.310 received control channel command 'freeze
example.com'
You have views... is the definition of the internal one different
from the external one (which you posted)?
Nope, this zone appears only in the external view.
So, I re-created your zone with the following zone entry:
zone example.com in { type master; file master/example.com;
allow-query { any; }; allow-transfer { any; }; notify yes;
key-directory keys/; inline-signing yes; auto-dnssec maintain;
};
This zone isn't dynamic based on what you have posted.
Yes, that's right.
It also works fine when I make changes (no freeze/thaw
needed):
== Commands typed == root@server00:/etc/namedb# ls bind.keys keys
master named.conf rndc.key root@server00:/etc/namedb# cd master
root@server00:/etc/namedb/master# ls example.com example.com.jbk
example.com.signed example.com.signed.jnl
root@server00:/etc/namedb/master# vi example.com
root@server00:/etc/namedb/master# rndc reload example.com zone
reload queued root@server00:/etc/namedb/master#
Same here, except that file locations and permissions differ a bit on
FreeBSD (e.g., DNSSEC-signed zones MUST reside in a directory owned by
bind, so not 'master' because root owns that).
== Logging produced == 14-Oct-2013 17:39:26.565 received control
channel command 'reload example.com' 14-Oct-2013 17:39:26.571 zone
example.com/IN (unsigned): loaded serial 2 14-Oct-2013 17:39:26.571
zone example.com/IN (signed): serial 4 (unsigned 2)
And for those of you that have taken the DNS and BIND class, yes,
I'm really using the very same lab environment that you used in
class to test things... it works!
This is the crux of the problem: I was watching serial changes from
dig, not from the Bind logs.
In this case, I started with a serial of 2013092700, incremented it to
2013092701, and reloaded. 'dig soa' would still return 2013092700.
Problem is, bind logged the current serial number as 2013092705.
Guessing here, but it looks as though my change wouldn't be seen by
dig or any other external tool because internally, Bind was already on
a larger serial number.
As soon as I advanced the serial to something ahead of the one in the
logs, everything worked again.
This is probably another thing for dynamic zone fans to snicker at us
static zone users about. But as long as the static zone file's serial
number is greater than or equal to the internal serial number (modulo
a counter wrap), this appears to work OK.
Thanks again for the pointers. Much appreciated.
dn
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJcQhAACgkQyPxGVjntI4LWBgCg4z9M6munwjcag6TtPJuk1ey7
5B8An1z+TkRuSLAUpKyUrWmKU/T7/dvl
=3lB+
-END PGP SIGNATURE-
___
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 [SOLVED]
On Oct 14, 2013, at 9:12 PM, David Newman dnew...@networktest.com wrote: Thanks very much for your responses. Per my comments inline below, this actually wasn't broken to begin with, but I just wasn't seeing it. 8-) No problems. So, I'm going to jump back a bit here If the configuration that you posted is what is actually running, you should get the following when you try to rndc freeze: When I said I used 'rndc freeze' and 'rndc reload', those really were the commands I used. I did not use 'rndc command zone' specifically because this is a static zone, and as you note that doesn't work. In case you couldn't tell by now, I don't use dynamic zones. If the freeze/thaw commands are superfluous here, please let me know. Yes. The use of the freeze and thaw is not needed unless you are hand-modifying dynamic zones. My (admittedly limited) understanding is that DNSSEC inline signing copies the contents of the static zone into a dynamic zone and then serves that, leaving the static zone unchanged. Yes, it does that, but it does it hidden from the user -- you don't need to deal with it as if it is dynamic, just do what you were doing before and ignore the .signed and .jnl files that are created. It sounds as though you're saying I don't need the freeze/thaw commands with static zones. Yes? Correct. You treat inline-signed zones exactly like you do static zones. Pretend it's not even happening. [...] This is the crux of the problem: I was watching serial changes from dig, not from the Bind logs. In this case, I started with a serial of 2013092700, incremented it to 2013092701, and reloaded. 'dig soa' would still return 2013092700. Problem is, bind logged the current serial number as 2013092705. Guessing here, but it looks as though my change wouldn't be seen by dig or any other external tool because internally, Bind was already on a larger serial number. As soon as I advanced the serial to something ahead of the one in the logs, everything worked again. So, you were able to see the zone and zone (signed) entries in the log file? This is probably another thing for dynamic zone fans to snicker at us static zone users about. But as long as the static zone file's serial number is greater than or equal to the internal serial number (modulo a counter wrap), this appears to work OK. You shouldn't need to keep track of the signed vs. unsigned serial numbers. Inline signing is supposed to be completely (and I mean 100%) transparent to the process that you had in place prior to signing. Now that you have (what I'll call) synchronized-but-out-of-sync-due-to-inline-signing serial numbers (the signed one should be a bit higher than the unsigned one but you'll only see that from the log messages; dig should ALWAYS produce the higher number), can you try incrementing the serial on your static/unsigned zone by one, reloading the zone and seeing what the logging produces? It _should_ increment the signed version (otherwise your slaves will never update), when you reload the zone (as the SOA is resigned). [wow, that's a horrible paragraph, but I think it makes sense] Also note that the inline-signed zone (in memory and dumped out to zone.signed file) will continue to increment serial numbers even without you making changes to the static/unsigned zone because of internal re-signing caused by signature expiration. Thanks again for the pointers. Much appreciated. No problem, 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 [SOLVED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/14/13 12:39 PM, Alan Clegg wrote: In this case, I started with a serial of 2013092700, incremented it to 2013092701, and reloaded. 'dig soa' would still return 2013092700. Problem is, bind logged the current serial number as 2013092705. Guessing here, but it looks as though my change wouldn't be seen by dig or any other external tool because internally, Bind was already on a larger serial number. As soon as I advanced the serial to something ahead of the one in the logs, everything worked again. So, you were able to see the zone and zone (signed) entries in the log file? I see only the signed entry, e.g.: 14-Oct-2013 12:36:30.584 zone example.com/IN/external-in (signed): sending notifies (serial 2013092706) I do not have something for just the zone. This is probably another thing for dynamic zone fans to snicker at us static zone users about. But as long as the static zone file's serial number is greater than or equal to the internal serial number (modulo a counter wrap), this appears to work OK. You shouldn't need to keep track of the signed vs. unsigned serial numbers. Inline signing is supposed to be completely (and I mean 100%) transparent to the process that you had in place prior to signing. Now that you have (what I'll call) synchronized-but-out-of-sync-due-to-inline-signing serial numbers (the signed one should be a bit higher than the unsigned one but you'll only see that from the log messages; dig should ALWAYS produce the higher number), can you try incrementing the serial on your static/unsigned zone by one, reloading the zone and seeing what the logging produces? It _should_ increment the signed version (otherwise your slaves will never update), when you reload the zone (as the SOA is resigned). [wow, that's a horrible paragraph, but I think it makes sense] Yes. When I increment by one and reload, I see the signed entry increment in the logs. I see the same serial from dig queries to slave servers (this is a hidden master). Also note that the inline-signed zone (in memory and dumped out to zone.signed file) will continue to increment serial numbers even without you making changes to the static/unsigned zone because of internal re-signing caused by signature expiration. That's interesting. If I understand correctly, you're saying I should focus on the zone serial number, same as I always have with static zones, and pay no attention to the internal signed serial numbers. dn Thanks again for the pointers. Much appreciated. No problem, AlanC -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJcTJwACgkQyPxGVjntI4IIiQCfR0CYrv1j6v4jqASIIIizpXZt dlMAoNF8Yl4NDdgyWTxIhP1CPz7J4VnH =LPfe -END PGP SIGNATURE- ___ 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 12, 2013, at 7:59 PM, Alan Clegg a...@clegg.com wrote: On Oct 11, 2013, at 10:54 PM, David Newman dnew...@networktest.com wrote: 4. Check that the new server is working and you can update the zone by using nsupdate. This is where things fall apart. I run 'rndc freeze' and increment the zone file's serial number (or make any other change), and then run 'rndc thaw' and 'rndc reload'. There's no change in serial number, and there's no error reported in the logs. What am I missing? What log messages are you getting from named? What is the zone entry in your named.conf that relates to the zone in question? I would strongly recommend forgetting all about freeze the zone and edit as a method of updating... move completely to dynamic zones if at all possible. And yes, I noticed that you say there are no errors in the logs... there may be no errors, but if BIND isn't logging anything, I'm extremely curious as to what your logging stanza has in it. If it's not logging, turn some on (or up) so that we can help you figure out the problem. In worst case, strip out any keying material and just post your entire config file. At this point, we are all shooting in the dark. 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/13/13 1:34 AM, Alan Clegg wrote:
On Oct 12, 2013, at 7:59 PM, Alan Clegg a...@clegg.com wrote:
On Oct 11, 2013, at 10:54 PM, David Newman
dnew...@networktest.com wrote:
4. Check that the new server is working and you can update the
zone by using nsupdate.
This is where things fall apart. I run 'rndc freeze' and
increment the zone file's serial number (or make any other
change), and then run 'rndc thaw' and 'rndc reload'.
There's no change in serial number, and there's no error
reported in the logs.
What am I missing?
What log messages are you getting from named?
Sorry for not posting these earlier. Here's the log entry, with the
zone name redacted:
('rndc reload' after initial axfr and then becoming master)
Oct 13 11:50:27 uci named[62826]: using built-in root key for view
external-in
Oct 13 11:50:27 uci named[62826]: the working directory is not writable
Oct 13 11:50:27 uci named[62826]: zone example.org/IN/external-in
(signed): receive_secure_serial: unchanged
Oct 13 11:50:28 uci named[62826]: all zones loaded
Oct 13 11:50:28 uci named[62826]: running
('rndc reload' after incrementing serial number in zone file)
Oct 13 11:51:22 uci named[62826]: using built-in root key for view
internal-in
Oct 13 11:51:22 uci named[62826]: using built-in root key for view
external-in
Oct 13 11:51:22 uci named[62826]: the working directory is not writable
Oct 13 11:51:22 uci named[62826]: all zones loaded
Oct 13 11:51:23 uci named[62826]: running
What is the zone entry in your named.conf that relates to the
zone in question?
Here are the logging, options, and zone parts of named.conf:
options {
// All file and path names are relative to the chroot directory,
// if any, and should be fully qualified.
directory /etc/namedb;
pid-file/var/run/named/pid;
dump-file /var/dump/named_dump.db;
statistics-file /var/stats/named.stats;
transfer-format many-answers;
max-transfer-time-in 60;
masterfile-format text;
allow-query { trusted; };
allow-query-cache { trusted; };
allow-transfer { external-xfer; internal-xfer; };
version none;
// DNSSEC stuff
dnssec-enable yes;
managed-keys-directory managed-keys;
dnssec-validation auto;
..
};
logging {
channel default_syslog {
// Send most of the named messages to syslog.
syslog local2;
severity debug 1;
};
channel audit_log {
// Send the security related messages to a separate file.
file /var/log/named.log versions 7 size 1m;
severity debug 1;
print-time yes;
};
category default { default_syslog; };
category general { default_syslog; };
category security { audit_log; default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
};
view external in {
..
zone example.com in {
type master;
file dynamic/example.org/example.org.db;
allow-query { any; };
allow-transfer { external-xfer; };
notify yes;
key-directory managed-keys/example.org;
inline-signing yes;
auto-dnssec maintain;
};
};
I would strongly recommend forgetting all about freeze the zone
and edit as a method of updating... move completely to dynamic
zones if at all possible.
I've been resisting this, mostly because I have a lot of static zones
and I'm lazy. I know ISC has been moving toward dynamic zones, but are
they really required to run DNSSEC?
And yes, I noticed that you say there are no errors in the logs...
there may be no errors, but if BIND isn't logging anything, I'm
extremely curious as to what your logging stanza has in it.
If it's not logging, turn some on (or up) so that we can help you
figure out the problem. In worst case, strip out any keying
material and just post your entire config file.
At this point, we are all shooting in the dark.
Hope these entries help. Thanks in advance for more troubleshooting
clues...I'm sure this is easy, and I'm just missing some basic config
issue.
dn
AlanC
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJa7pAACgkQyPxGVjntI4IuhACg10jF/MHLLlXKt3fLxXWndZNm
Re: moving DNSSEC to a hidden master
On Oct 11, 2013, at 10:54 PM, David Newman dnew...@networktest.com wrote: 4. Check that the new server is working and you can update the zone by using nsupdate. This is where things fall apart. I run 'rndc freeze' and increment the zone file's serial number (or make any other change), and then run 'rndc thaw' and 'rndc reload'. There's no change in serial number, and there's no error reported in the logs. What am I missing? What log messages are you getting from named? What is the zone entry in your named.conf that relates to the zone in question? I would strongly recommend forgetting all about freeze the zone and edit as a method of updating... move completely to dynamic zones if at all possible. 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 10/4/13 10:23 AM, David Newman wrote: On 10/3/13 5:27 PM, Sten Carlsen wrote: This works for me and is the standard method: rndc freeze update serial rndc thaw Bingo. Thanks! Sorry, spoke too soon. I followed your instructions and Mark's but I'm not seeing the zone file serial number increment on the new machine, even after making other edits to the zone file. Here are the steps I'm following. Both old and new nameservers run bind 9.9.4. 1. copy the .key and .private files over - did this with rsync -prv and verified ownerships and permissions are unchanged 2. Disable updating on the old master - did this with 'rndc freeze' 3. Transfer the zone contents by setting up as a slave using masterfile-format text; or using by using dig. - did this with 'dig axfr zone +multi +onesoa @oldmaster zonefile', then edited zone file to remove top and bottom lines from dig, then changed file ownership to the named owner. Then I edited named.conf to make the new nameserver master for this zone. Then I ran 'rndc reload' on the new nameserver. A 'dig soa' query returns the same serial as on the old master. 4. Check that the new server is working and you can update the zone by using nsupdate. This is where things fall apart. I run 'rndc freeze' and increment the zone file's serial number (or make any other change), and then run 'rndc thaw' and 'rndc reload'. There's no change in serial number, and there's no error reported in the logs. What am I missing? Thanks! dn dn Rndc freeze merges the .jnl files into the zone files and stops dynamic updates. Thaw allows dynamic updates to resume. On 04/10/13 02.12, David Newman wrote: Thanks all for your responses. On 10/1/13 6:42 PM, Mark Andrews wrote: 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 Converting the new secondary to a new master worked. But incrementing the zone's serial number did not, producing an error after 'rndc reload' like this: Oct 3 16:00:29 host named[35249]: malformed transaction: dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 != transaction first serial 2013092700 and you can update the zone by using nsupdate. Although the zone file lives under dynamic/mydomain.com so DNSSEC updates can happen, I don't have dynamic updates configured, so nsupdate won't work. This arrangement -- with static zone files under the dynamic directory -- worked OK on the old master. Permissions are the same on both. This thread suggested the journal issue was separate views pointing to the same zone file: https://lists.isc.org/pipermail/bind-users/2008-June/070807.html Indeed I had pointers to the same zone file in separate views, but removing them and restarting named did not clear the issue. Now I have the zone in just one view, and still can't manually increment the serial number without that journal complaint. Thanks in advance for clues on resolving the journal version issue. dn Convert the old master server into a slave. Update the other slaves to talk to a new master. ___ 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 ___ 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/3/13 5:27 PM, Sten Carlsen wrote: This works for me and is the standard method: rndc freeze update serial rndc thaw Bingo. Thanks! dn Rndc freeze merges the .jnl files into the zone files and stops dynamic updates. Thaw allows dynamic updates to resume. On 04/10/13 02.12, David Newman wrote: Thanks all for your responses. On 10/1/13 6:42 PM, Mark Andrews wrote: 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 Converting the new secondary to a new master worked. But incrementing the zone's serial number did not, producing an error after 'rndc reload' like this: Oct 3 16:00:29 host named[35249]: malformed transaction: dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 != transaction first serial 2013092700 and you can update the zone by using nsupdate. Although the zone file lives under dynamic/mydomain.com so DNSSEC updates can happen, I don't have dynamic updates configured, so nsupdate won't work. This arrangement -- with static zone files under the dynamic directory -- worked OK on the old master. Permissions are the same on both. This thread suggested the journal issue was separate views pointing to the same zone file: https://lists.isc.org/pipermail/bind-users/2008-June/070807.html Indeed I had pointers to the same zone file in separate views, but removing them and restarting named did not clear the issue. Now I have the zone in just one view, and still can't manually increment the serial number without that journal complaint. Thanks in advance for clues on resolving the journal version issue. dn Convert the old master server into a slave. Update the other slaves to talk to a new master. ___ 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
Thanks all for your responses. On 10/1/13 6:42 PM, Mark Andrews wrote: 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 Converting the new secondary to a new master worked. But incrementing the zone's serial number did not, producing an error after 'rndc reload' like this: Oct 3 16:00:29 host named[35249]: malformed transaction: dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 != transaction first serial 2013092700 and you can update the zone by using nsupdate. Although the zone file lives under dynamic/mydomain.com so DNSSEC updates can happen, I don't have dynamic updates configured, so nsupdate won't work. This arrangement -- with static zone files under the dynamic directory -- worked OK on the old master. Permissions are the same on both. This thread suggested the journal issue was separate views pointing to the same zone file: https://lists.isc.org/pipermail/bind-users/2008-June/070807.html Indeed I had pointers to the same zone file in separate views, but removing them and restarting named did not clear the issue. Now I have the zone in just one view, and still can't manually increment the serial number without that journal complaint. Thanks in advance for clues on resolving the journal version issue. dn Convert the old master server into a slave. Update the other slaves to talk to a new master. ___ 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
This works for me and is the standard method: rndc freeze update serial rndc thaw Rndc freeze merges the .jnl files into the zone files and stops dynamic updates. Thaw allows dynamic updates to resume. On 04/10/13 02.12, David Newman wrote: Thanks all for your responses. On 10/1/13 6:42 PM, Mark Andrews wrote: 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 Converting the new secondary to a new master worked. But incrementing the zone's serial number did not, producing an error after 'rndc reload' like this: Oct 3 16:00:29 host named[35249]: malformed transaction: dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 != transaction first serial 2013092700 and you can update the zone by using nsupdate. Although the zone file lives under dynamic/mydomain.com so DNSSEC updates can happen, I don't have dynamic updates configured, so nsupdate won't work. This arrangement -- with static zone files under the dynamic directory -- worked OK on the old master. Permissions are the same on both. This thread suggested the journal issue was separate views pointing to the same zone file: https://lists.isc.org/pipermail/bind-users/2008-June/070807.html Indeed I had pointers to the same zone file in separate views, but removing them and restarting named did not clear the issue. Now I have the zone in just one view, and still can't manually increment the serial number without that journal complaint. Thanks in advance for clues on resolving the journal version issue. dn Convert the old master server into a slave. Update the other slaves to talk to a new master. ___ 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 8:27 PM, David Newman dnew...@networktest.com 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 dnew...@networktest.com 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 st...@s-carlsen.dk wrote: On 02/10/13 02.47, Alan Clegg wrote: On Oct 1, 2013, at 8:27 PM, David Newman dnew...@networktest.com 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
