0

We run an Exchange 2003 email server which also doubles as a SDC / DNS server. The PDC also serves DNS requests too. Every now and again an email will fail. Where the email is going to or coming from doesn't seem to make much difference as long as it passes through our organization but when it fails it sends an NDR saying,

"The destination server for this recipient could not be found in Domain Name Service (DNS). Please verify the email address and retry. If that fails, contact your administrator. "

McAfee's VirusScan Enterprise is running on the Exchange server. It had logged the following error:

Blocked by port blocking rule C:\WINDOWS\System32\dns.exe Anti-virus Standard Protection:Prevent IRC communication 10.0.0.6:6668

The antivirus log times somewhat match up with the failed email times. I've re-configured this particular AV rule and I'm hopeful that it will do the trick. Is there a simple way to test this?

Also worthy of note, this exchange server is scheduled for some maintenance. It has been running straight for almost 2 years now. Could this be causing issues? Other than the random DNS NDR here and there performance and delivery are both quite fast.

So, I'm asking for help in testing the configuration change I have made and whether other people have encountered this NDR for other reasons which might apply to myself.

Thanks in advance.

1
  • 1
    Terminology nitpick - There are no "PDC" computers in Active Directory. They're all just domain controllers and host equal copies of the Active Directory database for their domain (so long as they aren't read-only DCs). One of them in each domain of your forest holds the "PDC emulator" role, but that doesn't make its copy of Active Directory "primary". Dec 2, 2009 at 15:53

1 Answer 1

1

Silly antivirus software!

Unfortunately, there isn't an easy way using built-in tools to make a DNS request using a particular port (since the port appears to be what's setting off the AV rule). Why that rule is applying to UDP traffic from the DNS server (since IRC is TCP-based) is puzzling. (It is possible for the DNS server to source queries using TCP, but that's not typically the case.)

You are probably in dire need of some Windows updates (and possible Exchange updates, too) if you've got a solid uptime of 2 years, but in general that's not going to cause delivery issues. I'd be wary of keeping the machine up that long, straight, only because you've probably got some serious unpatched security vulnerabilities sitting there.

4
  • Sorry, I meant to say that it's been two years since I did any maintenance on the Exchange installation such as eseutil. The server is up-to-date in terms of Windows / Exchange security updates. So far the change to the AV seems to be working although I suppose time will tell whether or not it was the solution. Thanks for the insight, Evan. Also, thanks for the terminology nitpick. ;) I should have known that.
    – JohnyD
    Dec 2, 2009 at 17:37
  • @JohnyD: >smile< Big difference, then. My experience has been that, so long as there's no compelling need to shrink the database, the "need" for regular offline defragmentation has been very overblown. The worst that you're going to see is a badly fragmented database and poor performance (not unlike a fragmented filesystem). Reliabilty and functionality won't be impacted by a fragmented IS database. Dec 2, 2009 at 17:43
  • I've heard others mention that exact opinion, which is why I've put off that maintenance procedure for this long. As I said in the original post, performance and delivery are both very fast and if it ain't broke... Thanks for the insight.
    – JohnyD
    Dec 2, 2009 at 18:04
  • To add to what Evan has said: eseutil should not be considered a "maintenance" tool and should not be be used as part of any regularly (or non-regularly )occurring maintenence schedule.
    – joeqwerty
    Dec 3, 2009 at 0:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .