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:

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

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:

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!

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.97318051

11.7.40.94318051

116.4.29.46318051

124.9.42.64318051

132.17.21.71318051

17.4.2.11318051

2003:51:6012:110:0:0:a07:53318051

213.61.29.182318051

25.65.7.44318051

28.97.1.119318051

38.170.12.0318051

4.73.254.24318051

52.29.39.21318051

56.18.17.64318051

56.43.229.35318051

62.33.29.91318051

67.225.70.20318051

80.154.108.230318051

82.53.61.170318051

95.44.87.54318051

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.973392208

11.7.40.943392208

116.4.29.463392208

124.9.42.643392208

132.17.21.713392208

17.4.2.113392208

25.65.7.443392208

28.97.1.1193392208

38.170.12.03392208

4.73.254.243392208

52.29.39.213392208

56.18.17.643392208

56.43.229.353392208

62.33.29.913392208

67.225.70.213392208

82.53.61.1703392208

95.44.87.543392208

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?