DNSproxy resolve fail msgs - only I am not using this feature!

[craiglunt]

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?

[dbjohnson]

Did this begin after an 8.1.0 update ?

[craiglunt]

Actually - Yes - known bug?

[BPry]

@craiglunt,

You could be running into PAN-92972

[craiglunt]

Can't seem to find a reference to that issue anywhere. can you elucidate? Thanks

---

@BPry wrote:

@craiglunt,

You could be running into PAN-92972

---

[BPry]

@craiglunt,

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. 

[dbjohnson]

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.

[craiglunt]

This seems to have stopped for me - (at least temporarily). not sure why ... will continue to check as I do not like inconsistencies - especially in a fw and more so when it involves dns.

[LCMember3055]

I'm seeing a lot of these too after 8.1

i can ping the dns name from the panos cli... not sure

Failed to resolve domain name:ad1.our.internal after trying all attempts to name server(s): internal.dns.ip.address 8.8.8.8

[BPry]

@LCMember3055,

8.1 is really where I started to pay attention to them simply because I'm seeing it come across a lot more in the logs. I passed the information back to TAC and haven't really heard anything outside of the fact that they are still investigating the issue. 

[craiglunt · Accepted solution]

 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

[meyer37]

I actually created a support ticket for this issue.  8.1 was when I first saw the issue as well.  I have been told that this is a know bug with 8.1 and it will be addressed with 8.1.1.  8.1.1 should be available around May 3rd.  Here is the bug id for this issue:

PAN-94640