ASA FQDN access-list Part 2

My previous post focused on using access-lists that we based upon Fully Qualified Domain Names. This recently has posed a solution for some works that have been undertaken. Even though it might seem quite straight forward to implement – there are some considerations that need to be addressed before implementation.

DNS Time To Live

There are quite a few websites which we deal with daily that live behind a load balancer. This allows the provider to deliver resiliency to their service.  This also means they have low TTL times on DNS query answers. In the case of (my focus for work) this was 96 seconds.

Screen Shot 2013-08-13 at 8.32.37 PM

This time works rather well in my environment but I do need to consider CPU load on continuous polling. This is especially true if you are using something like Akamai or Facebook. These sites use 6 and 12 seconds respectively. This can cause quite a load upon your ASA.

Trust thy DNS

Now this should go without saying. Trust your DNS server. Your new rules are being made from DNS records. These DNS records resolve to IP addresses which are used to create access lists. If your DNS was compromised or poison you might actually be allowing in traffic that you aren’t expecting.

A low latency, trusted (internal) server is a great place to start.

I am not your URL filter

It is good to note that although this can permit or deny based upon FQDN it is not a URL filter mechanism. These are some reasons why you should not use it as a URL filter.

  • The FQDN access-list purely provides dynamic entries for ACLs.
  • Intermittent access based on low DNS TTL time + ASA TTL time.
  • Multiple host names for single IP address
  • Multiple names for a single site.

If you need URL filtering enable it through the features of the ASA or set up a proxy sever such as squid.

You might need to spend a little time with the packet captures identifying the average TTL for the sites you required. It is important that you are aware of the caveats and requirements before you implement this. The real benefits I feel are for the next generation of internet services  where IPv6 and DNS AAAA records are used though why not capitalise now!


ASA FQDN access-lists Part 1

A recent change came through which required a geo-spatial map data server from an isolated network to cache maps from various public entities. The geo-spatial database calls upon various websites.  The use of Bing, Google, government agencies, traffic management combine together to provide layered map data.  With a static source references a dynamic entity the need to look beyond IP addressed destinations was required.

The Fully Qualified Domain Name (FQDN) access-lists were introduced in 8.4(2) and allow name to ip resolution for access-lists. This post outlines what is required to perform DNS lookup to enable FQDN ACLs.

A DNS server is required to perform the lookup and resolve the FQDN.

dns domain-lookup inside
DNS server-group SG-CI-DNS
    domain-name <strong> </strong>

Now like any other object in the ASA we can reference the FQDN. This allows us to define the site in question.

object network

As you would reference an object normally on the ASA you can reference the This has the nested FQDN.

access-list acl-inside permit ip any object
access-list acl-inside deny ip any any

To check access-list hit counts and what is in an access-list normally you would issue a show access-list . When you use a FQDN ACL it is a little different.  This is a standard ASA access-list.

ASA5515X# sh access-list OLD-ACL
access-list OLD-ACL line 10 extended deny ip any (hitcnt=2314931)
access-list OLD-ACL line 11 extended permit ip any (hitcnt=29207)

This is a FQDN access-list. Notice the resolved addresses make entries themselves in the ACL.

ASA5515x# show access-list acl-inside
 access-list acl-inside line 1 permit ip any object 
 access-list acl-inside line 1 permit ip any fqdn (resolved) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=5810) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=3351) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=15) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=12) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=0) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=0) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=0) 
 access-list acl-inside line 1 permit ip any host ( (hitcnt=0) 
 access-list acl-inside line 2 deny ip any any (hitcnt=259428)

This has definitely helped in the business problem we had. Now we rely on DNS servers we do expose ourselves to DNS hijacking. Additional filtering can be applied to narrow ip any to the specified host to include port information. This tightens the vector of attack. The next part looks at DNS packet information and tweaking FQDN resolution for look up improvement.