01-19-2011 03:56 AM - edited 03-11-2019 12:37 PM
Hi,
We have a FWSM version 3.1.19
Our internal DNSses are not able to resolve certain addresses for instance www.inventionmachinecommunity.com
We have configured:
inspect dns maximum-length 2048
...and even tried 4096 but this doesn't help.
When i remove the inspect dns command alle works fine. Does anyone have a clue as to hwo to resolve this issue?
Thx
Erik
Solved! Go to Solution.
01-21-2011 05:19 AM
It appears that dns inpsection does not like something about these udp 53 packets even after increasing the message length to 4096. May be the response is failing one of the following:
http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/command/reference/i2.html#wp1623043
•Enforces a domain-name length of 255 bytes and a label length of 63 bytes.
•Verifies the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message.
•Checks to see if a compression pointer loop exists.
If you remove the message length completly and simply inspect dns, does the response come through?
-KS
01-19-2011 05:18 AM
Hi Erik,
It looks like the DNS response for www.inventionmachinecommunity.com is only 1776 bytes. What syslogs are generated by the FWSM when the traffic is dropped?
-Mike
01-20-2011 03:25 AM
Thanks!
Instead of digging through the logging i did a capture on the FWSM, and exported the output to wireshark.
What i see is a standard query A inventiomachinecommunity.com (what a name..!) from our internal DNS towards 216.21.236.249.
The answer from 216.21.236.249 is reported as a malformed packet.
Every time i do this i get the same result: malformed packet.
I guess that's what makes the FWSM stumble. However it strikes me as strange that without the inspect there's no problem. In that case the response is quite usable.
Erik
**edit** I now also tried if there is an error message in logging but nothing shows up there. **edit**
01-20-2011 05:41 AM
When you issue "sh service-policy" do you see many packets dropped under dns inspection?
If you try to resolve this looooong domain name from another computer you get the same thing as well? - meaning malformed packet?
see what you see in the logs:
conf t
logging on
logging buffered 7
exit
sh logg | i x.x.x.x (where x.x.x.x is the ip address that is sending the dns request out)
-KS
01-21-2011 02:00 AM
Thanks KS
I tried this from another pc in our internal network and captured the same malformed reply packet from the same address.
The sh service-policy command shows :
Global policy:
Service-policy: global_policy
Class-map: inspection_default
...
Inspect: dns maximum-length 2048, packet 151112514, drop 30716, reset-drop 0
Thats about 0.02%
"show logging | i ..." gives me no entries that matter.
Erik
01-21-2011 05:19 AM
It appears that dns inpsection does not like something about these udp 53 packets even after increasing the message length to 4096. May be the response is failing one of the following:
http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/command/reference/i2.html#wp1623043
•Enforces a domain-name length of 255 bytes and a label length of 63 bytes.
•Verifies the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message.
•Checks to see if a compression pointer loop exists.
If you remove the message length completly and simply inspect dns, does the response come through?
-KS
04-07-2011 02:00 AM
I supposed they changed something at inventionmachine...etc because the problem is gone.
Thanks for your support!
Erik
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide