I have a recurring DNS problem that has been plaguing our users occasionally causing their laptops to appended our companies domain to the end of all DNS queries. The problem only occurs when users are offsite and it appears to be fairly random. It will work one day and then out of the blue it will show the invalid entry. This affects mostly Windows XP users but has recently been seen on Vista as well. Here is an example using nslookup.

C:\Users\Username>nslookup www.yahoo.com 
Server: Linksys

Non-authoritative answer:
Name: www.yahoo.com.EXAMPLE.COM

I have replaced the IP address that is reported with a placeholder but I can tell you that what it returns is the default *. entry on our Network Solutions configuration. Since obviously www.yahoo.com.EXAMPLE.COM doesn't exist this makes sense. I believe the user's internal equipment is functioning properly. Internally we run a Windows 2k3 Active Directory w/ Windows based DHCP and DNS servers. Eventually the problem resolves itself usually over a couple of hours or a number of reboots.

Has anyone seen this behavior before?

  • Aggghhhh, this drove me insane for so long -- I didn't realize networksolutions HAD a wildcard entry, after removing it (setting it to blank) and waiting a couple hours, I was finally able to set up a proper AD subdomain of our external domain and see the proper NXDOMAIN response from the outside world. – Kamilion Dec 15 '18 at 10:09

If you launch nslookup and turn on debugging you'll see that Windows always tries to append its suffix first.

Default Server:  itads.example.com

> set debug=true
> www.yahoo.com
Server:  itads.example.com

Got answer:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

        www.yahoo.com.example.com, type = A, class = IN
    ->  example.com
        ttl = 3600 (1 hour)
        primary name server = itads.example.com
        responsible mail addr = itads.example.com
        serial  = 12532170
        refresh = 1200 (20 mins)
        retry   = 600 (10 mins)
        expire  = 1209600 (14 days)
        default TTL = 3600 (1 hour)

Got answer:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 4,  authority records = 0,  additional = 0

        www.yahoo.com, type = A, class = IN
    ->  www.yahoo.com
        canonical name = www.wa1.b.yahoo.com
        ttl = 241 (4 mins 1 sec)
    ->  www.wa1.b.yahoo.com
        canonical name = www-real.wa1.b.yahoo.com
        ttl = 30 (30 secs)
    ->  www-real.wa1.b.yahoo.com
        internet address =
        ttl = 30 (30 secs)
    ->  www-real.wa1.b.yahoo.com
        internet address =
        ttl = 30 (30 secs)

Non-authoritative answer:
Name:    www-real.wa1.b.yahoo.com
Aliases:  www.yahoo.com, www.wa1.b.yahoo.com

As you can see above my machine tried to look for www.yahoo.com.example.com first, and the DNS server responded NXDOMAIN (entry not found). You can confirm this by running nslookup www.yahoo.com. (note the dot at the end of .com!) and you'll see that it is resolved normally.

What's happening is that your external DNS server is responding that they have an entry for "www.yahoo.com.example.com" and is returning your IP address for the root of your site. I'm not sure what service you use but I'm guessing that you have a wildcard mapping that tells your server to respond to any unknown query with a valid response, rather than returning NXDOMAIN. You'll need to double check your settings for the server and confirm that it is only set to respond to queries for entries it actually has (example.com, www.example.com, mail.example.com, etc.).

Remember that DNS works by checking the configured server and working its way up from there. The DNS query can take a path like the following pattern (of course this is just a example, it is probably wrong): Machine -> Local Router DNS (linksys) -> ISP DNS -> (2nd ISP DNS?) -> Root Server DNS -> TLD DNS -> Your External DNS server. Someone along that path is saying that www.yahoo.com.example.com exists. Chances are it's your external DNS server.


I figured I'd include one more tidbit about the randomness you mention. If this is really happening sporadically you may have a misconfigured external DNS server or their ISP could be providing a DNS hijacking service. Unfortunately I've seen more and more residential ISPs provide a "search service" for invalid domain names. Since almost all end users use their ISP DNS servers, the ISPs are now starting to redirect invalid domain entries to a search page - one usually laden with ads, irrelevant links and a small "Did you mean www.example.com?" with some results that may or may not be related to the domain name. I know that Verizon and Comcast are starting to do this, I believe Quest is starting to as well. Another possibility is OpenDNS, since they provide the same "search for a related domain" if it doesn't exist (it's their revenue after all).

My problem with suggesting that as the problem, though, is the fact that you say it's returning the address of your root record, which none of these would do if they were trying to search for it, they'd give you an IP of one of their web servers to handle the search.

  • 1
    Good summary - this is a common issue with many residential ISPs. – Doug Luxem Oct 13 '09 at 16:08
  • 1
    Joshua, Sounds perfectly reasonable. I have removed the wild card entry from your network solutions configuration. As you pointed it out it served no purpose but driving invalid web urls to our main website. I'll let it propagate over lunch and try again and let everyone know how it works. – Xap Oct 13 '09 at 17:03
  • Your hint about the ISP and DNS helped me track down my problem. I replaced the * with www. so my domains wouldn't fail as www.mydomain.tld and would no longer appear as www.yahoo.com.mydomain.tld. Within Hover it's listed under the DNS as a default value. – Stevoni Dec 29 '15 at 9:17

After drunken totalling my Windows 7 tcpip registry settings, I had the same problem. In:


make sure your entry for domain is the same as your entry for dhcpdomain, then you are good to go.

  • 5
    At least you're honest. – Tom O'Connor Nov 12 '12 at 0:03

I struggled over the same problem, that my windows is appending the primary domain suffix when using nslookup. The solution I found was that appending the dot for the request stops windows from doing this. So instead of using:

nslookup yahoo.com


nslookup yahoo.com.

According to the source other requests should not show this behaviour.

Source (3rd Post) here https://social.technet.microsoft.com/Forums/windows/en-US/a34896f6-d784-4e52-8252-54f6520bc495/dns-queries-all-have-my-internal-domain-name-applied-to-queries-eg-googlecommydomaincom?forum=winserverNIS


Problem most of the time related to configuration in the residential routers. In the general setup of these routers you will find two fields, System name and domain name.

Example, if your ISP domain name is x.com and you put the domain name in that field as y.com. The router will still give the DNS configured in the WAN and LAN interface as authoritative DNS, but non-authoritative will be given from this y.com.


I found the answer. In that registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters, look for search list. Double click it and delete what is in the box. Fixed mine. Now nslookup is correct. I had something there from an employer that I was using my personal pc for remote work. Never again will i work for that company. I am still finding rogue entries.


I had same issue.

Was being provided by the DHCP server

Deleting the domain registry value resolve issue HKLM\SYSTEM\CurrentControlSet001\Services\Tcpip\Parameters


For me, using bind9 as authoritative local nameserver, and authoritative nameserver for the same domain, I can fix this behaviour by removing the *.example.com record (commented out below).

From /etc/bind/example.com zone file

;*.example.com. IN CNAME example.com. ; GLOBALOK

This was set for convenience, not having to manually set all the port forwarded subdomains to the same public IP.

The side effect is as the parent describes. All queries resolve to the same public IP address. Programs and services operate fine, however nslookup never returns IP addresses which is a small anoyance that I put up with for half a year before discovering this page and leading me to the above fix.

  • DNS wildcards and suffix lists are two different things... – Patrick Mevzek Aug 29 '18 at 15:02

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.