DNS Fixup/Inspect Pix/ASA 7.0 or greater breaking email

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

Reply to
Brian V
Loading thread data ...

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...
Reply to
Walter Roberson

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 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!

Reply to
Brian V

EDNS0 is the protocol to negotiate a larger packet size für DNS. I do strongly recommend to enlarge this inspect to 4096 bytes.

Reply to
Lutz Donnerhacke

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.

Reply to
Lutz Donnerhacke

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.