If you were Registered and logged in, you could reply and use other advanced thread options
|
Posted by Brian V on October 7, 2006, 6:47 pm
Hey guys,
Wondering if any of you have run in to this before and can perhaps list a
web reference on either Cisco or Microsoft about it.
Symptom: Email hanging in exchange queue
Platforms:
Pix or ASA 7.0 or greater
Exchange 2003
Microsoft DNS 2003
By default we all know that inspect DNS is on by default for 512byte packets
on the ASA and int Pix 7.0 and above. In certain instance this will cause
emails being sent to AOL and Comcast plus a few other mom and pops to hang
in the exchange queue. The fix is to apparently change the DNS inspect to
1500bytes.
I would have lost my shirt on this one because I would have bet every dollar
I have that there is no way that a DNS inspect command could cause only
certain emails to hang in an exchange queue. Block all maybe, but only a
few....no friggin way.
This is not the first time that we have seen this. First time I have seen
it, but a couple other engineers I work with have seen it/heard of it
before.
Anyone ever heard of this beofre?
Thanks,
-Brian
|
|
Posted by Walter Roberson on October 8, 2006, 5:15 pm
>By default we all know that inspect DNS is on by default for 512byte packets
>on the ASA and int Pix 7.0 and above. In certain instance this will cause
>emails being sent to AOL and Comcast plus a few other mom and pops to hang
>in the exchange queue. The fix is to apparently change the DNS inspect to
>1500bytes.
>I would have lost my shirt on this one because I would have bet every dollar
>I have that there is no way that a DNS inspect command could cause only
>certain emails to hang in an exchange queue. Block all maybe, but only a
>few....no friggin way.
Hold on to that shirt ;-)
The reason the problem is selective is that only -some- providers
try to return more than 512 bytes of DNS response; the ones that
return the expected size get through, but the ones that return
long responses have the response dropped, which is the same effect
as if the DNS servers were down.
There shouldn't really be more than 512 bytes of DNS response, because
UDP doesn't have any way of negotiating maximum packet size and
DNS has to work with networks that can only support the old TCP/IP
minimum maximum-packet-size of 576 bytes. For anything larger than
that, rather than sending a larger response, the DNS server should
be sending only the first 512 bytes of response and should be setting
a "response truncated" flag in the response. Upon seeing the truncation
flag, the client determines whether it was able to get the information
it needed from what it was sent, and if the truncated information
wasn't enough, the client is supposed to repeat the query but using
TCP instead of UDP (the destination port number is the same either way.)
Unfortunately, some providers figure that since "everybody" supports
1500 byte packets these days, that they can just send back longer
UDP DNS responses and the packet will get through anyhow, potentially
saving an extra connection. That's mostly fine, but fails when
you have a firewall inspection in place that knows about the protocol
and knows that those longer packets shouldn't be there and figures
that the longer packets are probably some kind of attack...
|
|
Posted by Brian V on October 8, 2006, 6:21 pm
>>By default we all know that inspect DNS is on by default for 512byte
>>packets
>>on the ASA and int Pix 7.0 and above. In certain instance this will cause
>>emails being sent to AOL and Comcast plus a few other mom and pops to hang
>>in the exchange queue. The fix is to apparently change the DNS inspect to
>>1500bytes.
>>I would have lost my shirt on this one because I would have bet every
>>dollar
>>I have that there is no way that a DNS inspect command could cause only
>>certain emails to hang in an exchange queue. Block all maybe, but only a
>>few....no friggin way.
> Hold on to that shirt ;-)
> The reason the problem is selective is that only -some- providers
> try to return more than 512 bytes of DNS response; the ones that
> return the expected size get through, but the ones that return
> long responses have the response dropped, which is the same effect
> as if the DNS servers were down.
> There shouldn't really be more than 512 bytes of DNS response, because
> UDP doesn't have any way of negotiating maximum packet size and
> DNS has to work with networks that can only support the old TCP/IP
> minimum maximum-packet-size of 576 bytes. For anything larger than
> that, rather than sending a larger response, the DNS server should
> be sending only the first 512 bytes of response and should be setting
> a "response truncated" flag in the response. Upon seeing the truncation
> flag, the client determines whether it was able to get the information
> it needed from what it was sent, and if the truncated information
> wasn't enough, the client is supposed to repeat the query but using
> TCP instead of UDP (the destination port number is the same either way.)
> Unfortunately, some providers figure that since "everybody" supports
> 1500 byte packets these days, that they can just send back longer
> UDP DNS responses and the packet will get through anyhow, potentially
> saving an extra connection. That's mostly fine, but fails when
> you have a firewall inspection in place that knows about the protocol
> and knows that those longer packets shouldn't be there and figures
> that the longer packets are probably some kind of attack...
Excellent answer Walter.
Whats got me by the short hairs is that it worked fine thru a Pix 515
running 6.3(5) using "fixup protocol dns maximum-length 512". Put an ASA
5520 using that new fangled <G> inspect.
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global-policy
class inspection_default
inspect dns preset_dns_map
Broke AOL, Comcast and a few others.....
Riddle me that batman!
|
|
Posted by Lutz Donnerhacke on October 9, 2006, 3:19 am
* Brian V wrote:
> Broke AOL, Comcast and a few others.....
You will break RIPE, *.se and a lot of other registries too. Because they
are using DNSSec. If you never need reverse lookups on IP addresses, you can
drop those answers by limiting DNS-packets to 512 bytes.
Your choice. Your broken network.
|
|
Posted by Lutz Donnerhacke on October 9, 2006, 3:17 am
* Walter Roberson wrote:
> There shouldn't really be more than 512 bytes of DNS response, because
> UDP doesn't have any way of negotiating maximum packet size and
EDNS0 is the protocol to negotiate a larger packet size für DNS.
I do strongly recommend to enlarge this inspect to 4096 bytes.
|
| Similar Threads | Posted | | Packet Size greater than MTU set | November 17, 2006, 4:18 am |
| Email/ VPN using PIX 506 | October 5, 2005, 8:38 am |
| VPN and Email | October 19, 2005, 2:14 am |
| Email access through Pix 515 | December 16, 2004, 10:43 am |
| Email access through Pix 515 | December 28, 2004, 9:25 pm |
| routing email | April 10, 2006, 7:52 pm |
| Re: routing email | April 14, 2006, 12:05 am |
| PIX 515 email issues with FQD | July 2, 2007, 2:33 am |
| VPN access to email out? | September 28, 2007, 10:22 pm |
| SSL Email SLOW sending through PIX | March 1, 2006, 10:43 am |
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map
>on the ASA and int Pix 7.0 and above. In certain instance this will cause
>emails being sent to AOL and Comcast plus a few other mom and pops to hang
>in the exchange queue. The fix is to apparently change the DNS inspect to
>1500bytes.