Showing results for 
Search instead for 
Did you mean: 

RE: Dns.exe being blocked

So this is not stopping Zone transfer from happening??
Level 13
Report Inappropriate Content
Message 12 of 22

RE: Dns.exe being blocked

not unless its showing on the logs between the primary and secondary, why is DNS replication not taking place?

RE: Dns.exe being blocked

See this thread: Someone in that thread tracked it down to UPnP. Disabling the service for them seemed to help. I haven't tried it on my systems yet that are throwing the error.

NOT Plug and Play

sad 1. It is NOT wise to turn off Plug and Play unless you like hardware driver failures.
:confused: 2. This communication is already listed, albeit an old listing dated from 2005, on a Symantec site as a WORM. :eek:

The issue I believe is that this may be so old a worm it is no longer supported in the DATs.
I have had this issue before, such is the nature of the anarchists that produce these worms (can they NOT find gainful employment?).
I am working to prove this issue is real and I will post what I find.


Patrick Burwell
Senior Infrastructure Engineer
Senior EPO Engineer

Re: NOT Plug and Play

The Bad News: After speaking with Mcafee, they say that blocking DNS.exe and LSASS.exe traffic for port 6660-6669 can cause issues on AD network servers, but they don't recommend unblocking the range. They suggested excluded the executables from scanning but I don't like that solution either.
What if they get infected?

I tested unblocking the IRC CHAT port range from active scanning on two of our dns servers and now my unc access to another DNS server no longer gets me "access denied" errors when I try to make a change on the other server's "scheduled tasks". Hmmm!

The Hopeful News: I have a contact in Microsoft and have dispatched the question to them to resolve the issue for us all. 11,000+ views indicates many have a question about this matter so we might actually get a response within 30 days.

Maybe we will find out we can direct %windir%\system32\DNS.exe and %windir%\system32\LSASS.exe to NOT use that port range, with a registry change, so when they alert the Mcafee client as having used the IRC Chat Ports 6660-6669 we can KNOW they have been infected!

I suspect DNS.exe and LSASS.exe already "roam" other port ranges and when they get blocked they are configured to just try a different range, but I have yet to confirm this anywhere no Microsoft sites. Our best minds are working on it, you are officially in trouble.

In the mean time, if you have a documented solution, you can send an email to me at my Ministry contact form, as I don't have a contact form set up for the site and I'm not so stupid as to post my email on the internet EVER again.

Message was edited by: patrickburwell on 1/6/10 1:31:40 PM GMT-05:00

Re: NOT Plug and Play


as I can see from the first post this is a old problem. It hit us only now as we migrated from ePo 4.0 to ePo 4.5 and to the 8.7.0 scanner.

Is there meanwhile a solution other than to configure windows  (;en-us;812873 ) to reserve this range of ports ?



Re: NOT Plug and Play


I forgot to mention that it happens with other applications to ( wget.exe and more ) that do simply ftp and other protocols so it is not a solution to disable port range checks for singel applications.



Re: Port blocking rules - odd log entries

Ok, we have an update on the request to Microsoft.

Essentially their answer is "Open a service call".

We are unblocking IRC Chat for DNS LSASS because we believe the issue is resulting from the standard ports being overloaded by our internal DOTNet application "cloud".

TIP: When you exclude IRC Chat PORT Range blocking for DNS.exe and LSASS.exe they are STILL SCANNED for viruses - so don't worry.

Reliable Contributor tao
Reliable Contributor
Report Inappropriate Content
Message 19 of 22

Re: Port blocking rules - odd log entries

One of the units has blocked and logged the following:

Threat Source Address: Our Domain Controller

Threat Source Process Name: C:\Program Files\McAfee\SiteAdvisor Enterprise\McSACore.exe

Threat Target User Name: SYSTEM
Threat Target Port Number: 6,666

If I'm reading this correctly our DC tried to communicate via McSACore on port 6666.  Why would McAfee SiteAdvisor communicate with our DC or vice versa?

If this information was helpful or has answered your question, please select Accept as Solution. This will assist other memebers

Re: Port blocking rules - odd log entries

I am bringing this up from the dead, I am gonna agree, why do dns.exe or lsass.exe communicate to these port #'s?

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community