SOLVED

Odd Windows 2012 R2 DNS requests

Copper Contributor

So I have regular Cisco OpenDNS Umbrella rejections for malware-related DNS requests logged. From what I can tell these rejections are coming from our internal AD DNS Server. It has Umbrella DNS defined for DNS resolution of Internet-based domain names.

 

When I look at the DNS audit logs, I don't see the initial Event ID 256 - LOOK_UP QUERY_RECEIVED for these rejections. If I did I would then see the internal source (i.e. - Source=x.x.x.x) and could investigate further. The first activity I see is always Event ID 260 - RECURSE_QUERY RECURSE_QUERY_OUT, which is the local AD DNS Server querying out to Umbrella to resolve the malicious QNAME's.

 

Does this mean that the local AD DNS Server is the initial requestor? I've looked at the box in detail and don't see any strange processes running or anything else out of the ordinary when looking at the results of a netstat -abn command line result. So that's why I'm asking this here :) 

 

2 Replies
best response confirmed by gregarican (Copper Contributor)
Solution

Hey @gregarican 

 

I suspect that the 2012 R2 DNS is receiving a query from a domain joined client, is unable to resolve so it passing on to the umbrella to resolve.

 

You can turn on logging on the 2012 box to capture DNS requests and where they have come from:

 

Open DNS, right click the server, and go to properties

 

In the Debug tab, select what you want to capture and fill out a name and location for the capture log.

 

clipboard_image_0.png

 

You might need to restart DNS services to get the log to kick into action.

 

After some time has gone, Open the log (I tend to save it as a .txt) and search for the domain in question. This will give you the IP of the client making the request

 

In my example below, I tried to go to hmitps.co.uk

 

clipboard_image_1.png

 

We can see in the log that the receive request was from 192.168.10.30 which resolves to the windows client I was using to test with. In your situation, I'd take a close look at that client and see if it is infected with malware etc.

 

Make sure you stop the debug once you've got the log you want - it can grew pretty big pretty quickly.

 

Hope this helps,

 

Mark

@HidMov Thanks for the suggestion. I had forgotten about this, and will give it a shot. Previously I was looking at the Windows 2012 R2 analytic logs, gathered via the recommended method outlined here --> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn.... When I looked at the details I didn't see the initial DNS client request for these particular QNAME's. Just saw the recursive requests out to Cisco OpenDNS Umbrella. Since I can assumedly trace things based on the XID for each DNS transaction, there wasn't a complete picture of which internal client initiated the calls. Hopefully the debug logs will divulge that!

1 best response

Accepted Solutions
best response confirmed by gregarican (Copper Contributor)
Solution

Hey @gregarican 

 

I suspect that the 2012 R2 DNS is receiving a query from a domain joined client, is unable to resolve so it passing on to the umbrella to resolve.

 

You can turn on logging on the 2012 box to capture DNS requests and where they have come from:

 

Open DNS, right click the server, and go to properties

 

In the Debug tab, select what you want to capture and fill out a name and location for the capture log.

 

clipboard_image_0.png

 

You might need to restart DNS services to get the log to kick into action.

 

After some time has gone, Open the log (I tend to save it as a .txt) and search for the domain in question. This will give you the IP of the client making the request

 

In my example below, I tried to go to hmitps.co.uk

 

clipboard_image_1.png

 

We can see in the log that the receive request was from 192.168.10.30 which resolves to the windows client I was using to test with. In your situation, I'd take a close look at that client and see if it is infected with malware etc.

 

Make sure you stop the debug once you've got the log you want - it can grew pretty big pretty quickly.

 

Hope this helps,

 

Mark

View solution in original post