Excessive lookup queries from DNS

%3CLINGO-SUB%20id%3D%22lingo-sub-1606893%22%20slang%3D%22en-US%22%3ERe%3A%20Excessive%20lookup%20queries%20from%20DNS%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1606893%22%20slang%3D%22en-US%22%3E%3CP%20class%3D%22lia-align-left%22%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F428046%22%20target%3D%22_blank%22%3E%40Pranesh1060%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20assume%20you%20meant%20for%20every%20KQL%20query%20executed%20in%20LA%20workspace%20there%20is%20DNS%20queries%2Factivity%20observed%2C%20correct%20%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhat%20do%20the%20observed%20DNS%20lookup%20queries%20indicate%20in%20terms%20of%20FQDN%2FDNS%20records%3F%20and%20how%20did%20you%20establish%20that%20those%20DNS%20queries%20are%20related%20to%20queries%20executed%20in%20the%20Log%20Analytics%20workspace%20%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1610575%22%20slang%3D%22en-US%22%3ERe%3A%20Excessive%20lookup%20queries%20from%20DNS%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1610575%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F540154%22%20target%3D%22_blank%22%3E%40majo01%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20post%20was%20written%20in%20a%20hurry%2C%20let%20me%20try%20to%20post%20the%20exact%20scenario%3C%2FP%3E%3CP%3E1)%20Random%20requests%20are%20getting%20generated%20from%20endpoint%20machines%20trying%20to%20connect%20to%20random%20suspicious%20domains.%20This%20has%20caused%20a%20surge%20in%20the%20number%20of%20requests%20made%20by%20endpoints%20via%20DNS%20servers%20to%20internet.%3C%2FP%3E%3CP%3E2)%20These%20alerts%20are%20getting%20generated%20from%20ASC%20and%20since%20it%20is%20connected%20with%20Sentinel%2C%20alerts%20are%20getting%20replicated.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUsing%20the%20DG%20algorithm%20we%20come%20across%20a%20new%20domain%20every%20time%20there%20is%20a%20new%20alert.%20Now%20the%20question%20here%20is%20we%20do%20not%20have%20alerts%20from%20any%20other%20security%20tools%2C%20we%20tried%20scanning%20the%20machines%20but%20the%20results%20came%20clean.%20Not%20all%20the%20alerts%20are%20from%20one%20location%20or%20one%20particular%20endpoint.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EJust%20wanted%20to%20know%2C%20if%20anyone%20here%20has%20faced%20something%20of%20this%20kind%20or%20probably%20would%20have%20suggestions%20as%20to%20how%20we%20can%20tackle%20these%20alerts.%20If%20there%20were%20any%20changes%20that%20were%20recently%20made%20on%20ASC%20that%20we%20are%20not%20aware%20of.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1601051%22%20slang%3D%22en-US%22%3EExcessive%20lookup%20queries%20from%20DNS%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1601051%22%20slang%3D%22en-US%22%3E%3CP%3EHello%20Experts%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFrom%20last%202%20weeks%20or%20so%20we%20have%20been%20getting%20a%20lot%20of%20DNS%20lookup%20queries%20and%20events%20are%20being%20generated%20since%20the%20endpoints%20are%20trying%20to%20connect%20to%20random%20suspicious%20domains%20via%20the%20DNS%20servers%20to%20the%20internet%20.%20The%20number%20of%20events%20started%20to%20change%20drastically%20from%207th%20of%20this%20month.%20In%20addition%20to%20that%2C%20we%20have%20been%20getting%20alerts%20from%20ASC%20on%20Sentinel%20saying%20that%20endpoints%20are%20trying%20to%20connect%20to%20random%20suspicious%20domains%2Fsinkhole%20domains%20and%20at%20times%20we%20are%20also%20getting%20alerts%20saying%20that%20network%20intrusion%20signature%20activation%20has%20been%20detected.%20However%20there%20are%20no%20alerts%20from%20MDATP%20or%20any%20other%20tool%20related%20to%20this%20activity.%20We%20have%20tried%20troubleshooting%20this%20on%20our%20own%20and%20as%20well%20as%20with%20MS%2C%20till%20now%20we%20haven't%20found%20anything.%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20was%20an%20article%20saying%20that%20the%20updates%20for%20the%20month%20of%20July%20contained%202%20zero%20day%20vulnerabilities%20w.r.t%20to%20DNS%20servers%20and%20a%20registry%20change%20would%20be%20required%2C%20which%20we%20are%20in%20process%20of%20deployment.%3C%2FP%3E%3CP%3EWe%20checked%20this%20internally%20as%20well%20and%20has%20been%20confirmed%20that%20no%20additional%20logging%20has%20been%20enabled%20for%20on%20DNS.%3C%2FP%3E%3CP%3EHas%20anyone%20here%20faced%20this%20issue%3F%20Any%20help%20would%20be%20appreciated.%3C%2FP%3E%3CP%3EThanking%20in%20anticipation%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1601051%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3ESentinel%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1610620%22%20slang%3D%22en-US%22%3ERe%3A%20Excessive%20lookup%20queries%20from%20DNS%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1610620%22%20slang%3D%22en-US%22%3EThe%20primary%20cause%20of%20too%20many%20DNS%20requests%20is%20TTLs%20that%20are%20too%20low.%20Yours%20are%20low%20but%20not%20insanely%20low.%20(I've%20seen%2060%20and%201%20as%20TTLs%20in%20production%20systems.)%3CBR%20%2F%3E%3CBR%20%2F%3Edigitaldawn.net.%201800%20IN%20A%20109.73.163.166%3CBR%20%2F%3E%3CBR%20%2F%3E%3CA%20href%3D%22http%3A%2F%2Fwww.digitaldawn.net%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Ewww.digitaldawn.net%3C%2FA%3E.%203600%20IN%20A%20208.94.146.71%3CBR%20%2F%3E%3CA%20href%3D%22http%3A%2F%2Fwww.digitaldawn.net%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Ewww.digitaldawn.net%3C%2FA%3E.%203600%20IN%20A%20208.94.146.70%3CBR%20%2F%3E%3CA%20href%3D%22http%3A%2F%2Fwww.digitaldawn.net%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Ewww.digitaldawn.net%3C%2FA%3E.%203600%20IN%20A%20208.94.146.80%3CBR%20%2F%3E%3CA%20href%3D%22http%3A%2F%2Fwww.digitaldawn.net%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Ewww.digitaldawn.net%3C%2FA%3E.%203600%20IN%20A%20208.94.146.81%3CBR%20%2F%3E%3CBR%20%2F%3Ecdn.digitaldawn.net.%201800%20IN%20CNAME%20wpc.7b5c.edgecastcdn.net.%3CBR%20%2F%3Ewpc.7b5c.edgecastcdn.net.%203600%20IN%20CNAME%20gs1.wpc.edgecastcdn.net.%3CBR%20%2F%3Egs1.wpc.edgecastcdn.net.%2014400%20IN%20A%2093.184.221.133%3CBR%20%2F%3EUnless%20you%20are%20changing%20the%20IP%20address%20that%20these%20domains%20point%20to%20more%20often%20than%20once%20per%20day%2C%20you%20will%20be%20better%20off%20changing%20the%20TTL%20to%20something%20like%2086400%20(24%20hours).%20You%20can%20go%20higher%20if%20you%20can%20be%20confident%20of%20having%20at%20least%20the%20time%20period%20in%20the%20TTL%20of%20advance%20waning%20that%20you%20might%20need%20to%20change%20the%20IP%20address.%3CBR%20%2F%3E%3CBR%20%2F%3EFor%20the%20cdn.digitladawn.net%20subdomain%2C%20even%20if%20you%20set%20that%20TTL%20to%2086400%2C%20only%20that%20line%20in%20the%20above%20output%20will%20be%20cached%20for%2024%20hours.%20If%20the%20wpc.7b5c.edgecastcdn.net%20response%20changes%2C%20all%20clients%20should%20have%20picked%20up%20the%20new%20value%20after%20a%20maximum%20of%20one%20hour%20(ignoring%20for%20now%20those%20DNS%20servers%20that%20ignore%20your%20TTLs.)%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20other%20two%20causes%20of%20too%20many%20DNS%20requests%20that%20I%20have%20seen%20are%20too%20many%20clients%20(say%2C%20thousands%20of%20edge%20CDN%20servers%20that%20are%20all%20hitting%20your%20authoritative%20name%20servers)%20or%20a%20single%20misbehaving%20client%20(possibly%20a%20script%20on%20your%20own%20server)%20that%20is%20doing%20lookups%20dozens%20of%20times%20per%20second.%20An%20example%20of%20this%20could%20be%20a%20reverse%20proxy%20that%20uses%20backend.digitaldawn.net%20as%20its%20upstream%20server%20and%20makes%20a%20DNS%20request%20for%20that%20domain%20for%20every%20HTTP%20request%20it%20has%20to%20proxy.%20Adding%20DNS%20caching%20to%20that%20server%20or%20running%20your%20own%20authoritative%20name%20server%20inside%20your%20production%20environment%20can%20solve%20this%20problem.%3CBR%20%2F%3E%3CBR%20%2F%3EIf%20you%20can%20get%20hold%20of%20better%20statistics%20for%20your%20name%20servers%20(such%20as%20the%20IP%20addresses%20of%20all%20the%20clients%20that%20did%20lookups)%20then%20you%20might%20be%20able%20to%20diagnose%20this%20sort%20of%20problem.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1759236%22%20slang%3D%22en-US%22%3ERe%3A%20Excessive%20lookup%20queries%20from%20DNS%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1759236%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F428046%22%20target%3D%22_blank%22%3E%40Pranesh1060%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20Team%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20just%20wondering%20when%20the%20DNS%20lookup%20was%20put%20into%20preview%20in%20ASC%20and%20thus%20reports%20into%20Sentinel.%26nbsp%3B%20As%20per%20below%20-%20see%20alot%20of%20this%20associated%20with%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E1%20-%20attempted%20communications%20with%20suspicious%20sinkholed%20domain%3C%2FP%3E%3CP%3E2%20-%20network%20intrusion%20detections%20signature%20activated%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ethey%20come%20hand%20in%20hand%20(as%20you%20would%20expect)%20but%20trying%20to%20establish%20the%20rationale%20for%20ASC%20reporting%20these%20and%20trying%20to%20establish%20the%20base%20for%20it%20is%20proving%20somewhat%20difficult.%26nbsp%3B%20any%20suggestions%20would%20be%20great%20-%20tks%20all%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Contributor

