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.