Bind 8.3.4 vs Pix 6.2.2 (Revisited)
phn at icke-reklam.ipsec.nu
phn at icke-reklam.ipsec.nu
Thu Feb 6 17:42:05 UTC 2003
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.
More information about the bind-users
mailing list