Hello Experts,

 

From last 2 weeks or so we have been getting a lot of DNS lookup queries and events are being generated since the endpoints are trying to connect to random suspicious domains via the DNS servers to the internet . The number of events started to change drastically from 7th of this month. In addition to that, we have been getting alerts from ASC on Sentinel saying that endpoints are trying to connect to random suspicious domains/sinkhole domains and at times we are also getting alerts saying that network intrusion signature activation has been detected. However there are no alerts from MDATP or any other tool related to this activity. We have tried troubleshooting this on our own and as well as with MS, till now we haven't found anything. 

There was an article saying that the updates for the month of July contained 2 zero day vulnerabilities w.r.t to DNS servers and a registry change would be required, which we are in process of deployment.

We checked this internally as well and has been confirmed that no additional logging has been enabled for on DNS.

Has anyone here faced this issue? Any help would be appreciated.

Thanking in anticipation

 

4 Replies

@Pranesh1060 

I assume you meant for every KQL query executed in LA workspace there is DNS queries/activity observed, correct ?

 

What do the observed DNS lookup queries indicate in terms of FQDN/DNS records? and how did you establish that those DNS queries are related to queries executed in the Log Analytics workspace ?

 

@majo01 

That post was written in a hurry, let me try to post the exact scenario

1) Random requests are getting generated from endpoint machines trying to connect to random suspicious domains. This has caused a surge in the number of requests made by endpoints via DNS servers to internet.

