cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

2539
Views
0
Helpful
6
Replies
Erik Molenaar
Beginner

Inspect DNS FWSM - DNS not resolving certain addresses

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

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

6 REPLIES 6
mirober2
Cisco Employee

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

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

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

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

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

View solution in original post

I supposed they changed something at inventionmachine...etc because the problem is gone.

Thanks for your support!

Erik

Content for Community-Ad