This document describes the working of Domain Name System (DNS) on Cisco Adaptive Security Appliance (ASA) when Fully Qualified Domain Name (FDQN) objects are used. When multiple FQDN objects are configured on an ASA, an end-user trying to access any of the URLs defined in the FQDN objects would observe multiple DNS queries being sent by the ASA. This document aims to provide a better understanding of why such behavior is observed.
Cisco recommends that you have knowledge of Cisco ASA.
In order to elucidate the workings of the DNS when multiple FQDNs are configured on the ASA in a simulated production environment, an ASAv with one interface facing the internet and one interface connected to a PC device hosted on the ESXi server was setup. The ASAv interim code 9.8.4(10) was used for this simulation.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
The topology setup is shown here.
The client PC was configured with these IP, subnet mask, and name-servers for DNS resolution
On the ASA, two interfaces were configured, 1 inside interface with a security level of 100 to which the PC was connected and 1 outside interface having connectivity to the internet.
Here Gig0/1 interface is the outside interface with an interface IP of 10.197.223.9 and the Gig0/3 interface is the inside interface with an interface IP of 10.10.10.1 and connected to the PC on the other end.
Set up a capture on the ASA outside interface for capturing DNS traffic. Then from the client PC try accessing www.google.com from a browser.
What do you observe? Take a look at the packet capture.
Here we see that even though we tried to resolve only www.google.com, there are DNS queries being sent out for all of the FQDN objects.
Now take a look at how DNS caching works for IPs on the ASA to understand why this happens -
When www.google.com is typed in the client PCs web browser, the PC sends out a DNS query to get the URL resolved to an IP address.
The DNS server then resolves the PCs request and returns an IP stating that google.com resides at the specified location.
The PC then initiates a TCP connection to google.com's resolved IP address. However, when the packet reaches the ASA, it doesn't have an ACL rule stating that the specified IP is permitted or denied.
The ASA however knows that it has 4 FQDN objects and that any of the FQDN objects could possibly be resolved to the concerned IP.
Hence the ASA sends out DNS queries for all the FQDN objects as it doesn’t know which FQDN object may resolve to the concerned IP. (This is why there are multiple DNS queries being observed).
The DNS server resolves the FQDN objects with their corresponding IP addresses. The FQDN object should get resolved to the same public IP address as was resolved by the client. Otherwise, the ASA creates a dynamic access-list entry for a different IP address than the one that the client tries to reach, hence the ASA ends up dropping the packet. For Example, if the user resolved google.com to 203.0.113.1 and if the ASA resolves it to 203.0.113.2, the ASA creates a new dynamic access-list entry for 203.0.113.2 and the user are unable to access the website.
The next time when a request arrives, requesting resolution of a particular IP, if that particular IP is stored on the ASA it does not query all the FQDN objects again since a dynamic ACL entry would now be present.
If a client is concerned about the large number of DNS queries sent by ASA, increase the DNS timer expiry, provided end hosts tries to access the destination IP addresses which are there in the DNS cache. If the PC requests for an IP, not stored on the ASA DNS cache, DNS queries are sent out to resolve all the FQDN objects.
A possible workaround for this, should one want to still reduce the no. of DNS queries, would be to either reduce the no. of FQDN objects or to define the whole range of public IPs that you would be resolving the FQDN to, which however defeats the purpose of having an FQDN object in the first place. Cisco Firepower Threat Defense (FTD) is a better solution for handling this use case.
In order to verify which IPs are present in the ASAs DNS cache to which each of the FQDN objects get resolved to the command ASA# sh dns can be used.