Routing & Security

DNS Re-Write (DNS Doctoring) on the Cisco ASA

Refer to the following topology

Scenario

Host1 on the inside network and Host4 on the DMZ network use name-server 136.1.122.2 (Host2), which is located on the outside network, to resolve DNS queries. Both hosts are trying to reach DMZ Host3 by name. They send a DNS resolution request to Host2 server for Host3. Host2 responds to the request with the IP address 136.1.122.50. They receive the response and try to connect to Host3 but are unsuccessful. What can be done so that the DNS record stays as is on Host2 and both Host1 and Host4 can reach Host3 by name.

Discussion

Well, now that we know the problem, what can we do to fix it? In regards to the ASA, we have a few options. The ASA has two commands to rewrite the DNS record. These are the alias and static commands. The alias command is legacy compared to the static command. Another option we have that does not re-write the DNS record is hair-pinning along with dynamic NAT (DNAT). So we will setup this scenario and configure the devices without any of these mentioned solutions. We will then implement each of the 3 proposed solutions mentioned to see if they resolve the issue. We will then discuss different ways of securing these solutions. First, let’s discuss each solution in detail for better understanding.

ASA Configuration

Ok, let’s configure the ASA so we can get connectivity to the devices within our lab. Let’s implement NAT, allow ICMP, and test connectivity. The ASA has a default configuration after the wr erase command was issued.

asa(config)#nat (inside) 1 0 0
asa(config)#nat (dmz) 1 0 0
asa(config)#global (outside) 1 interface
asa(config)#global (dmz) 1 interface
asa(config)#policy-map global_policy
asa (config-pmap)# class inspection_default
asa (config-pmap-c)# inspect icmp

Now let’s test connectivity
Host1#ping 136.1.122.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Host1#ping 10.0.0.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Host4#ping 136.1.122.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Ok, it appears that we have reachability throughout the network.
Now let’s try to ping host3 with the name of host3 from host4

host4#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Now let’s try to ping host3 with the name of host3 from host1

host1#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

We now know that we need to implement one of the solutions mentioned earlier.

Alias Command Solution

1)      Alias command (This command has 2 functions)

First Function – DNS Doctoring – performs DNS re-writes
Second Function – Destination NAT – changes destination IP address to another address

First, let’s fix Host4 so it can access Host3. Let’s use the alias command:

asa(config)#alias (dmz) 10.0.0.100 136.1.122.50 255.255.255.255

This alias command also creates a proxyarp entry in the ASA. We should disable this for DNS Doctoring purposes using the following command

asa(config)#sysopt noproxyarp dmz

Now let’s try our same ping test as earlier; host4 will try and ping host3 by name

host4#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

We can see that the alias performed the DNS re-write as host3 is now resolved to 10.0.0.100. We can successfully ping host3 from host4 now. This is great.

Now, what about host1? Lets implement the same alias command but this time apply it to the inside interface and turn off the proxyarp.

asa(config)#alias (inside) 10.0.0.100 136.1.122.50 255.255.255.255
asa(config)#sysopt noproxyarp inside

And let’s try our ping from host1 to the name host3

Host1#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100 timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Well, we can see that host3 resolves to 10.0.0.100 but we don’t have reachability to the device. Hmmm… that is strange. Many people I have run across say that it is because we don’t allow ICMP from DMZ. But how can this be as we are inspecting ICMP globally within the ASA and we had reachability before implementing the alias command. Well, we have actually implemented DNS Doctoring on an interface that the host we are trying to reach is not located on. That is the only difference between the dmz and inside, right? The DNS changes but we have no reachability. Mission failed….

Well, believe it or not, if you want reachability, we cannot use DNS Doctoring with the alias command. Instead, we have to use destination NAT with the alias command. We need to swap around the addresses within the alias command. Let’s try it out and see what happens.

asa(config)#alias (inside) 136.1.122.50 10.0.0.100 255.255.255.255

Let’s see how this works.

Host1#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Success, mission accomplished. Even though we don’t doctor the DNS as we see that host3 resolves to 136.1.122.50. It may not be the record that we expect but we do have full reachability to the device.

Although, the alias command is deprecated since version 7 code to the static command, it can still be used as a solution if desired.  It just has to be correctly implemented. The alias command acts like a half functioning static command.

Let’s remove the alias and sysopt commands we issued earlier before proceeding to the next solution, using the static command

