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):

1 2	request system fqdn show request system fqdn refresh

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:

Click To Expand Code

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,

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

1 2 3

Using username "weberjoh". Last login: Wed Aug 24 11:32:17 2016 from p20030050aa0082001494745f15bf1c6c.dip0.t-ipconnect.de System initializing; please wait... (CTRL-C to bypass)

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.

Click To Expand Code

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!

1 2 3 4 5 6 7 8 9 10 11

weberjoh@pa> request system fqdn show   FQDN Table : Last Request time Fri Aug 26 12:10:15 2016 --------------------------------------------------------------------------------                       IP Address     Remaining TTL     Secs Since Refreshed -------------------------------------------------------------------------------- VSYS  : vsys1 (using mgmt-obj dnsproxy object)   32dual-long.weberdns.de  (Objectname h_fqdn_32dual-long.weberdns.de):                           Not used

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!

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

many.weberdns.de  (Objectname h_fqdn_many.weberdns.de):                        11.31.62.97              3180                       51                       11.7.40.94              3180                       51                      116.4.29.46              3180                       51                      124.9.42.64              3180                       51                     132.17.21.71              3180                       51                        17.4.2.11              3180                       51      2003:51:6012:110:0:0:a07:53              3180                       51                    213.61.29.182              3180                       51                       25.65.7.44              3180                       51                      28.97.1.119              3180                       51                      38.170.12.0              3180                       51                      4.73.254.24              3180                       51                      52.29.39.21              3180                       51                      56.18.17.64              3180                       51                     56.43.229.35              3180                       51                      62.33.29.91              3180                       51                     67.225.70.20              3180                       51                   80.154.108.230              3180                       51                     82.53.61.170              3180                       51                      95.44.87.54              3180                       51

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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

many.weberdns.de  (Objectname h_fqdn_many.weberdns.de):                        11.31.62.97              3392                      208                       11.7.40.94              3392                      208                      116.4.29.46              3392                      208                      124.9.42.64              3392                      208                     132.17.21.71              3392                      208                        17.4.2.11              3392                      208                       25.65.7.44              3392                      208                      28.97.1.119              3392                      208                      38.170.12.0              3392                      208                      4.73.254.24              3392                      208                      52.29.39.21              3392                      208                      56.18.17.64              3392                      208                     56.43.229.35              3392                      208                      62.33.29.91              3392                      208                     67.225.70.21              3392                      208                     82.53.61.170              3392                      208                      95.44.87.54              3392                      208