Palo Alto FQDN Objects

While I tested the FQDN objects with a Palo Alto Networks firewall, I ran into some strange behaviours which I could not reproduce, but have documented them. I furthermore tested the usage of FQDN objects with more than 32 IP addresses, which are the maximum that are supported due to the official Palo Alto documentation. Here we go:

Some Notes

I am using a Palo Alto PA-200 with PAN-OS 7.1.4-h2. A description of how to use the FQDN objects by Palo Alto Networks is this “How to Configure and Test FQDN Objects” article. To show and refresh them via the CLI, these commands can be used (refer to my list of CLI troubleshooting commands):

Note that at least one policy must use an FQDN object to be queried by the firewall. Otherwise, it won’t be resolved at all.

The release notes from PAN-OS 7.1 state: “Issue ID 98576: In PAN-OS 7.1 and later releases, the maximum number of address objects you can resolve for an FQDN is increased from 10 of each address type (IPv4 and IPv6) to a maximum of 32 each. However, the combination of IPv4 and IPv6 addresses cannot exceed 512B; if it does, addresses that are not included in the first 512B are dropped and not resolved.”

In oder to test different scenarios, I generated the following FQDNs on my DNS server. The names are almost self-explanatory. I am using the documentation prefixes for both, IPv4 (RFC 5737) and IPv6 (RFC 3849):

  • 16a.weberdns.de
  • 16aaaa.weberdns.de
  • 16dual.weberdns.de
  • 32a.weberdns.de
  • 32aaaa.weberdns.de
  • 32dual.weberdns.de
  • 32dual-long.weberdns.de <- with full random IP addresses that are long, i.e., no :: abbreviations for IPv6
  • 64a.weberdns.de
  • 64aaaa.weberdns.de
  • 64dual.weberdns.de

Online tools such as DNSWatch can be used to query the DNS names.

Tests

I added a few security policies in order to use the FQDN objects.

16 – no problem

The objects with the 16x address were no problem. Neither the A, AAAA, nor the dual ones:

32 – the problems began

As expected, some problems arose when I used the 32x FQDN objects. But not only within the objects, but with the whole Palo Alto. After the commit, the GUI displayed a “not ready” and logged me out after a few seconds,

Palo Alto FQDN Objects device not ready

while the CLI session ended, too. After a re-login, it displayed a “system initializing” message:

Hm. A bit strange. After a re-login I listed the FQDN objects via the CLI. While the 32a object was ok, the 32aaaa was missing some entries (probably due to the longer as 512 byte DNS answer), while the 32dual and 32dual-long were displayed as “Not used” while they were definitely used. That is, I suppose that there is still a bug within the handling of multiple records from a single FQDN name.

I made a second try with only the 32dual-long object (while I disabled all other rules containing my test FQDN objects). The management plane restarted again and logged me out, too. Furthermore, the object was still listed as “Not used” while the other (disabled!) objects were still listed, even after a manual refresh!

After these results I decided to not even test the 64x objects. ;)

What Was That?

Another strange behaviour was this test case: Before I used the 16x and 32x objects, I simply created a domain name called “many.weberdns.de” with 17x A records. But after a first usage, the following records were listed by the CLI. The strange parts are the lines 9, 10, and 20, because these are my DNS servers IP addresses that are definitely not part of the “many.weberdns.de” domain name!

After some more commits this FQDN object was listed correctly and I was not able to reproduce this behaviour. However, it looked not that reliable. Here it is without any wrong entries:

Conclusion

Let’s first notice that the limitation of 10 IP addresses is not present anymore, which is good. At least 16 IP address objects worked without any problems. Even the 32 A records worked. But all other objects, e.g., 32 AAAA records or even more, are not just “not working” but forced a restart (?) of the management plane. Uh. I am not fully sure whether this is related to my small hardware (PA-200), or to some other side effects such as DNS proxies configured on the Palo, etc. Maybe someone has similar experiences?

Featured image “Bunte Steine 313/366” by Dennis Skley is licensed under CC BY-ND 2.0.

3 thoughts on “Palo Alto FQDN Objects

  1. I have the exact same experiences and elements on my PA-200 going on. No work-around yet other than forcing a restart of the MGT plane quite often :-(

  2. Hi,

    Great of you to share this. Might be a potential availability issue…
    Have you logged a ‘case’ with PA? How does PA react to these findings?

    1. No, as far as I remember I have not opened a case. (Otherwise I would have written something here.) I tested the FQDN objects for a customer that needed about 8-10 IP addresses per object. This was working.
      I ran into those issues in my lab, so I did not open a case, because they always refer to “which customer is having the issue”? Lab cases are not of intereset at all from the vendors perspective. ;(

Leave a Reply

Your email address will not be published. Required fields are marked *