I'm getting system log errors that state " failed to resolve domain... etc" and lists the dnsproxy as the type and resolve-fail as the event. This is all really cool - but I have NOT set DNS proxy up - ever. If I dig through the logs - I can see a time where "Dnsproxy object:mgmt-obj was enabled" - however I do not know why it would state so as I can find no config changes made that would correleate and and my current running config shows no DNS proxy's have been set up ( enabled or otherwise).
Anyone else seen this?
I think I figured this out.
There is a default internal dns-proxy object called mgmt-obj that works to resolve hostnames when you check the "resolve hostname" checkbox in the various monitor logs. To do this it does a reverse dns lookup using the arpa database - and sends a dns query for a pointer record of the domain name.
ie - if one of your devices/apps was reaching out to a.b.c.d and your "monitor traffic" gui pane had the resolve hostname checkbox enabled - to facilitate this, the PA device would send out a dns query for a pointer record of the domain name d.c.b.a.in-addr.arpa to your specified dns servers. If this resolve fails ... it logs it in the system log as type: dnsproxy, severity: informational, event: resolve-fail, object: mgmt-obj and provides a description of the failed reverse lookup attempt
Actually I just re-read what you intially posted, ignore the bug-id I presented (I'm not sure it's public yet, and I'm not sure if I could give you the description if it isn't seeing as I found it on a walled off resource).
It's actually normal to see system events with a subtype of dnsproxy, pretty much everyone should be seeing them if they look for it. Regardless of the dns-proxy configuration the dameon is used internally by the firewall for different dns functions. I know that panagent had wrote something about it that I'll try to find again, unfortuantely I haven't seen anything posted by them in while so I'm not sure they are still active to expand on it at all.
I have a few devices upgraded to 8.1
Prior to the upgrade - we would get the resolve error on some FQDN object entries blocked, but this was due to dead domains.
After upgrading to 8.1, the errors started due to Server Monitor entries, for network addresses input as FQDN. We do not run DNS proxy profiles on our appliances either, but did attempt doing so to see if the problem would resolve. Having the DNS proxy, rather than global DNS for the mgmt interface, did not make a difference.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!