Firewall flipping IPs for reverse DNS lookups resulting in incorrect FQDNs

I've run into a fun one.

As described by the title, I have a HA pair of TZ670's on 7.0.1-5095 that like to flip IP octets before performing reverse DNS lookups which subsequently results in incorrect FQDNs in the logs.

Example (sanitized) log entries:

time="2022-12-21 08:11:23" fw=173.64.X.X pri=5 c=0 m=1574 msg="Filename: versions.id" n=761440 src=192.168.3.123:52162:X3:123-3-168-192.sta.dodo.net.au dst=152.195.13.12:80:X1 srcMac=00:e0:4c:68:0e:11 dstMac=cc:e1:7f:a9:23:c2 proto=tcp/http rule="235 (RADIO->WAN)" fw_action="NA"

time="2022-12-21 08:11:23" fw=173.64.X.X pri=6 c=262144 m=98 msg="Connection Opened" app=49169 appName='General DNS' n=4586758 src=192.168.10.1:45836:X0:node-81s.pool-1-10.dynamic.totinternet.net dst=192.168.10.12:53:X0 dstMac=00:0c:29:59:d1:d4 proto=udp/dns sent=72 dpi=0 rule="Default Access Rule" fw_action="NA"

Note the src fields.

src=192.168.3.123:52162:X3:123-3-168-192.sta.dodo.net.au

src=192.168.10.1:45836:X0:node-81s.pool-1-10.dynamic.totinternet.net

These are RFC 1918 Private IP addresses being resolved to public FQDNs.

The firewall is configured with external DNS servers on its WAN ports, inherits the WAN settings for it's DNS (Network \ DNS \ Settings) and set to internal DNS for logs (Device \ Log \ Name Resolution).

A public PTR lookup against 192.168.3.123 doesn't resolve anything. A public PTR lookup against 123.3.168.192 resolves to 123-3-168-192.sta.dodo.net.au.

It's not even looking up it's own IP (192.168.10.1) correctly! A public PTR lookup against 1.10.168.192 resolves to node-81s.pool-1-10.dynamic.totinternet.net.

Again, this is set to internal DNS for logs.

I have a ticket open with support. This was occurring on the previous firmware version 5080 as well, but wasn't all the time.

Figured I'd make others aware of high strangeness.