«tsig verify failure» only on some zones

Joachim Tingvold joachim at tingvold.com
Tue Aug 17 21:04:00 UTC 2010


Hi,

I've been trying to wrap my head around this for a while now, so I  
thought I'd ask around here.

For a while, I've had two nameservers, one master (let's call this  
NS1), one slave (let's call this NS2) -- which has been working  
flawlessly. They've both run BIND 9.6-ESV-R1 on Debian Lenny, and has  
static, public IP-addresses.

I've tried to get a third nameserver (let's call this NS3) up and  
running. This one runs BIND 9.7.0-P1 on Debian Squeeze, and sits  
behind NAT (a Cisco-router, FWIW). Proper measures have been taken  
(ie; proper ports have been opened, «no-payload» has been applied,  
debug shows no packets being dropped, so I think I've ruled out this  
to be a NAT-issue -- I could be wrong, though).

During initial startup of NS3, most zones gets «tsig verify failure»,  
but some zones are successfully transferred. All zones uses the same  
transfer-key.

I pulled some logs, from both NS1 and NS3, showing what's happening on  
both sides; <http://home.komsys.org/~jocke/bind9-tsig-fail.txt>. For  
clarification; 80.0.0.1 is the public IP of NS3, and 90.0.0.1 is the  
public IP of NS1.

I notice that «request failed: end of file» shows up sometimes; this  
also shows up in the logs on NS2, but transfers all the zones without  
issues. NS2 has an identical config to NS3 (except other forwarders,  
etc), so I've assumed this isn't what's causing the «tsig verify  
failure». Maybe I'm wrong?

I could also mention that all three nameservers are chrooted, but  
they've all been created with the same script, so the setups are  
identical.

The timestamps from the logs differs by about ~40 seconds -- is this  
too much a variation?

Could this be an issue with different BIND-versions, or are there  
other matters that could cause this?

-- 
Joachim


More information about the bind-users mailing list