Bind9: Unable to stop / restart
Today I found that I was not able to stop or to restart the bind daemon, getting the error: rndc: connection to remote host closed
Googling a few minutes I found the problem is about the public key system used to communicate the program to manage the daemon (rndc) and the daemon itself (named). How to solve it? That's what I'll explain in this post:
To do it, you need to execute the following command:
root@:/etc/bind# dnssec-keygen -a hmac-md5 -b 256 -n HOST
K.+175+31628
Replacing by the name of the host we are configuring. That's will generate two files, the K.+175+31628.key and K.+175+31628.private.
Now we'll create the config file for rndc, but first we'll try to know the private key that we have created in the previous step:
root@:/etc/bind# cat /etc/bind/K.+175+31628.private
Getting the following content:
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: vqwertysx8jccnXb/B/rCjevk9inRtou9nS36NxxbxII=
Now we create a file called rndc.conf in the /etc/bind directory, writing the following:
key {
algorithm hmac-md5;
secret "vqwertysx8jccnXb/B/rCjevk9inRtou9nS36NxxbxII=";
};
server localhost {
key;
};
options {
default-server localhost;
default-key "";
};
Take care that the secret line contents the key line founded in the private key file. Also note that you have to replace with the name of your host ;-)
The last step is to edit the named.conf file, adding the following lines:
key {
algorithm hmac-md5;
secret "vqwertysx8jccnXb/B/rCjevk9inRtou9nS36NxxbxII=";
};
server 127.0.0.1 {
keys {;};
};
controls {
inet 127.0.0.1 allow { localhost; } keys {; };
};
Take in care again to replace the key with your own key and with your own hostname.
Now it's time to test our job. To do it i'll recommend you to tail -f the named.log located in /var/log to detect any error, or the syslog if you don't have an exclusive log file for the bind daemon.
To stop and start the daemon the first time (assuming that you were not able to do it before the changes made in this tip, you'll have to kill -9 the daemon, and then execute:
root@# /etc/init.d/bind9 start
Now your daemon is able to be managed by you again, executing a:
root@# /etc/init.d/bind9 stop or
root@# /etc/init.d/bind9 restart
Without any anoying messages.
If you have any other problem, let me know.
Good luck.
Googling a few minutes I found the problem is about the public key system used to communicate the program to manage the daemon (rndc) and the daemon itself (named). How to solve it? That's what I'll explain in this post:
1. Generate a new pair of public/private keys:
To do it, you need to execute the following command:
root@
K
Replacing
2. Create a new config file for rndc:
Now we'll create the config file for rndc, but first we'll try to know the private key that we have created in the previous step:
root@
Getting the following content:
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: vqwertysx8jccnXb/B/rCjevk9inRtou9nS36NxxbxII=
Now we create a file called rndc.conf in the /etc/bind directory, writing the following:
key
algorithm hmac-md5;
secret "vqwertysx8jccnXb/B/rCjevk9inRtou9nS36NxxbxII=";
};
server localhost {
key
};
options {
default-server localhost;
default-key "
};
Take care that the secret line contents the key line founded in the private key file. Also note that you have to replace
3. Edit the named config file:
The last step is to edit the named.conf file, adding the following lines:
key
algorithm hmac-md5;
secret "vqwertysx8jccnXb/B/rCjevk9inRtou9nS36NxxbxII=";
};
server 127.0.0.1 {
keys {
};
controls {
inet 127.0.0.1 allow { localhost; } keys {
};
Take in care again to replace the key with your own key and
4. Testing the new config:
Now it's time to test our job. To do it i'll recommend you to tail -f the named.log located in /var/log to detect any error, or the syslog if you don't have an exclusive log file for the bind daemon.
To stop and start the daemon the first time (assuming that you were not able to do it before the changes made in this tip, you'll have to kill -9 the daemon, and then execute:
root@
Now your daemon is able to be managed by you again, executing a:
root@
root@
Without any anoying messages.
If you have any other problem, let me know.
Good luck.