asa(config)#no alias (dmz) 10.0.0.100 136.1.122.50 255.255.255.255
asa(config)#no alias (inside) 136.1.122.50 10.0.0.100 255.255.255.255
asa(config)#no sysopt noproxyarp dmz
asa(config)#no sysopt noproxyarp inside

Static with DNS Command Solution

2)      DNS re-write using Static command.

The static command with the DNS keyword performs DNS doctoring. This is by far the best method to make our configuration work. Please note that DNS inspection must be enabled within the Modular Policy Framework. So, using the same scenario earlier, let’s try the static command with the keyword DNS.

asa(config)#static (dmz,outside) 136.1.122.50 10.0.0.100 netmask 255.255.255.255 dns

Let’s perform our ping tests from host4 within the DMZ network.

host4#ping host3

Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

The static command with DNS re-write works fine for the DMZ. Let’s try host1 on the inside network.

Host1#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Looking at the result above, the static command works for the host1 dns re-write resolution as well. The MPF re-writes the DNS entry with relation to the static command entry used. This one line command is the recommended solution to this DNS issue.

Let’s remove the alias and sysopt commands we issued earlier before proceeding to the next solution

asa(config)#no static (dmz,outside) 136.1.122.50 10.0.0.100 netmask 255.255.255.255 dns

ASA HairPinning  Solution

3)      Hairpinning traffic with DNAT.

So to start off with, this solution actually does no DNS re-writes. Basically what this solution does is use NAT technology for the traffic flow from querieng host to the host in the DNS reply message (so from host1 to host3)

Prior to code that introduced hairpinning using the same-security-traffic permit intra-interface command, the firewall could not send out traffic on the same interface that it originally came from. The traffic had to flow through the PIX from one interface to another. The same-security-traffic permit intra-interface allows traffic to flow out the same interface in which it was received. So let’s setup the configuration on the ASA to determine what happens.

First, we will configure the ASA to fix the reachability in the inside network. Note that since our traffic should still be flowing through the firewall interfaces, we should not need the same-security-traffic permit intra-interface command as of yet. So we will have change the source and destination addresses via NAT to accomplish this task. Remember, the source IP address is changed with the nat and global command. The destination IP will be changed by the static command.

Let’s start off this test by trying to ping host3 from host1

Host1#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50 timeout is 2 seconds:
…..

Now let’s add configuration using NAT solutions only to see if we can make this work

asa(config)#static (dmz,inside) 136.1.122.50 10.0.0.100

And let’s try to ping host3 again from host1

Host1#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Ok, we now have reachability there. You can see that the host is still at 136.1.122.50 and that DNS re-write is not performed here.

Let’s try to ping the host directly and see what happens

Host1#ping 10.0.0.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100 timeout is 2 seconds:
…..

Due to the static NAT translation, if we want to access the device, we will have to use 136.1.122.50 now.

Now let’s try to reach host3 from host4 in the dmz network by name

Host4#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50 timeout is 2 seconds:
…..

As we can see, we will need to implement a solution here for host4 to reach host3 by name. Let’s configure the ASA a little more.

asa(config)#static (dmz,dmz) 136.1.122.50 10.0.0.100

Let’s try our reachability test.

Host4#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50 timeout is 2 seconds:
…..

Still the same issue. We will install the hairpinning feature now.

asa(config)# same-security-traffic permit intra-interface

Host4#ping host3
Translating “host3″…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.50 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

We can see that by permitting traffic back out the same interface in which it was learned that we can solve the issue with NAT only.

So we have 2 solutions utilizing DNS re-write and one by using NAT along with hairpinning the traffic. So what if we want to turn off DNS re-write. Well, one way we can disable it for both the alias and static commands is to use MPF. We can choose not to inspect dns within the global policy, or we can create our own policy-map with dns inspection with the dns inspection not doing re-write.

If we are using the alias command we also have the command “sysopt nodnsalias (inbound|outbound)”. The inbound flag means that the direction is from a lower security level to a higher security level. The outbound flag is the opposite of the inbound flag, from a higher security level to a lower security level.

Conclusion

Within a topology that is comparable to the one being dissected in this paper, we can see that there are several options to fix DNS infrastructure that is disjoint from hosts around our network domain. Two of these fixes utilize the ASA’s modular policy framework to re-write DNS records. The other solution uses the ASA’s hairpinning feature along with NAT technologies. We also discussed ways to secure the alias command and how to disable DNS re-writes using the MPF functionality. I hope this provides useful to your lab preparation or in real world scenarios.