Potential firewall performance issues when using FQDNs?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Potential firewall performance issues when using FQDNs?

L1 Bithead

I'm new to Palo Alto firewalls.  I'm setting up a PA-500 active/passive HA cluster, replacing an HA cluster of Sidewinder v7 (McAfee Firewall Enterprise) firewalls.  I know from many years of experience with that type of firewall and from talking to tech support that using network objects of the FQDN type (requiring DNS lookups) is a bad thing for firewall performance, and has even caused us major downtime in the past.  Is using FQDN objects in Palo Alto (PanOS 4.1.4) a similarly bad thing?  It must have to perform DNS lookups at some time, but this is also why they can be handy, so I don't have to try to keep IP addresses up-to-date in the firewall.

4 REPLIES 4

L6 Presenter

To my knowledge the dataplane of PA never uses FQDNs.

What happends is that the mgmtplane of the PA will perform dns lookups during commit in order to "convert" the FQDN into ip address before programming the asic/fpga.

In my opinion you should avoid using FQDNs.

You could of course name your network object to a FQDN but assign a static ip to this object.

The point is that imagine what would happen if someone tempers with your dns so it will resolve server.example.com into 0.0.0.0 (hopefully not that much unless you use something else than /32 as mask) but lets say the ip is suddently to some other protected server on the same zone?

I believe the IP address is determined at commit time.. and then again periodically according to the TTL of the DNS record. I wouldnt expect much of a performance hit.. though cant say I've tested with more then a handful of FQDN objects..

I would really hope the Palo Alto wouldnt be stupid enough to accept a 0.0.0.0 address for a FQDN object .. or infact anything other than a single host /32. (but that would definitely be worth checking)

Though I do acknowledge the general risk associated with relying on DNS for defining your access rules.

Also on a similar subject ..  I think the last time that I tested I'm pretty sure if there are multiple "A" records defined for a domain name the palo alto only uses the first one it gets.. which might throw a spanner in the works if there's any DNS based round robin/ loadbalancing going on. Yet again functionality worth verifying yourself with your current operating version of PAN OS .. as usual the documentation from PA on many things is lacking..

Would be great if someone from PA could put some light on this.

To me it sounds odd that the mgmtplane would autocommit based on some TTL in the network objects based on FQDN instead of ip addresses since the dataplane on its own lacks the necessary logic to do so (but I could be wrong Smiley Happy

Page 164 from "PA-4.1_Administrators_Guide"

FQDN:
To specify an address using the FQDN, select FQDN and enter the domain name.

The FQDN initially resolves at commit time. Entries are subsequently refreshed when the DNS time-to-live expires (or is close to expiring). The FQDN is resolved by the system DNS server or a DNS proxy object, if a proxy is configured. For information about DNS proxy, refer to “DNS Proxy” on page 125.

I agree there is definitely still some mystery around how the DNS to IP mapping is dynamically reprogrammed into the FPG's for the security rulebase to be able to process at high speed.. I'm guessing something similar to an automatic partial/selective commit.

  • 2795 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!