System administrators should turn on advanced debug logging from the DNS Manager console to get the most out of Windows DNS Events. Unfortunately, Microsoft did not design the debug log file for 3rd party logging and monitoring software. Administrators may encounter a DNS debug log error because of this.
A handful of Splunk and McAfee SIEM users have complained that Windows DNS logging stops after a while. Some suggest using a Scheduled Task which works because the log file is recreated every time Restart-Service DNS is run. This will resolve the DNS debug log error until the file reaches its maximum size again, but it will also restart the DNS Server service quite frequently.
Signs of the DNS Debug Log Error
Splunk (or other monitoring software) stops logging DNS events
An Event ID 3152 Error shows up around the same time logging stops
The debug log file no longer exists in the set file path
The file path for the log file is not on the same volume as the Windows OS (C:)
Set the DNS debug log file path to a location on the same volume as the Windows OS (C); it’s that simple.
The system backs up and deletes the log file when it reaches its maximum size, then an empty log file of the same filename is created in the same location. However, the log file is recreated in a slightly different way if it is not on the same volume as the OS. This difference is what causes the DNS debug log error that Splunk users may experience. Credit goes to adm at NXLog for finding the solution.
The more we rely on email, the more susceptible we are to spam and phishing attempts by cyber frauders. Recently, yet another company lost 3.8 million when they made a bank transfer requested by a spoofed email. How did it happen?
The attackers set up an email account that mirrored [Alutiiq CEO] Hambright’s email address and sent an email to Alutiiq’s controller that gave instructions about a “confidential transaction” by a person who called minutes later.
Pretending to be an attorney, the co-conspirator requested an “urgent” transfer of the $3.8 million “to an entity later revealed to be a fictitious third party company based in Hong Kong,” Hambright wrote. Hambright and the chief financial officer discovered the transfer two days later.
All companies small and large are susceptible to scams like this. Fortunately for Office 365 users, there is an easy way to effectively block spam and spoofing attempts by blocking senders from “Outside the organization”. Microsoft TechNet Blogger Caltaru Mihai also mentions this technique near the end of his Block Spoofing in Office 365 post and appropriately cautions “that this is a dangerous rule if not configured correctly, but it is very effective at blocking spoofing“.
Office 365 Exchange Admin Center
Log into your Office 365 Exchange Admin Center
Navigate to mailflow, then rules, and add a new rule
Click “More Options…” near the bottom of the new window
Add two conditions:
The sender’s domain is… yourdomain.com AND The sender is located… Outside the organization
Add one action:
Reject the message with the explanation… Message has been blocked as an email spoofing attempt.
Modify the message properties… Set the spam confidence level (SCL) to… 9
Add an exception(s)
This is not necessary, but it is usually a good idea to whitelist your company’s WAN IPs as well as any other legitimate services that may be sending emails on your company’s behalf. If you have SPF set up, then you can use the same IPs listed in the SPF TXT record
Let me know if this rule works out for your organization, or if you find some new ways to improve it!