DNS Fixup/Inspect Pix/ASA 7.0 or greater breaking email
|
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||||||||
|
Posted by Brian V on October 7, 2006, 6:47 pm
Please log in for more thread options
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
Please log in for more thread options  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
Please log in for more thread options 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
Please log in for more thread options * Brian V wrote: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
Please log in for more thread options * Walter Roberson wrote: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 |
| DNS Fixup/Inspect Pix/ASA 7.0 or greater breaking email | October 7, 2006, 6:47 pm |
| Packet Size greater than MTU set | November 17, 2006, 4:18 am |
| Email/ VPN using PIX 506 | October 5, 2005, 11:38 am |
| VPN and Email | October 19, 2005, 5:14 am |
| 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 |
| Bizarre URL in phishing email | March 13, 2006, 10:29 pm |
| Pix 515 - possible issue with Email Relaying | April 30, 2007, 9:37 am |
| PIX 515R - EMAIL LOCKDOWN | August 1, 2007, 10:25 am |
| email notification for unreachable switch | February 26, 2007, 3:54 pm |
| T1 issues, setting up paging/email system? | August 6, 2007, 11:02 am |
| EEM email sending problem: source ip address | October 24, 2008, 8:53 am |
|
Home Cabling Guide
Finally, an instantly downloadable book that saves you thousands in home improvement dollars! Enjoy living in 21st century technology-advanced home while increasing its selling value and competitive advantage on the real estate market. Whether your cabling is for home office or high-tech leisure, you can wire your home yourself or learn "wirish" to speak with your cabling contractors in their language! Click Here to learn more |
>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.