2) These alerts are getting generated from ASC and since it is connected with Sentinel, alerts are getting replicated.

 

Using the DG algorithm we come across a new domain every time there is a new alert. Now the question here is we do not have alerts from any other security tools, we tried scanning the machines but the results came clean. Not all the alerts are from one location or one particular endpoint.

 

Just wanted to know, if anyone here has faced something of this kind or probably would have suggestions as to how we can tackle these alerts. If there were any changes that were recently made on ASC that we are not aware of.

 

 

 

The primary cause of too many DNS requests is TTLs that are too low. Yours are low but not insanely low. (I've seen 60 and 1 as TTLs in production systems.)

digitaldawn.net. 1800 IN A 109.73.163.166

www.digitaldawn.net. 3600 IN A 208.94.146.71
www.digitaldawn.net. 3600 IN A 208.94.146.70
www.digitaldawn.net. 3600 IN A 208.94.146.80
www.digitaldawn.net. 3600 IN A 208.94.146.81

cdn.digitaldawn.net. 1800 IN CNAME wpc.7b5c.edgecastcdn.net.
wpc.7b5c.edgecastcdn.net. 3600 IN CNAME gs1.wpc.edgecastcdn.net.
gs1.wpc.edgecastcdn.net. 14400 IN A 93.184.221.133
Unless you are changing the IP address that these domains point to more often than once per day, you will be better off changing the TTL to something like 86400 (24 hours). You can go higher if you can be confident of having at least the time period in the TTL of advance waning that you might need to change the IP address.

For the cdn.digitladawn.net subdomain, even if you set that TTL to 86400, only that line in the above output will be cached for 24 hours. If the wpc.7b5c.edgecastcdn.net response changes, all clients should have picked up the new value after a maximum of one hour (ignoring for now those DNS servers that ignore your TTLs.)

The other two causes of too many DNS requests that I have seen are too many clients (say, thousands of edge CDN servers that are all hitting your authoritative name servers) or a single misbehaving client (possibly a script on your own server) that is doing lookups dozens of times per second. An example of this could be a reverse proxy that uses backend.digitaldawn.net as its upstream server and makes a DNS request for that domain for every HTTP request it has to proxy. Adding DNS caching to that server or running your own authoritative name server inside your production environment can solve this problem.

If you can get hold of better statistics for your name servers (such as the IP addresses of all the clients that did lookups) then you might be able to diagnose this sort of problem.

@Pranesh1060 

 

Hi Team 

 

I am just wondering when the DNS lookup was put into preview in ASC and thus reports into Sentinel.  As per below - see alot of this associated with 

 

1 - attempted communications with suspicious sinkholed domain

2 - network intrusion detections signature activated

 

they come hand in hand (as you would expect) but trying to establish the rationale for ASC reporting these and trying to establish the base for it is proving somewhat difficult.  any suggestions would be great - tks all