IOS ZBF DNS Translation

People who have worked with Cisco ASA probably know about an interesting feature – “DNS doctoring”. Basically, if you have static NAT configured on an ASA, and the device sees a DNS query/reply going between the NAT inside and outside interfaces, it will actually look inside the packet, and change its contents. Which is actually a useful feature in cases where one cannot (or doesn’t want to) configure split DNS on the name server.

For example, let’s say you have an internal mail server (172.16.1.10), statically translated to a public IP address (5.5.5.10). When the internal clients try to access “mail.example.com”, the (internal) nameserver will give them the correct (internal) IP – 172.16.10.10. When external clients try the same query, the reply will go through the ASA, and the external clients will receive the correct (external) IP – 5.5.5.10. And everything works.

The problem starts when Cisco IOS starts to do the same thing. It appears that if you’re running ZBF (Zone-Based Firewall) on Cisco IOS, it will automatically have the same behavior – translating DNS A and PTR queries as they go across the NAT.

However, there are two issues with the implementation:

1) Something is wrong with the translation. It seems to change the query, but not the answer. Using the same example as above, I try a reverse query for the external IP of the mail server:
root@thermite:~# host -vv  5.5.5.10
Trying “10.5.5.5.in-addr.arpa”
;; Question section mismatch: got 10.1.16.172.in-addr.arpa/PTR/IN

Notice the issue? I ask about the public address. My query gets translated by ZBF, and the server receives a query about the private address. However, when the reply comes back to me, the “question” section in the reply is not translated back. My client asked about 10.5.5.5.in-addr.arpa, and received a reply about 10.1.16.172.in-addr.arpa – which is ignored. Hence, my DNS resolution doesn’t work…

Not a problem – I’ll just disable DNS deep packet inspection! After all, it used to be quite easy on the ASA (just remove DNS from the list of deep-inspected protocols). Well… there’s the second problem!

2) Disabling the feature isn’t easy. After spending a long time looking through Cisco’s documentation (with no results), I managed to find the answer on the support forums:

no ip nat service alg tcp dns

no ip nat service alg udp dns

And yes, I have to agree with the person asking the question – “Very funny, Cisco! Now whose bright idea was that????!!”

 

Leave a Comment