Re: «tsig verify failure» only on some zones
On Wed, Aug 18, 2010, at 00:42:40AM GMT+02:00, Hauke Lampe wrote: What TSIG algorithms do you use and how long are the keys? HMAC-MD5, 128 bit. The keys are 24 chars long. I'll try to test with another algorithm, however I find it quite strange; if it works for some zones, why doesn't it work for the others? It could be that you hit an interoperability bug in BIND that was fixed in 9.7.0, although it doesn't fit the symptoms exactly: I see. No, it doesn't seem like the same symptoms. I could of course try to downgrade NS3, or upgrade the two other, but I'd consider that as a last-resort solution. -- Joachim ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: «tsig verify failure» only on some zones
First thing. Ensure that the nameservers are properly ntp synced. This should get rid of mosr timing issues. Secondly, for the failing zone run tcpdump on both ends and compare the TCP payload of the packets. They should be byte for byte identical. If they differ then the NAT box is fiddling with the contents. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
«tsig verify failure» only on some zones
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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: «tsig verify failure» only on some zones
Joachim Tingvold wrote: During initial startup of NS3, most zones gets «tsig verify failure», but some zones are successfully transferred. All zones uses the same transfer-key. Could this be an issue with different BIND-versions, or are there other matters that could cause this? What TSIG algorithms do you use and how long are the keys? It could be that you hit an interoperability bug in BIND that was fixed in 9.7.0, although it doesn't fit the symptoms exactly: http://www.mail-archive.com/bind-users@lists.isc.org/msg04663.html This is just hunch. I'd have no other explanation yet. Hauke. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
