Hi list,
here is what happened: today I noticed some resolution's problems on my network. I did a "service named status" and here was the output: # /etc/init.d/named status rndc: connection to remote host closed This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid.
In the named's log, several entries like that: general: error: invalid command from 127.0.0.1#42033: bad auth
I am not using the key's authentication on my chrooted bind dns and it was working great so far.
Searching on rndc's files in /etc I've found mismatch for the key value in /etc/rndc.conf and /etc/rndc.key. There was also a rndc.key.rpmnew file. After giving the good value for the key entry (I've copied-pasted the value from the .key file), the bind daemon seems to be happy now.
My question is how things get broken because I didn't touch the bind's config files for a year or so (only the zone files, sometime) ?
--------------- CentOS 4.4 fully updated
[root@host etc]# rpm -qa | grep bind ypbind-1.17.2-8 bind-libs-9.2.4-16.EL4 bind-utils-9.2.4-16.EL4 bind-chroot-9.2.4-16.EL4 bind-9.2.4-16.EL4
[root@host etc]# uname -a Linux host 2.6.9-42.0.3.ELsmp #1 SMP Fri Oct 6 06:28:26 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux -----------------
Thanks for any input. Kfx
On Sat, 2006-11-18 at 16:03 +0100, kadafax wrote:
Hi list,
here is what happened: today I noticed some resolution's problems on my network. I did a "service named status" and here was the output: # /etc/init.d/named status rndc: connection to remote host closed This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid.
In the named's log, several entries like that: general: error: invalid command from 127.0.0.1#42033: bad auth
I am not using the key's authentication on my chrooted bind dns and it was working great so far.
Searching on rndc's files in /etc I've found mismatch for the key value in /etc/rndc.conf and /etc/rndc.key. There was also a rndc.key.rpmnew file. After giving the good value for the key entry (I've copied-pasted the value from the .key file), the bind daemon seems to be happy now.
My question is how things get broken because I didn't touch the bind's config files for a year or so (only the zone files, sometime) ?
Search the Centos archives for a complete explanation. Basically, a recent update changed the configurations (that's why you have an .rpmnew file) so that your rndc keys no longer match.
After an update, it's always a good idea to updatedb and then locate *.rpmnew and/or *.rpmsave.
The *potential* for the problem was reported *very* early after the 4.4 (?) update and those who watch the lists regularly avoided problems.
<snip>
HTH -- Bill
William L. Maltby wrote:
On Sat, 2006-11-18 at 16:03 +0100, kadafax wrote:
Hi list,
here is what happened: today I noticed some resolution's problems on my network. I did a "service named status" and here was the output: # /etc/init.d/named status rndc: connection to remote host closed This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid.
In the named's log, several entries like that: general: error: invalid command from 127.0.0.1#42033: bad auth
I am not using the key's authentication on my chrooted bind dns and it was working great so far.
Searching on rndc's files in /etc I've found mismatch for the key value in /etc/rndc.conf and /etc/rndc.key. There was also a rndc.key.rpmnew file. After giving the good value for the key entry (I've copied-pasted the value from the .key file), the bind daemon seems to be happy now.
My question is how things get broken because I didn't touch the bind's config files for a year or so (only the zone files, sometime) ?
Search the Centos archives for a complete explanation. Basically, a recent update changed the configurations (that's why you have an .rpmnew file) so that your rndc keys no longer match.
the rpmnew file means that an update created a *new* file. A .rpmsave file means that an update had renamed and replaced the original file. You really should know that...
After an update, it's always a good idea to updatedb and then locate *.rpmnew and/or *.rpmsave.
No bind update since 4.4 fork. I move from 4.3 to 4.4 since some times, and the problem only appears now.
The *potential* for the problem was reported *very* early after the 4.4 (?) update and those who watch the lists regularly avoided problems.
useless...
<snip>
The .rpmnew file is independent of my problem in this case. Is it possible that a process had changed the original rndc.key value? Thanks.
On Sat, 2006-11-18 at 20:59 +0100, kadafax wrote:
The .rpmnew file is independent of my problem in this case. Is it possible that a process had changed the original rndc.key value? Thanks.
There is a new bind in the fasttrack repo that fixes several bugs concerning rndc.
-
Johnny Hughes -
kadafax -
William L. Maltby