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
