In this article, we will see how to configure DNS doctoring on the Cisco ASA. We will start by looking at the problem that DNS doctoring solves and then see how it solves this problem.

Consider the diagram below:

The web server (webserver.example.com) located in the DMZ should be accessible from both the inside (i.e., the LAN) and the outside (i.e., the Internet). For the public access to the web server, static NAT has been configured on the ASA to translate the real IP address (172.16.1.100) to a mapped IP address of 192.0.2.5.

Now, there are two possible scenarios that can occur in such a network as this:

  1. If the DNS server is configured to resolve the FQDN webserver.example.com to the real IP address of 172.16.1.100, then LAN clients will be able to access the web server but remote clients will not, because the real IP address is not routable on the Internet.
  2. If the DNS server is configured to resolve the FQDN webserver.example.com to the mapped IP address of 192.0.2.5, then that server will only be accessible by remote clients and not from the LAN.

Let’s examine these problems using a GNS3 lab. My web server is just a router with the HTTP server turned on. The DNS server is also a router configured to answer DNS requests. The configuration on the ASA is as follows:

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 192.0.2.1 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet2
 nameif dmz
 security-level 50
 ip address 172.16.1.1 255.255.255.0
!
object network LAN
 subnet 10.0.0.0 255.255.255.0
 nat (inside,outside) dynamic interface
object network DNS_SRVR_REAL
 host 10.0.0.100
 nat (inside,outside) static 192.0.2.3
object network WEB_SRVR_REAL
 host 172.16.1.100
 nat (dmz,outside) static 192.0.2.5
 !
access-list INBOUND extended permit udp any object DNS_SRVR_REAL eq domain
access-list INBOUND extended permit tcp any object WEB_SRVR_REAL eq www
access-list INBOUND extended permit icmp any object WEB_SRVR_REAL
!
access-group INBOUND in interface outside

In the configuration above, I have allowed DNS requests from any IP address on the outside to the DNS server. IP addresses from the outside are allowed to open HTTP connections to the web server and also ping the web server (for testing purposes). Finally, I have enabled ICMP inspection on the ASA (not shown in the configuration above) using the modular policy framework.

The current DNS configuration on the DNS server is as follows:

 ip host webserver.example.com 172.16.1.100

A ping from the LAN client (PC1) goes through, as shown below:

Hint: I’m using VPCS for my PCs. To configure the DNS server on a VPCS, use the command ip dns <ip_address>.

However, if we try to ping from the remote client (PC2), even though the FQDN is resolved successfully, the ping will not go through because it resolves to the real IP address of the web server:

Note: Remember to use the mapped IP address of the DNS server (192.0.2.3) as the DNS server on the remote client.

If you enable logging on the Cisco ASA while pinging from the remote client, you will see the following error:

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:192.0.2.200 dst dmz:172.16.1.100 (type 8, code 0) denied due to NAT reverse path failure

Let’s simulate the other scenario, where the DNS server is configured to return the mapped IP address of 192.0.2.5. In this case, the remote client will be able to ping the web server but the LAN client will not.

The configuration change on the router acting as the DNS server will be as follows:

no ip host webserver.example.com 172.16.1.100
ip host webserver.example.com 192.0.2.5

If we ping from PC1 again, it will not be successful:

The logs on the ASA will show that the ASA tries to build a connection to the outside IP address of 192.0.2.5 and since the web server is on the DMZ interface, that connection will never be successful and will eventually time out:

%ASA-7-609001: Built local-host outside:192.0.2.5
%ASA-6-305011: Built dynamic ICMP translation from inside:10.0.0.101/3486 to outside:192.0.2.1/12626
%ASA-6-302020: Built outbound ICMP connection for faddr 192.0.2.5/0 gaddr 192.0.2.1/12626 laddr 10.0.0.101/3486
%ASA-6-302021: Teardown ICMP connection for faddr 192.0.2.5/0 gaddr 192.0.2.1/12626 laddr 10.0.0.101/3486
%ASA-7-609002: Teardown local-host outside:192.0.2.5 duration 0:00:02
%ASA-6-305012: Teardown dynamic ICMP translation from inside:10.0.0.101/1438 to outside:192.0.2.1/40150 duration 0:00:30

Solution: DNS Doctoring

One of the ways we can resolve this issue is by enabling DNS doctoring on the Cisco ASA. Let’s assume that the DNS server is configured with the real IP address of the web server; with DNS doctoring enabled; when a remote client makes a DNS request and the ASA sees the response, it will change the real IP address in the DNS response to the mapped IP address.

On the other hand, if the DNS server is located on the outside and is configured with the mapped IP address of the web server, when a LAN client makes a DNS request to that DNS server and the server responds, the ASA will change the mapped IP address in the response to the real IP address of the web server so that the LAN client can access it locally.

Note: DNS inspection must be enabled on the Cisco ASA (in the MPF configuration) for DNS doctoring to work. DNS inspection is enabled in the default MPF configuration on the ASA.

To enable DNS doctoring, we just need to add the “dns” keyword to our static NAT configuration for the web server. Therefore, our configuration on the ASA will be:

object network WEB_SRVR_REAL
 nat (dmz,outside) static 192.0.2.5 dns

Of course for DNS doctoring to work, the ASA must be in the path of the DNS response. Therefore, let’s change the configuration on the DNS server to point back to the real IP address and then test to see if the remote client can also connect successfully.

no ip host webserver.example.com 192.0.2.5
ip host webserver.example.com 172.16.1.100

Now I will ping from both clients and you will see our configuration in effect:

You can also test that DNS doctoring works by moving the DNS server to the outside and configuring that server with the mapped IP address of the web server. If the LAN client queries that DNS server for the IP address of the web server, then the ASA will change the IP address in the response to the real IP address of the web server.

Summary

In this article, we have seen the problem that can occur when the same DNS server is serving both inside and outside users. We have enabled DNS doctoring on the Cisco ASA to resolve this issue.

I hope you have found this article informative.

Reference and Further Reading

Configure DNS Doctoring for Three NAT Interfaces on ASA Release 9.x: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html