cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11086
Views
0
Helpful
5
Replies

Debugging ASA DNS inspection

Joseph Da Rosa
Level 1
Level 1

How can I debug ASA (9.1(1)) DNS inspection?  Specifically, the ASA is blocking the queries associated with dig requests like the following from ever reaching "the.name.server":

   dig @the.name.server -t ptr 1.2.3.4.reverse.somedomain.com.

And I'd like to be able to see how it's responding to the query (and deciding to block it).

I'm really just asking for the debug statements that might help me troubleshoot this, but if anyone can tell me what it is about this query that the ASA doesn't like that'd be very helpful.  It blocks the query even with very basic inspection enabled:

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 4096
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map

If I have the "inspect dns preset_dns_map" in there the ASA blocks the query, but if I remove the "inspect dns preset_dns_map" the query works just fine.

(Just to be clear, the client in question is on the ASA's inside interface and "the.name.server" is on the outside interface.)

2 Accepted Solutions

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I havent had to do this myself at any point

I did find that there is atleast 3 different debug commands related to "inspect dns"

  • debug inspect dns errors
  • debug inspect dns events
  • debug inspect dns packets

Maybe turning some of them on would give some clarification to whats happening.

Under the following configuration mode

policy-map type inspect dns preset_dns_map  parameters - See more at: https://supportforums.cisco.com/thread/2201942?tstart=0#sthash.3j02GDqr.dpuf
policy-map type inspect dns preset_dns_map  parameters - See more at: https://supportforums.cisco.com/thread/2201942?tstart=0#sthash.3j02GDqr.dpuf
policy-map type inspect dns preset_dns_map  parameters - See more at: https://supportforums.cisco.com/thread/2201942?tstart=0#sthash.3j02GDqr.dpuf

policy-map type inspect dns preset_dns_map

parameters

There is an option called

ASA(config-pmap-p)# ?

MPF policy-map parameter configuration commands:

  protocol-enforcement  DNS message format check

Wether disabling this default setting with "no protocol-enforcement" helps or wether it beats the purpose of having "inspect dns" I dont know.

- Jouni

View solution in original post

Filed as Cisco bug Id CSCue87407:

DNS: Inspection drops non in-addr.arpa PTR queries.
Symptom:
Non 'in-addr.arpa' PTR queries through an ASA  firewall configured for DNS inspection will be dropped. For example a  PTR query for IP 203.0.113.100 normally looks like  100.113.0.203.in-addr.arpa and this will be allowed by the inspection.  However, if the query does not end with 'in-addr.arpa', the query will  be dropped. An example of this would be 100.113.0.203.cisco.com .

Conditions:
This  is seen on ASA code version 9.0.x and 9.1.x due to the introduction of  the DNS 4-to-6 functionality in the DNS inspection engine.

Workaround:
If possible, disable DNS inspection in your modular policy framework and/or service policies

While Cisco designated this as a "minor" bug, it will in fact break DNS resolution for everyone -- including you -- if your ASA has DNS inspection enabled and you're attempting to resolve a domain that uses reverse domain delegation as described in (e.g.) section 5.2 of RFC 2317.  And the only fix at present is to disable DNS inspection.

View solution in original post

5 Replies 5

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I havent had to do this myself at any point

I did find that there is atleast 3 different debug commands related to "inspect dns"

  • debug inspect dns errors
  • debug inspect dns events
  • debug inspect dns packets

Maybe turning some of them on would give some clarification to whats happening.

Under the following configuration mode

policy-map type inspect dns preset_dns_map  parameters - See more at: https://supportforums.cisco.com/thread/2201942?tstart=0#sthash.3j02GDqr.dpuf
policy-map type inspect dns preset_dns_map  parameters - See more at: https://supportforums.cisco.com/thread/2201942?tstart=0#sthash.3j02GDqr.dpuf
policy-map type inspect dns preset_dns_map  parameters - See more at: https://supportforums.cisco.com/thread/2201942?tstart=0#sthash.3j02GDqr.dpuf

policy-map type inspect dns preset_dns_map

parameters

There is an option called

ASA(config-pmap-p)# ?

MPF policy-map parameter configuration commands:

  protocol-enforcement  DNS message format check

Wether disabling this default setting with "no protocol-enforcement" helps or wether it beats the purpose of having "inspect dns" I dont know.

- Jouni

Yeesh, how did I miss those?  Thanks.

This is what I see when I do "debug inspect dns packets" and then execute the specified dig command:

asa# debug inspect dns packets

DNS request: Flags=100 (Qs=1 An=0 Au=0 Ad=0)

Flow is regular

Pre-NAT (not 46) dn=1.2.3.4.reverse.somedomain.com dn_len=30

Parsing of 1.2.3.4.reverse.somedomain.com failed

And that's it (debug inspect dns errors/events don't add any more detail, by the way).  I'd assume that the "Parsing of 1.2.3.4.reverse.somedomain.com failed" message is the reason why the ASA is dropping the query packet.  If anyone has any idea why that might be or suggestions for a workaround, I'm all ears.

