more clarification needed on TSIG please

J.D. Bronson jbronson at wixb.com
Tue Jun 29 13:49:02 UTC 2004


At 08:31 AM 06/29/2004, you wrote:
>         CISCO, in their infinite wisdom, decided to have their NAT
>         alter the DNS message content when the transport was UDP and
>         not alter it when it was TCP.
>
>         TSIG works by generating a cryptographically secure hash of
>         the DNS message.  Altering the contents of the DNS message
>         (with the exception of the message id) will cause the TSIG
>         to fail.
>
>         You should be able to verify whether 'no-payload' works or
>         not by capturing the packet refresh packet both sides of
>         the firewall and seeing if the DNS message in it has been
>         modified.
>
>         If the DNS messages are identical 'no-payload' is working.
>         By identical I mean evey bit with the exception of the
>         message id.
>
>         Mark

First off...THANK YOU for at least pointing this out. I did find out a few 
years ago that I had to add 'no-payload' to the NAT mappings or direct 
queries against my machine ended up give out INTERNAL view IPs rather than 
EXTERNAL view IPs. That was most amusing to troubleshoot.

Here is what I currently have:
ip nat inside source static 10.10.10.171 64.91.71.171 no-payload
ip nat inside source static 10.10.10.172 64.91.71.172 no-payload

(IPs are scrambled of course)

that fixed my 1st issue, but not my TSIG issue. I still feel that TSIG is 
being blocked by the firewall (or CBAC within the cisco).
I see the TSIG notify from WAN to my LAN, but then the transfer always fails.

Nothing is in the cisco log at all. But if I do a dig (like above) to 
transfer the zone (on the same machines involved) it works fine. I only 
allow transfers with TSIG KEYS...not even by IPs.

So...my next approach is a port thing. Is there anyways around 
this..perhaps a port or change from UDP to TCP for example?

My last approach will be to toss the cisco on ebay and buy a different 
router that does not mess with payload or have these issues.





-- 
J.D. Bronson
Aurora Health Care // Information Services // Milwaukee, WI USA
Office: 414.978.8282 // Email: jd at aurora.org // Pager: 414.314.8282



More information about the bind-users mailing list