Recently we're having a problem with the "Connection-specific DNS Suffix" automatically changing to an invalid domain on our network.

When a system plugs into the network, our DHCP server gives it the correct domain name suffix using option 15 (DNS Domain Name) = our-domain.com ... this can be verified immediately after getting an ip with ipconfig /all:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix : our-domain.com

After several minutes, some automatic discovery process finds a new (wrong) connection-specific dns suffix and updates the ip configuration with the new information. After this update with the wrong information, ipconfig /all changes to show:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix : novalocal

When this "novalocal" domain is discovered, many of my clients begin having name lookup problems.

This is happening to Windows 7 clients, and I've verified that the issue occurs with or without Bonjour installed. I haven't tried disabling SSDP or UPnP services yet. It is happening on clients with either Symantec firewall or Windows firewall turned on.

I did check for rogue DHCP servers, and offers / leases are only coming from my authorized DHCP servers (no rogues seen or sending offers on the network).

Has anyone seen anything like this before? Any suggestions on how I can find where this "novalocal" is coming from and how to prevent my clients from having their DNS suffix settings changed by some automatic discovery?

  • Have you checked in group policy that someone didn't automatically configure a suffix that they shouldn't have for these clients? – MDMarra Jun 22 '12 at 16:38
  • Where in group policy would I find the dns suffix settings? I'm not familiar with the dns part of group policy. – Mister_Tom Jun 22 '12 at 16:43
  • 1
    Is Google broken for you? – MDMarra Jun 22 '12 at 16:57
  • Thanks for the link, I'll double-check the policies at "Computer Configuration | Policies | Administrative Templates | Network | DNS Client". I did a gpupdate after getting a fresh IP and correct dns suffix from dhcp and suffix remained unchanged. I'm also trying to get some packet capture when it changes next. – Mister_Tom Jun 22 '12 at 17:04
  • There was no policy applied to my systems for the "DNS Client" GPO section, but I guess I could use that to force the "correct" domain. Definitely a possible workaround. It still bugs me that I can't figure out where this "novalocal" is coming from. – Mister_Tom Jun 22 '12 at 18:35

I found the problem, it was a rogue DHCP server. An intern was trying out the "Open Stack" cloud system which default configures a DHCP server. I guess he tried to isolate it from the network, but didn't do a good enough job because a few random DHCP messages between his server and clients were getting on the main network and setting only the domain name (not an ip) on my clients. Strange thing is that it was not responding to normal DHCP requests from clients on my subnet, he must've partially isolated his "Open Stack" traffic.

We found it with a packet trace in wireshark and searching for the string "novalocal" in packet details. It showed up in a few DHCP, SSDP, LLMNR, and NBNS packets to give us a few IP's and mac addresses to hunt down. I then viewed the mac table in my switches to find his port and go have a chat about the network problems his test was causing. We're isolating his test network with a separate router to prevent further leaks of his local broadcast traffic onto my LAN.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.