Solved: DNS Query error in ASA

ankurs2008 · ‎06-22-2010

hi halijenn / experts

106007 Deny Inbound UDP from 63.131.5.11/32411 to 63.131.64.142/53 due to DNS Query

This is the error which customer is getting when he is having Public DNS Server inside the organization .Following static and ACL configured for the same .However when i do it from my end , i am able to see that it is getting resolved to a name But customer says that on public internet when he type in nslookup, and type server 63.131.64.142 he wait for the response and he never gets that.

object-group protocol DOMAIN
protocol-object udp
protocol-object tcp

static (DMZ,Outside) 63.144.54.1 192.168.16.1 netmask 255.255.255.255

access-list Out2In extended permit object-group DOMAIN any host 63.144.54.1 eq domain
access-group Out2Inin in interface Outside

I have gone through the link for syslog 106007 , but i was not pretty sure if the explanation fits over here as i see the acls are configured . Please let me know what could be the probable reason .

http://www.cisco.com/en/US/docs/security/asa/asa80/system/message/logmsgs.html#wp4768890

Jennifer Halim · ‎06-22-2010

You can configure "any" for the client, or you can have a more specific ip address (your customer's actual ip address). Just in case there are a lot of DNS query going towards the DNS server.

Further to that, i wouldn't worry too much about the port# in the ACL, just match it on UDP without port as I wouldn't think there would be other types of UDP traffic going towards the DNS server.

access-list capi permit udp host any

access-list capi permit udp any host

access-list capo permit udp host any

access-list capo permit udp any host

View solution in original post

Jennifer Halim · ‎06-22-2010

Hi Ankur,

Can you please advise what is the DNS server ip address?

From the syslog, it seems that the DNS server is 63.131.64.142, however from the static NAT configuration, it's 63.144.54.1 (which is a different address).

Can you please confirm. Thanks.

ankurs2008 · ‎06-22-2010

halijenn

i am sorry , please read the syslog as 63.144.54.1 .There is no IP as 63.131.X.X .

Jennifer Halim · ‎06-22-2010

It's strange that you were able to resolve DNS using the same DNS server, while others can't from a different address.

You can run packet capture from both your address and your customer's address on the outside interface, and download it in pcap format to see if there is any difference between the 2 DNS queries. Is your customer able to test it with a different machine? or using the same machine and testing it from another internet provider?

ankurs2008 · ‎06-22-2010

hi halijenn

thanks for looking into issue . please let me know if the below packet captures will be correct to take .Yes , i have asked him to chk with a diff . machine and from a different ISP as well .

access-list capi permit udp host eq 53 any

access-list capi permit udp any host eq 53

access-list capo permit udp host eq 53 any

access-list capo permit udp any host eq 53

Jennifer Halim · ‎06-22-2010

You can configure "any" for the client, or you can have a more specific ip address (your customer's actual ip address). Just in case there are a lot of DNS query going towards the DNS server.

Further to that, i wouldn't worry too much about the port# in the ACL, just match it on UDP without port as I wouldn't think there would be other types of UDP traffic going towards the DNS server.

access-list capi permit udp host any

access-list capi permit udp any host

access-list capo permit udp host any

access-list capo permit udp any host

ankurs2008 · ‎06-22-2010

Besides that can u please let me know as to what possibly cud be the issue

Jennifer Halim · ‎06-22-2010

Unfortunately at this stage we don't have enough information to determine possible causes.

You might also want to issue "clear asp drop", test the failed dns resolution and check "show asp drop" output and see if there is any specific asp drop reason that might be dropping the dns query.

abinjola · ‎06-22-2010

can you get us the output of show run pol ?