Name resolution takes too long, diskable name for report [report name]

[hyperwookiee]

Hi! We just finished deploying the PA-5260 running PAN-OS 8.0.10 at our edge. Everything works well so far, but we see the log message below in Monitory->Logs->System:

Name resolution takes too long, diskable name for report [report name]

The type is general and severity is informational, but we are also not passing a lot of traffic at the moment because it's a Sunday. Primary DNS is set to our internal DNS server and 8.8.8.8 for secondary.  Anbody got this message before and what did you do to resolve it? Thank you.

[BPry]

@hyperwookiee,

Are you sure the message actually has to do with DNS at all? I'm assuming that the report in question is a custom or a predefined report that you are trying to run. Have you verified that you can actually resolve any FQDNs on the firewall just to verify that you aren't running into a security policy or service routing issue? 

[hyperwookiee]

Because of the wording of the log message, I'm assuming it has something to do with DNS. I can resolve FQDNs on the firewall:

> request resolve address www.google.com

172.217.12.68
2607:f8b0:4000:816::2004

[bhelman]

Have you been able to resolve this?  I've pretty much ignored it for months on my systems.  I just upgraded to 8.1.3 and, at least, they fixed the "diskable" typo, but I'm still getting the warning.  I cannot find the reports it is flagging .. even searching the XML configuration code.

[sziade1]

Palo's support was not very helpful when I opened a TAC case. Decided it wasn't worth the effort so I gave up..

[BPry]

@bhelman,

So just so I'm clear on what we're talking about, these are 'informational' logs that you are recieving within the System logs yes. By default you should be getting these logs whenever the firewall runs its predefined scheduled report, which unless you modify it would be around '02:00' or sometime shortly after.  

What you are seeing is due to the automatic summary generation and the fact that the firewall will attempt to resolve any address that is generated in the report; these alerts are triggered whenever it can't successfully resolve those IPs to a FQDN for whatever reason. The reason that you aren't seeing them within the XML is because it's a default statement, and therefore hidden from you by default unless you dive into the technical_support files. 

If you are not using these reports and no longer wish to receive these alerts, you can perform the following Action. 

Device -> Setup -> Management -> Logging and Reporting Settings ->

Within the popup you'll find a tab for 'Pre-Defined Reports' with an option to 'Deselect All'. Doing so will cause the firewall to no longer run the predefined reports as scheduled, and therefore you will see these alerts disappear unless you run a custom report that runs into the same issue. 

[bhelman]

Yikes.

So I've noticed something on my systems.  When I issue a "request resolve address <address>" command, any system that can respond with an IPv6 address returns a value immediately.  Any system that can only respond with an IPv4 address takes ~9 seconds to return the information.  I'm looking in to that now.

[bhelman]

I'm seeing the error within the System Log widget on the dashboard.  It's fine to turn it off, but the fact that I'm getting an error makes me think I have another issue.

Is there a way to tell which interface on the PAN is being used to query DNS?  Our internal DNS happen to be on segments directly connected to the PAN's, but I'm not seeing the traffic in the logs (from that PAN interface).  It's going to take me a while to go through all of the interfaces to see which one is being used.  I also checked for the management interface .. also not in the logs (for application dns).

[BPry]

@bhelman,

The system log widget on the dashboard will show you the last x number of entries within that log database. What you should be slightly more concerned with on System logs are the severity level, as the firewall generates a lot of informational logs that most administrators can safetly ignore. This would be one of those logs; you don't expect everything within the predefined reports to even have a DNS entry, so this event is expected to trigger when these reports are ran. 

The firewall will utilize the management interface unless you have specified a service route when querying DNS. The management interface is out-of-band and you won't see any firewall logs unless this traffic needs to route through the firewall for some reason. So in my enviroment for example the management interface is attached to an access port on the switch, but the gateway for that VLAN rests on the firewall itself. I could then expect to see this traffic. If that isn't how your enviroment is setup there is no guarentee that the management port traffic would ever cross the firewall so that it would actually get logged.