About address object with FQDN and apply it to security policy.

[neilwu]

If I have a FQDN "abc.com" that have two DNS records 10.0.0.1 and 10.0.0.2.

Then I create a  address object with FQDN type, and the value is "abc.com"

When I use this object into security policy, how does it working? Does it become 10.0.0.1 or 10.0.0.2 ? or it will randomize according to catch?

If a client connect to "abc.com", and the client's DNS (Ex. F5 GTM) resolve this FQDN become 10.0.0.1.

but in the security policy, the PaloAlto Firewall says "abc.com" is 10.0.0.2.

I think that would be a problem because sometimes it can match the rule and sometimes doesn't.

My purpose is if I use address object with FQDN then PaloAlto Firewall can resolve all about this FQDN's IP address, and apply to rule dynamically.

If the address object with FQDN always just can resolve one IP address, I think It should not be use. doesn't it?

[hshah]

Hi Neilwu,

We can resolve upto 10 IPs per FQDN and keep in security policy. Make sure your DNS server resolve FQDN to all IP addresses, than and than its possible.

Refer following thread for more details.

FQDN address object resolution (multiple IP's)

Regards,

Hardik Shah

[bat]

Hi neilwu

Do you see the IP address for which it is not working in the running security policy ? You can verify that through CLI:

show running security-policy | match 10.0.0.1

show running security-policy | match 10.0.0.2

Thanks

[mivaldi · Accepted solution]

The definitive answer depends on what the DNS query responds and if the servers themselves change their IP (or there is more than one server always-listening and DNS is being used as a load-balancing technique).

I've experienced a scenario where a FQDN was being used in a security policy, and the destination host was changing its IP address to a pool of 3 IP addresses in a round-robin fashion. The DNS record was also dynamically updated to reflect the newly assigned IP on its non-authoritative section.

The Palo Alto Networks firewall does not run a DNS resolution on the fly for every SYN packet that goes out if a FQDN is used in a security policy, thus causing a practical problem. As you described " sometimes it can match the rule and sometimes doesn't."

There is a set frequency in which the firewall will resolve a FQDN and run a short commit to update the resulting security policy. The firewall is matching IP addresses and if a FQDN is used in the security policy, it will not work well with frequently changing records.

For cloud FQDN's there are different approaches.

The DNS records may rotate pointing to new IP's (like Facebook does):

computer$ nslookup www.facebook.com

Server: <obscured>

Address: <obscured>#53

Non-authoritative answer:

www.facebook.com canonical name = star.c10r.facebook.com.

Name: star.c10r.facebook.com

Address: 69.171.237.20

Or another approach is to give you a long list of possible addresses (like Google does):

computer$ nslookup www.google.com

Server: <obscured>

Address: <obscured>#53

Non-authoritative answer:

Name: www.google.com

Address: 74.125.239.49

Name: www.google.com

Address: 74.125.239.48

Name: www.google.com

Address: 74.125.239.51

Name: www.google.com

Address: 74.125.239.52

Name: www.google.com

Address: 74.125.239.50

... When you have a long list of possible IP's, the Palo Alto Networks firewall will cache up to 10 IP addresses presented in the Non-authoritative section of the DNS query response. This does not mean that it will cache those IP's for a round-robin rotating DNS record.

Hope this helps,

Mariano Ivaldi

[neilwu]

Thank you Mariano.

Your description is very helpful for me.

[Flang3r]

Bumping and old thread here, but is there any practical approach to this round-robin resolving discrepancy between host and firewall?

I have several FQDN-s to which internal host has to communicate to and facing exactly the same problem. IP address resolved by the client host differs from one present in firewall's cache at that time and security rule fails. I would configure all those load balanced IP addresses statically, but they get changed faster than the diapers on newborns 😞