TSIG help

[Kevin Darcy]

J.D. Bronson wrote:

> At 01:20 PM 6/23/2004, Kevin Darcy wrote:
>
>> J.D. Bronson wrote:
>>
>> >Hmm. I need help getting more debug out of bind 9.3.0rc1...
>> >
>> >I have TSIG working on 2 of 3 machines and it works fine in both
>> >directions. However, these 2 are on the same side of 1 router, so they
>> >never pass THRU this CISCO router.
>> >
>> >The 3 machine is off site and I can TSIG "into it" without any 
>> issue, but
>> >cant TSIG 'out of it'.
>> >
>> >I see the TSIG notify's coming from the offsite machine, but the local
>> >machine sees this and then fails:
>> >
>> >[slave]
>> >22-Jun-2004 19:26:08.637 client 1.2.3.4#23765: view external: received
>> >notify for zone 'electric.net': TSIG 'ns1.electric.net'
>> >
>> >Jun 22 19:26:08 named[1590]: zone electric.net/IN/external: refresh:
>> >failure trying master 1.2.3.4#53 (source 192.168.1.2#0): tsig verify 
>> failure
>> >
>> >
>> >....now, I am going thru a CISCO router (and I know they didnt pass 
>> TSIG
>> >awhile back...) but I think the latest IOS I am running does. After 
>> all, it
>> >does work 1 way at least...
>> >
>> >anything I can do to debug this and either find MY error, or prove 
>> that the
>> >CISCO is messing up my TSIG?
>> >
>> >it seems I can TSIG 'OUT' fine, but not 'IN'.
>> >
>> You could try sending a TSIG-signed query and see what the exact
>> response is, e.g.:
>>
>> dig chrysler.com ns @xx.xx.xx.xx 
>> -k/etc/keys/Kbogus-key.+157+33362.private
>>
>> ;; Couldn't verify signature: tsig indicates error
>>
>> ; <<>> DiG 9.2.2-P3 <<>> chrysler.com ns @xx.xx.xx.xx
>> -k/etc/keys/Kbogus-key.+157+33362.private
>> ;; global options: printcmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOTAUTH, id: 1490
>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; QUESTION SECTION:
>> ;chrysler.com. IN NS
>>
>> ;; TSIG PSEUDOSECTION:
>> bogus-key. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1088014485 300 0 1490
>> BADKEY 0
>>
>> You'll need a relatively-modern version of "dig" to do this.
>>
>> - Kevin
>
>
> Ok. Well I tried this (although slightly different):
> dig electric.net @ns1.electric.net AXFR -y ns2.blah.com:key_goes_here
>
> and that worked. In fact, no matter what keys I use on either machine 
> all TSIG works with AXFR IN and OUT fine. I cannot make it fail MANUALLY.
>
> But if I change the WAN side DNS server zone (I am slave to) and kick 
> it, I see the TSIG request but then the transfer still fails.
>
> So I am down to this:
>
> Manual dig AXFR via TSIG works in any way I try.
> Automatic TSIG AXFRs fail from WAN to LAN, but work LAN to WAN.
>
> I still think its the cisco, but need more help. Perhaps DIG uses 
> different ports (or TCP vs UDP something) wherease the REFRESH or AXFR 
> doesnt?
>
> Thanks for the hints. 

AXFR always uses TCP, but IXFR can use UDP: have you considered that 
maybe you're doing IXFR between master and slave?

You can force dig to use a particular port, or force named to use a 
particular port by specifying it as an option to the "masters" clause. 
Those should give you some knobs for doing head-to-head comparisons, but 
frankly I think you're rapidly approaching the need to break out a 
sniffer of some kind to see what's *really* going on...

- Kevin