02-26-2013 11:49 AM - edited 03-11-2019 06:06 PM
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.)
Solved! Go to Solution.
02-26-2013 01:16 PM
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"
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
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
03-03-2013 09:36 AM
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.
02-26-2013 01:16 PM
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"
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
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
02-26-2013 01:47 PM
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.)
02-26-2013 02:08 PM
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.
02-26-2013 08:08 PM
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
So yet another ASA bug. I'm starting to feel like I should charge Cisco for QA services. :-/
03-03-2013 09:36 AM
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.
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