Bind 8.3.4 vs Pix 6.2.2 (Revisited)

[phn at icke-reklam.ipsec.nu]

Shawn Wallis <swallis at ittc.ukans.edu> wrote:


> I have read through the list, and noticed that there have been some
> previous issues with Bind and Cisco Pix firewalls.  

> However, the problem I am currently seeing today, doesn't appear to be
> exactly the same issue.  Therefore, I have a several questions regarding
> other people's setup with Pix/Bind.

> A little background on my problem:

> It appears when I request MX records from certain sites, the
> response is delayed.  It is delayed in such a fashion, that a normal
> nslookup fails.  However, after the normal nslookup fails, the response
> returns, and is cached on the server.  Therefore, if I look it up once,
> and a second time, my server doesn't request the data again, and it
> responds immediately.

> The NAT setup is 1:1.. So, I don't believe there should be any trouble.
> UDP 53 allowed both by inbound and outbound. 

> On some occasions, the response doesn't return immediately, or doesn't
> cache.  I am guessing this is a timing issue, but I am not concerned with
> this.. 

> The site in particular I am dealing with is the MX record
> for "us.ibm.com".

> When I make this request, I see a packet from my firewall of size 544. 

> There is a Cisco bug report, stating that the Pix doesn't follow RFC 2716,
> and handles packets greater then 512 as buffer overflows..

> However, what I am seeing, is not that the packet is being dropped.. Just
> delayed.  When I use dig, the response time is anywhere from 5000 - 20000
> msec. 

> 1.  What have you done to get around the UDP 512 limitation?

> 2.  Has Cisco made any response to this?  Or is there any solution?

> 3.  I read in an earlier post, that IOS 6.2.1 fixed this problem, however
> we are running 6.2.2 and are still seeing it.  If this was true, what did
> they fix?  if anything, and does anyone have anymore info?

> 4.  Is anyone else seeing the same problem, and if so, does the mx for
> us.ibm.com give you the same trouble?

> Thanks for your help.

> - Shawn

Just did a dig for us.ibm.com mx and got an answerr from
ns.austin.ibm.com. And yes edns is used.

The packet sizes reported by dig was :
;; MSG SIZE  sent: 28  rcvd: 598
while ethereal reported an ip-packet with 'total len 637',
udp length = 617.

The whole session is saved at ftp://ftp.manet.nu/pub/us.ibm.com

And yes, it seems very likley that your problems comes from the fact that 
a/ pix don't do edns and
b/ the packet is to large for "classical dns/udp"








-- 
Peter Håkanson         
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
	   remove "icke-reklam" if you feel for mailing me. Thanx.