Video Screencast Help

DNS Registration Failing

Created: 20 Sep 2012 | 10 comments

We are currently migrating to SEP 12.1 from our previous vendor and are working currently to deploy to our server population.  

Post-installation reboot we are finding that a subset of our server population is failing to register with DNS dynamically.  This is generally resolved by issuing a 'ipconfig /registerdns' command from the server that SEP was installed on, however, we'd like to avoid having to do this at all (of course :) ).

The only blocks that we're seeing in the firewall logs are from LLMNR inbound to the server.  All traffic to/from our private network is trusted.  Nothing has shown up in any of the other logs (risk/IPS/app control/etc.).  There are no errors in the Event Logs indicating a failed DNS registration either.

While I don't think it is necessarily related to SEP, it is strange this issue seems to manifest itself after SEP installation.  

Any thoughts?

Comments 10 CommentsJump to latest comment

ᗺrian's picture

What components are you installing on the server? AV, PTP, NTP?

If so, disable NTP and see what happens.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Jason1222's picture

Are you installing the SEP firewall on your servers?

There is a default firewall rule to block IP v6 traffic. 

It is possible that the registration is failing due to the IP v6 trafic not being processed.

The Link Local Multicast Name Resolution (LLMNR, RFC 4795) is a protocol based on the Domain Name System (DNS) packet format that allows both IPv4 and IPv6 hosts to perform name resolution for hosts on the same local link. It is included in Windows Vista, Windows Server 2008 and Windows 7.

*** From Wikipedia for LLMNR ***

tmmiller's picture

They're getting the whole kit-and-caboodle.

While we can go the route of disabling module by module, I'd like to figure out how to identify exactly where the issue is coming from.  Especially given the fact that there is nothing being reported anywhere indicating any SEP actions are being taken.  

But it's certainly worth giving it a shot disabling component by component.

ᗺrian's picture

Check the traffic log on the client. It will show any traffic being blocked/allowed. If you want to keep the FW than you will need to modify the rule as mentioned above by Jason.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

tmmiller's picture

Thanks for the thoughts so far guys!

The server has all IPv6 disabled on the network adapter (it's a teamed adapter).

The LLMNR drops that I'm seeing in the firewall are inbound from hosts on the same subnet.  There are no outbound blocks in the firewall logs.

Name resolution works fine from the server.  The only issue seems to be that after SEP install, the server that is receiving the SEP install no longer has an A record registered in DNS.

Jason1222's picture

One other thing I can think of.

When you are installing the FW component, it is going to install and hook in a teefer3 (I believe in SEP 12.1) driver into the NIC. 

* * * *

The Teefer driver is responsible for capturing all network traffic entering or leaving a particular interface ( via the associated miniport driver ), so that the packets may be passed to the personal firewall component of the SEP client for analysis.

* * * *

This could be causing the server to call the DNS server and gracefully request the DNS records be removed from the DNS server as the "adapter" itself has technically changed.

After installing SEP on your servers, are you performing the reboot?

After the reboot occurs, it should re-register the DNS entry on the DNS server.

Is this what is happening?  Reboot - no re-register?  Or no reboot?

The interesting thing here is the IPCONFIG /REGISTERDNS is recreating the DNS record.

Hope that helps.

tmmiller's picture

Jason --

The way the servers have been deployed has been with a several day period between installation and reboot.  So a server could have SEP installed on Monday and not be rebooted until Thursday.  It doesn't unregister from DNS until after the reboot.

toby's picture

from what I see, the problem is present even when you have the Firewall not installed what would exclude the teefer driver and more put it into the IPS drivers.


Best regards!



usacc23's picture

Okay, I am experiencing on the same lines, but I want anyone to chime in on this:

We are on SEP 11.0.7101.1056

1. We are 99% VM Shop

2. I had 32 Servers to remove NTP with No FW turned on.

3. I set up a package to run the Reinstall from a specific Group to AV only (No Reboot).

4. I had about 8 servers where I had to do the same process on thru the Control Panel.

5. Of the 32 Servers when done, 6 failed to Register with the DNS Server.

6. Could ping by IP address but the a record was not there. It to be manually put back in.

We have a RCA(Root Cause Analysis) meeting tommorrow and I want to get a better understanding on this.

I have had our Symantec Technical Engineer look at the Log, but found nothing.

Could this be related?

toby's picture

have you had any success with support?

I may have found something interesting based on the SNAC service.

Considering that the SNAC Service has changed status from 11 to 12.

In version 12 the service is not disabled anymore but manual and therefore the drivers are getting loaded in any case. Talking about drivers we will find the according pointers in the RasMan PPP EAP section, what is also LAN authentication.

Could be the possibility that when SEP is especially getting updated in the first place forget to change the values as in that case still the version 11 is working. On the other side after the reboot when loading version 12 it is pointing to the old installation, what isnt loaded anymore and this takes some time until it is cleaned what should be part of the roru.exe.

Does this makes sense??


Best regards!