3 reasons why I would like to have DNS lookups in IOS access lists

When I chose the word “unfortunately” in my post describing how Cisco IOS performs DNS lookup when you enter a host name in an access list, I’ve triggered several responses that disagreed with my choice of words. Here’s why I still think IOS ACL could be improved with dynamic DNS lookup:

  • Things change. If you have to match a specific host in your ACL, there’s no guarantee that the host’s IP address will stay the same indefinitely. If the host is within your network and your ACL breaks because the host’s IP address was changed, it’s your problem (you should have kept better documentation and implemented proper change management procedures). When you have to use an external IP address (for example, the ISP’s SMTP gateway), you’ll notice it has changed when the phones start to ring.
  • Self-documentation. If the hostnames would remain in the ACLs and the router would perform a lookup as needed, the access lists would be self-documenting. When the hostnames get replaced by IP addresses, you have to perform reverse lookup manually to figure out what host the IP address is referring to.

You could use remark commands in access-lists to document what you’re doing. Although you can use multiple remark commands in the same ACL, they cannot be edited like the filtering lines in the ACL.

  • Reverse lookup problems. The IP address entered in the ACL does not necessarily translate back into the host name you’ve used. In some cases (hosted applications), the reverse lookup might give you a host name in a completely different domain, making your deciphering job even harder (assuming, of course, that your predecessor left no documentation behind).

There are, of course, numerous minor issues that would need to be addressed, for example:

  • Load balancing. Properly implemented DNS-based load balancers return numerous randomly mixed IP addresses as a response to the A query. The IOS could convert multiple returned addresses into a network object group automatically.
  • TTL issues. In most cases, the DNS zone files contain meaningful TTL values (the IP addresses stay valid for minutes or hours). Even if the router performed the DNS lookup for every packet (which would be total nonsense), it would usually get the same results on every query due to a cache somewhere in the chain between the router and the final DNS server. The DNS lookup thus only makes sense when the DNS A record expires.
  • Short TTL issues. Sometimes the responses returned by the DNS server contain very low TTL values (TTL might also be set to zero to disable caching). In these cases, IOS could provide a minimum TTL parameter and warn the operator when a hostname is used that results in a response with TTL below the threshold.

In any case, the saddest part of the story is that the IOS already supports the same functionality in a different part of the code: dynamic DNS lookups are used in zone-based firewall policies to identify masquerading applications like MSN and Yahoo messenger (see Chapter 5 of the Deploying Zone-Based Firewalls digital book).

2 comments:

  1. 1 reason why you should never use dns hostnames in a firewall policy.

    This gives attackers control over your policies. DNS is insecure. Attackers can manipulate DNS in a number of ways. If this summer's DNS snafu didn't teach us that, I don't know what will.

    ReplyDelete
  2. @Anonymous: while I completely agree with you, I would still like to have an option to choose ... or have no option to enter a host name at all.

    In low-security environments, the capability to adapt to changes in external networks (which is what DNS is all about) might be more important than the perfect filtering. You might want to read the posts I've linked to (for example, this one) to understand the whole context.

    And just in case someone would try to mis-understand me: I would never use a dynamic DNS-resolved IP address in a reasonably secure firewall.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.