(I'd already tried disabling protocol-enforcement, by the way, but it didn't help--and with the debug in place now I can see that it's still giving the "Parsing of 1.2.3.4.reverse.somedomain.com failed" error.)

So it looks like the problem is that the ASA rejects (or more specifically, fails to parse) any PTR query that starts with w.x.y.z but does not end in in-addr.arpa.  For example, if you do "dig @6.6.6.6 -t ptr 1.2.3.4.in-addr.arpa." you'll get the following debug output on the ASA:

DNS request: Flags=100 (Qs=1 An=0 Au=0 Ad=0)

Flow is regular

Pre-NAT (not 46) dn=1.2.3.4.in-addr.arpa dn_len=20

Pre-NAT 4.3.2.1 dn=4.3.2.1 dn_len=20

Post-NAT 4.3.2.1 wrt_len=21 rem=4 delta=0

str=1234in-addrarpa

new udp len is 46

Embedded=4.3.2.1, Translate=4.3.2.1, Delta=0

new udp len is 46

But if you do "dig @6.6.6.6 -t ptr 1.2.3.4.anythingelse" you'll get the parse failure:

DNS request: Flags=100 (Qs=1 An=0 Au=0 Ad=0)

Flow is regular

Pre-NAT (not 46) dn=1.2.3.4.anythingelse dn_len=20

Parsing of 1.2.3.4.anythingelse failed

Unless the numeric fields ("1.2.3.4") are followed by "in-addr.arpa", you'll get this parse failure.  I tried it for an A query and didn't get the parse failure, so I assume it's associated with PTR queries only.

I wish this were just an academic concern, but unfortunately it's breaking the modified version of RFC 2317-style classless in-addr.arpa delegation we're using with our zones.

Turns out the ASA under 9.1(1) won't even resolve PTR requests under IN-ADDR.ARPA (uppercase) vs in-addr.arpa (lowercase)--e.g., it'll give the "Parsing of failed" message for a PTR query for 1.2.3.4.IN-ADDR.ARPA, even though that's inarguably a valid request.

So yet another ASA bug.  I'm starting to feel like I should charge Cisco for QA services. :-/

Filed as Cisco bug Id CSCue87407:

DNS: Inspection drops non in-addr.arpa PTR queries.
Symptom:
Non 'in-addr.arpa' PTR queries through an ASA  firewall configured for DNS inspection will be dropped. For example a  PTR query for IP 203.0.113.100 normally looks like  100.113.0.203.in-addr.arpa and this will be allowed by the inspection.  However, if the query does not end with 'in-addr.arpa', the query will  be dropped. An example of this would be 100.113.0.203.cisco.com .

Conditions:
This  is seen on ASA code version 9.0.x and 9.1.x due to the introduction of  the DNS 4-to-6 functionality in the DNS inspection engine.

Workaround:
If possible, disable DNS inspection in your modular policy framework and/or service policies

While Cisco designated this as a "minor" bug, it will in fact break DNS resolution for everyone -- including you -- if your ASA has DNS inspection enabled and you're attempting to resolve a domain that uses reverse domain delegation as described in (e.g.) section 5.2 of RFC 2317.  And the only fix at present is to disable DNS inspection.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: