Re: How to create the TSIG?
On Thu, 2009-02-05 at 16:58 -0800, Chris Buxton wrote: Use a different key for each slave. Definitely, if each of your slaves is under distinct administration. If some organization is managing more than one of your slaves for you, I'ld suggest using a distinct key only for each cluster of commonly-administered servers. This may cut down on key-management effort. Do take care to use a secure channel for distributing the keys! /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to create the TSIG?
Hello Chris, thank you for the HOWTO... now it is more clear. OK, there are some stange things happen to my master DNS @home. Since I it seems I had a nsupdate from my Laptop, an update from my work- stations was working perfectly and now it comes: I have never used: Am 2009-02-05 16:58:27, schrieb Chris Buxton: Create a key: dnssec-keygen -a hmac-md5 -b 512 -n host slave1.key (Note: Use something better than hmac-md5 if your BIND version supports it.) This creates two files, with similar names. Extract the secret from either of them (it is the same in both) and create a key statement: key slave1.key { algorithm hmac-md5; secret put here the secret from the file; }; and this installed and was not looking into my local DNS since several weeks... Today I have found 1) a modified file /etc/bind/net.tamay-dogan.private 2) two new files /etc/bind/net.tamay-dogan.private.njl /etc/bind/rndc.key where the last one has the key enty above. Q: Does the nsupdate create/change this files? Note: The rndc.key file is not included in any files, hence I asume it is not alive and I have to include it into my. /etc/bind/named.conf.local (Debian System) Put this statement into named.conf on both the master server and one of your slaves. Then, put this into the master server's named.conf: server 192.0.2.1 { // use the actual IP address of the slave here keys { slave1.key; }; }; On the slave: server 192.0.2.2 { // this should be the IP address of the master keys { slave1.key; }; }; OK done. This will then secure all communication (except forwarded updates) between master and slave1. That includes notifies, SOA queries and responses, and zone transfers. Repeat the above for each slave. Use a different key for each slave. This means the master will have 5 keys defined (plus an RNDC key, hopefully), and 5 server statements. You may also want to create additional keys (and additional server statements) for use between slaves, just in case you ever need to promote one. OK, now I have: key rndc-key { ... }; key tdnet.key { ... }; key hetzner.key { ... }; key vallendor.key { ... }; and 5 entries like server 192.168.0.194 { keys { tdnet.key; }; }; Next, create yet another key for dynamic updates. Put that key's name into your allow-update statement. Turn on update-forwarding on the Done but... slaves, like this (in each slave zone): allow-update-forwarding { any; }; OK done. Since the master will only permit signed updates, and since the slaves will forward signed updates unmodified (signatures intact), you do not need to secure this ACL. I have for testing only me second local DNS included and I call the key tdnet.key since it is under my own control... I have now (unneccesary lines striped) [ '/etc/bind/named.conf' ]-- include /etc/bind/named.conf.options; zone . { type hint; file /etc/bind/db.root; }; zone localhost { type master; file /etc/bind/db.local; }; zone 127.in-addr.arpa { type master; file /etc/bind/db.127; }; zone 0.in-addr.arpa { type master; file /etc/bind/db.0; }; zone 255.in-addr.arpa { type master; file /etc/bind/db.255; }; include /etc/bind/named.conf.local; [ '/etc/bind/named.conf.options' ]-- options { directory /var/cache/bind; check-names master fail; check-names slave warn; check-names response ignore; auth-nxdomain no; listen-on-v6 { any; }; listen-on { 192.168.0.74; }; }; [ '/etc/bind/named.conf.local' ] key rndc-key { algorithm hmac-md5; secret ...very_short_key... ; }; key tdnet.key { algorithm hmac-md5; secret ...very_long_key... ; }; server 192.168.0.194 { keys { tdnet.key; }; }; zone private.tamay-dogan.net { typemaster; file/etc/bind/net.tamay-dogan.private; allow-transfer { 192.168.0.194; }; allow-update{ tdnet.key; }; // allow-update{ 192.168.0.91; 192.168.0.92; 192.168.0.93; 192.168.0.112; }; }; zone 0.168.192.in-addr.arpa { typemaster; file/etc/bind/db.192.168.0; allow-transfer { 192.168.0.194; }; }; And my Intranet Zone looks like: [ '/etc/bind/net.tamay.dogan.private' ]- $ORIGIN . $TTL 86400 ; 1 day private.tamay-dogan.net IN SOA dns.private.tamay-dogan.net. hostmaster.tamay-dogan.net. ( 1230807508 ; serial
Re: How to create the TSIG?
Point 1: The rndc.key file is referenced automatically if its contents are not included, because you do not have a controls statement. This is confusing, so please read the section of the ARM on the controls statement. __ Point 2: Your 'allow-update' statement is wrong. You have: allow-update { tdnet.key; }; Problem one is, you forgot the word key. allow-update { key tdnet.key; }; Problem two is, you're re-using a server-to-server key for dynamic updates. This is bad practice. You should have one key for dynamic updates to the zone, and another key for all communication with the server at 192.168.0.194. __ Point 3: Since you have an allow-transfer statement in the zone, you should change it to this: allow-transfer { key tdnet.key; }; Add all 5 slave server keys to that list. Furthermore, you can move this list out of the zone statements and into the options statement, so that you don't have to duplicate it once per zone. __ Point 4: The reason your zone has been rewritten, and the reason for the .jnl file, is that your zone has received a dynamic update. This is normal behavior. nsupdate doesn't directly create the journal file, nor does it directly modify the zone file; instead, named does this in response to the dynamic update. The .jnl file is created immediately upon receiving the first update, while the main zone file is rewritten 15 minutes later. You should constrain the size of your journal files, in the options statement, with something like this: max-journal-size 5M; The rndc.key file was created by the package installer for BIND, as part of the post-processing. It was always there; you just didn't notice it. __ Point 5: Whenever you modify named.conf, before you restart named, run named-checkconf over it, just to be sure. Chris Buxton Professional Services Men Mice On Feb 6, 2009, at 8:47 AM, Michelle Konzack wrote: Hello Chris, thank you for the HOWTO... now it is more clear. OK, there are some stange things happen to my master DNS @home. Since I it seems I had a nsupdate from my Laptop, an update from my work- stations was working perfectly and now it comes: I have never used: Am 2009-02-05 16:58:27, schrieb Chris Buxton: Create a key: dnssec-keygen -a hmac-md5 -b 512 -n host slave1.key (Note: Use something better than hmac-md5 if your BIND version supports it.) This creates two files, with similar names. Extract the secret from either of them (it is the same in both) and create a key statement: key slave1.key { algorithm hmac-md5; secret put here the secret from the file; }; and this installed and was not looking into my local DNS since several weeks... Today I have found 1) a modified file /etc/bind/net.tamay-dogan.private 2) two new files /etc/bind/net.tamay-dogan.private.njl /etc/bind/rndc.key where the last one has the key enty above. Q: Does the nsupdate create/change this files? Note: The rndc.key file is not included in any files, hence I asume it is not alive and I have to include it into my. /etc/bind/named.conf.local (Debian System) Put this statement into named.conf on both the master server and one of your slaves. Then, put this into the master server's named.conf: server 192.0.2.1 { // use the actual IP address of the slave here keys { slave1.key; }; }; On the slave: server 192.0.2.2 { // this should be the IP address of the master keys { slave1.key; }; }; OK done. This will then secure all communication (except forwarded updates) between master and slave1. That includes notifies, SOA queries and responses, and zone transfers. Repeat the above for each slave. Use a different key for each slave. This means the master will have 5 keys defined (plus an RNDC key, hopefully), and 5 server statements. You may also want to create additional keys (and additional server statements) for use between slaves, just in case you ever need to promote one. OK, now I have: key rndc-key { ... }; key tdnet.key { ... }; key hetzner.key { ... }; key vallendor.key { ... }; and 5 entries like server 192.168.0.194 { keys { tdnet.key; }; }; Next, create yet another key for dynamic updates. Put that key's name into your allow-update statement. Turn on update-forwarding on the Done but... slaves, like this (in each slave zone): allow-update-forwarding { any; }; OK done. Since the master will only permit signed updates, and since the slaves will forward signed updates unmodified (signatures intact), you do not need to secure this ACL. I have for testing only me second local DNS included and I call the key tdnet.key since it is under my own control... I have now (unneccesary lines striped) [ '/etc/bind/ named.conf' ]-- include /etc/bind/named.conf.options; zone . { type hint; file /etc/bind/db.root; }; zone localhost { type master; file
Re: How to create the TSIG?
Create a key: dnssec-keygen -a hmac-md5 -b 512 -n host slave1.key (Note: Use something better than hmac-md5 if your BIND version supports it.) This creates two files, with similar names. Extract the secret from either of them (it is the same in both) and create a key statement: key slave1.key { algorithm hmac-md5; secret put here the secret from the file; }; Put this statement into named.conf on both the master server and one of your slaves. Then, put this into the master server's named.conf: server 192.0.2.1 { // use the actual IP address of the slave here keys { slave1.key; }; }; On the slave: server 192.0.2.2 { // this should be the IP address of the master keys { slave1.key; }; }; This will then secure all communication (except forwarded updates) between master and slave1. That includes notifies, SOA queries and responses, and zone transfers. Repeat the above for each slave. Use a different key for each slave. This means the master will have 5 keys defined (plus an RNDC key, hopefully), and 5 server statements. You may also want to create additional keys (and additional server statements) for use between slaves, just in case you ever need to promote one. Next, create yet another key for dynamic updates. Put that key's name into your allow-update statement. Turn on update-forwarding on the slaves, like this (in each slave zone): allow-update-forwarding { any; }; Since the master will only permit signed updates, and since the slaves will forward signed updates unmodified (signatures intact), you do not need to secure this ACL. Chris Buxton Professional Services Men Mice On Feb 4, 2009, at 2:23 PM, Michelle Konzack wrote: Hello, since the french authorities (current government has shutdown my network in paris) I am installing my system on some root servers at different ISPs all over the world... So while reding the bind9 manual, it is not clear for me, HOW to create the TSIG and use it, because I will instal on one of my root servers bind9 as master ant then let the 5 slaves up date from it. But I have the need for dynamicaly updation the zones. So, what must I do to use TSIG? (as from the manual, allow-update with IP addresses is suicide) Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # http://www.tamay-dogan.net/ http:// www.can4linux.org/ Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How to create the TSIG?
Hello, since the french authorities (current government has shutdown my network in paris) I am installing my system on some root servers at different ISPs all over the world... So while reding the bind9 manual, it is not clear for me, HOW to create the TSIG and use it, because I will instal on one of my root servers bind9 as master ant then let the 5 slaves up date from it. But I have the need for dynamicaly updation the zones. So, what must I do to use TSIG? (as from the manual, allow-update with IP addresses is suicide) Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # http://www.tamay-dogan.net/ http://www.can4linux.org/ Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users