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):
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:
weberjoh@pa> request system fqdn show
FQDN Table : Last Request time Fri Aug 26 11:07:15 2016
--------------------------------------------------------------------------------
IP Address Remaining TTL Secs Since Refreshed
--------------------------------------------------------------------------------
VSYS : vsys1 (using mgmt-obj dnsproxy object)
16a.weberdns.de (Objectname h_fqdn_16a.weberdns.de):
192.0.2.1 2048 1552
192.0.2.10 2048 1552
192.0.2.11 2048 1552
192.0.2.12 2048 1552
192.0.2.13 2048 1552
192.0.2.14 2048 1552
192.0.2.15 2048 1552
192.0.2.16 2048 1552
192.0.2.2 2048 1552
192.0.2.3 2048 1552
192.0.2.4 2048 1552
192.0.2.5 2048 1552
192.0.2.6 2048 1552
192.0.2.7 2048 1552
192.0.2.8 2048 1552
192.0.2.9 2048 1552
16aaaa.weberdns.de (Objectname h_fqdn_16aaaa.weberdns.de):
2001:db8:0:0:0:0:0:1 2048 1552
2001:db8:0:0:0:0:0:10 2048 1552
2001:db8:0:0:0:0:0:11 2048 1552
2001:db8:0:0:0:0:0:12 2048 1552
2001:db8:0:0:0:0:0:13 2048 1552
2001:db8:0:0:0:0:0:14 2048 1552
2001:db8:0:0:0:0:0:15 2048 1552
2001:db8:0:0:0:0:0:16 2048 1552
2001:db8:0:0:0:0:0:2 2048 1552
2001:db8:0:0:0:0:0:3 2048 1552
2001:db8:0:0:0:0:0:4 2048 1552
2001:db8:0:0:0:0:0:5 2048 1552
2001:db8:0:0:0:0:0:6 2048 1552
2001:db8:0:0:0:0:0:7 2048 1552
2001:db8:0:0:0:0:0:8 2048 1552
2001:db8:0:0:0:0:0:9 2048 1552
16dual.weberdns.de (Objectname h_fqdn_16dual.weberdns.de):
192.0.2.1 2048 1552
192.0.2.10 2048 1552
192.0.2.11 2048 1552
192.0.2.12 2048 1552
192.0.2.13 2048 1552
192.0.2.14 2048 1552
192.0.2.15 2048 1552
192.0.2.16 2048 1552
192.0.2.2 2048 1552
192.0.2.3 2048 1552
192.0.2.4 2048 1552
192.0.2.5 2048 1552
192.0.2.6 2048 1552
192.0.2.7 2048 1552
192.0.2.8 2048 1552
192.0.2.9 2048 1552
2001:db8:0:0:0:0:0:1 2048 1552
2001:db8:0:0:0:0:0:10 2048 1552
2001:db8:0:0:0:0:0:11 2048 1552
2001:db8:0:0:0:0:0:12 2048 1552
2001:db8:0:0:0:0:0:13 2048 1552
2001:db8:0:0:0:0:0:14 2048 1552
2001:db8:0:0:0:0:0:15 2048 1552
2001:db8:0:0:0:0:0:16 2048 1552
2001:db8:0:0:0:0:0:2 2048 1552
2001:db8:0:0:0:0:0:3 2048 1552
2001:db8:0:0:0:0:0:4 2048 1552
2001:db8:0:0:0:0:0:5 2048 1552
2001:db8:0:0:0:0:0:6 2048 1552
2001:db8:0:0:0:0:0:7 2048 1552
2001:db8:0:0:0:0:0:8 2048 1552
2001:db8:0:0:0:0:0:9 2048 1552
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:
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.
weberjoh@pa> request system fqdn show
FQDN Table : Last Request time Fri Aug 26 11:38:37 2016
--------------------------------------------------------------------------------
IP Address Remaining TTL Secs Since Refreshed
--------------------------------------------------------------------------------
VSYS : vsys1 (using mgmt-obj dnsproxy object)
32a.weberdns.de (Objectname h_fqdn_32a.weberdns.de):
192.0.2.1 2025 807
192.0.2.10 2025 807
192.0.2.11 2025 807
192.0.2.13 2025 807
192.0.2.14 2025 807
192.0.2.15 2025 807
192.0.2.16 2025 807
192.0.2.17 2025 807
192.0.2.18 2025 807
192.0.2.19 2025 807
192.0.2.20 2025 807
192.0.2.21 2025 807
192.0.2.22 2025 807
192.0.2.23 2025 807
192.0.2.24 2025 807
192.0.2.25 2025 807
192.0.2.27 2025 807
192.0.2.28 2025 807
192.0.2.29 2025 807
192.0.2.3 2025 807
192.0.2.30 2025 807
192.0.2.31 2025 807
192.0.2.32 2025 807
192.0.2.4 2025 807
192.0.2.5 2025 807
192.0.2.6 2025 807
192.0.2.7 2025 807
192.0.2.8 2025 807
192.0.2.9 2025 807
32aaaa.weberdns.de (Objectname h_fqdn_32aaaa.weberdns.de):
2001:db8:0:0:0:0:0:12 2025 807
2001:db8:0:0:0:0:0:13 2025 807
2001:db8:0:0:0:0:0:14 2025 807
2001:db8:0:0:0:0:0:15 2025 807
2001:db8:0:0:0:0:0:17 2025 807
2001:db8:0:0:0:0:0:18 2025 807
2001:db8:0:0:0:0:0:19 2025 807
2001:db8:0:0:0:0:0:20 2025 807
2001:db8:0:0:0:0:0:24 2025 807
2001:db8:0:0:0:0:0:26 2025 807
2001:db8:0:0:0:0:0:28 2025 807
2001:db8:0:0:0:0:0:29 2025 807
2001:db8:0:0:0:0:0:3 2025 807
2001:db8:0:0:0:0:0:30 2025 807
2001:db8:0:0:0:0:0:4 2025 807
2001:db8:0:0:0:0:0:7 2025 807
2001:db8:0:0:0:0:0:9 2025 807
32dual-long.weberdns.de (Objectname h_fqdn_32dual-long.weberdns.de):
Not used
32dual.weberdns.de (Objectname h_fqdn_32dual.weberdns.de):
Not usedI 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!
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 usedAfter 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!
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 51After 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:
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
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?