10

We are a small, 300-seat organization with a mixed BYOD and Active Directory environment (Windows Server 2012 Standard, Windows 7 Enterprise) and we are having a very strange problem involving very specific-scope failures to resolve our organization's domain name on our domain-joined, company-controlled machines. For the purpose of this discussion, I'll use company.com instead of our domain name.

Background:

  • Active Directory Domain Controller is located at 172.16.1.3
  • The AD/DC machine is also running DHCP, DNS, and HTTP (IIS)
  • Our organizations websites at company.com and subdomain.company.com are hosted by IIS on the AD/DC machine
  • We have a split-DNS scenario in which the AD/DC server is used for internal DNS resolution but a different, off-site server provides DNS resolution for public queries
  • The IP address corresponding to company.com and subdomain.company.com is the public IP address used by a firewall at the edge of our network (both on the AD/DC DNS server and the off-site DNS server)
  • The firewall is correctly configured for NAT to pass HTTP and HTTPS requests it receives on its public IP address to the internal IP of the AD/DC server and reflects

Scenario 1:

  • A user on a domain-joined Windows 7 Enterprise machine is connected directly to our local network with local address 172.16.6.100 /16, issued by the DHCP server.
  • The DNS server entry is provided by DHCP (172.16.1.3)
  • This user is able to access the websites hosted at company.com and subdomain.company.com
  • Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the internal DNS server (172.16.1.3)

Scenario 2:

  • The same user on the same domain-joined Windows 7 Enterprise machine goes home and connects to the Internet using their residential ISP
  • The IP and DNS server entries for the client machine are provided by DHCP
  • This user can access any internet resources, such as google.com
  • This user cannot access the website at company.com or subdomain.company.com (a "host not resolved" error is returned)
  • When this user runs nslookup on company.com they DO receive the correct public IP address provided by DNS
  • HTTP/HTTPS requests to the IP address succeed and a webpage is returned properly by the server
  • This issue prevails across all web browsers
  • Using tracert company.com returns "unable to resolve target system name"
  • Using ping company.com returns "could not find host company.com"
  • When running Wireshark on the client before/during a failed request, no packets are sent by the client machine (either for DNS resolution or for an initial HTTP/ping/tracert request)
  • Restarting the DNS Client service does not resolve the problem
  • Stopping the DNS Client service does not resolve the problem
  • Using ipconfig /flushdns does not resolve this issue
  • Using route /f does not resolve this issue
  • Resetting the network connections using netsh int ip reset does not resolve this issue
  • Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the DNS server specified by the DHCP settings of the network used by the user

Scenario 3:

  • This same user on a personal (not domain-joined) Windows 7 Professional computer is able to access the websites at company.com and subdomain.company.com when connected to our local network
  • Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the internal DNS server (172.16.1.3)

Scenario 4:

  • This same user on a personal (not domain-joined) Windows 7 Professional computer is able to access the websites at company.com and subdomain.company.com when connected their home network
  • Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the DNS server specified by the DHCP settings of the network used by the user

Final Notes:

This issue seems to be generalized to affect all company-owned computers. We are using a common system image for all company-owned computers, which was just loaded in August. I have been scouring the internet in search of possible solutions and have come up empty handed so far -- I really appreciate any suggestions or advice you may have.

Dan
  • 101
  • 1
  • 1
  • 5
  • 2
    Running websites on your domain controllers, eh? That's no bueno. – Ryan Ries Sep 27 '13 at 17:50
  • 1
    Yep, I agree. Budgets are tight, what can I say. Maybe in the future... – Dan Sep 27 '13 at 17:56
  • 1. Are you configuring any DNS settings on the domain joined machines with Group Policy? 2. Running nslookup in debug mode for each scenario will probably give you some clues. – joeqwerty Sep 27 '13 at 18:59
  • Thanks for the suggestion. DNS is provided by the DHCP server, not group policy, so when a user leaves our physical building they receive the DNS server of whatever network they connect to. I have run nslookup in all cases, and it returns the correct DNS settings in all cases (including the failure case in Scenario 2). The problem seems to be that for some reason the web browsers are not even bothering to go as far as nslookup -- as described above, they simply fail without initiating any network transaction in Scenario 2. – Dan Sep 27 '13 at 19:03
  • Can I make the assumption that they can acceess it as `www.company.com` but not just `company.com` or does both fail? – TheCleaner Sep 27 '13 at 19:15
  • Thanks for the question! Unfortunately, no, all attempts to access the server using company.com or any subdomain.company.com fail -- there are about 10 different CNAME and A records that point to that server and all fail in Scenario 2. Accordingly, both company.com and www.company.com fail in that scenario. – Dan Sep 27 '13 at 19:51
  • Can you access the resource by IP address instead of FQDN? This will tell us whether it's a firewall issue or a DNS issue. – CIA Sep 27 '13 at 22:48
  • Thanks for the suggestion! Yes, as described in Scenario 2, requests that use the IP address instead of the FQDN are successful. Also, as described by Scenario 4, users that are not using company-issued computers have no trouble accessing this server using the FQDN from off-site locations. – Dan Sep 27 '13 at 22:57
  • Have you tried to disable WINS or NetBIOS on the client machines? – Edwin Oct 01 '13 at 03:09
  • Re: scenario 2 - IE Browser? Any proxy settings? Same problem with different browser? Same network interface used at both office & home? Or wired at office, wirless at home? May want to expand search to include peculiarities of NLA (network location awareness) – Clayton Oct 01 '13 at 20:04
  • Thanks, Edwin and Craig. I just tried disabling NetBIOS and WINS is not set; this did not resolve the problem. I have also tried setting WINS on the client machines and passing WINS through the firewall to no avail. These issues prevail on any type of connection -- the consistent theme is that it only affects company-owned computers using the standard company software image. NLA is not an issue -- the issues persist regarding of the location type (Work/Home/Public). The issue persists across all browsers, testing is primarily conducted on Google Chrome. No proxies are configured. – Dan Oct 02 '13 at 13:03
  • The output from a comprehensive nslookup command from an affected client (Scenario 2) is at the pastebin link below (too long for an in-comment paste). **[http://pastebin.com/w0DS8LyP](http://pastebin.com/w0DS8LyP)** – Dan Oct 02 '13 at 13:12
  • Tough one, grasping here... Are you doing a cold boot (not sleep/resume) of the system when it's at the home location? Have you tried making a local (not domain) account on it and running the browser with that login? – Clayton Oct 03 '13 at 18:16
  • Cold boot, yes. I have not tried a local account yet, but I will tomorrow. Any other ideas? – Dan Oct 10 '13 at 00:07
  • What are the DNS server(s) configured via DHCP when the user has the work laptop at home? Are they the same as what's configured on the user's personal laptop at home? Are you able to duplicate the issue using a public DNS server (4.2.2.4)? – CIA Oct 10 '13 at 13:59
  • The DNS servers are assigned by DHCP. When the computer is on the company network, it uses our internal DNS server. When the user is at another location it uses the DNS server specified by that location. The issue persists even if a public DNS server is manually specified (such as Google's Public DNS at 8.8.8.8 or 8.8.4.4). – Dan Oct 11 '13 at 14:22
  • Check the contents of your **hosts** file, please. I strongly suspects that sometime in the past, the image used to clone the computers has the hosts file hardcoded. This explains why there were no DNS lookup made by the browsers; the hosts file _always_ gets first dib on all DNS lookups. – pepoluan Feb 06 '14 at 18:59
  • have you deployed any "extrange" solution like Direct Access or something like that may interfiere with normal DNS resolution process?? Regards – SantiFdezMunoz Oct 16 '13 at 14:34
  • Thanks, Santi and Dave. We do not have DirectAccess enabled. We do have VPN enabled, but that is run through a different machine than the DNS server, and the affected client machines are not connected to VPN when the problem occurs. VPN does not seem to be involved in the equation at all. – Dan Oct 17 '13 at 21:21

2 Answers2

2

The domain joined computers are going to be looking for their DC, not just doing a DNS based lookup. Since the domain is the same as the public website, they're going to be searching for an SRV record to tell them how to get to the DC and get domain info. Since there's no DC in the remote network, they cannot resolve this name using normal AD aware windows parts.

When you use ping or (almost) any Windows application, it uses the full Windows IP stack, including the parts that talk to AD. Whereas NSLookup actually just does a DNS query. You've verified this with your Wireshark traces, no lookups are performed by Windows when trying to get to company.com but nslookup shows a proper DNS lookup. This is why you're unable to resolve the domain via ping or web browser, but nslookup is fine.

The solution for the first part of this is to use www.company.com to get to the website both internally and externally so that clients completely ignore looking for a DC.

The solution for the second part is trickier depending on what subdomain.company.com refers to internally as well as externally. Does the DC have a DNS record for subdomain, or are those requests just sent to the external DNS server? If it does have a DNS record, where does that record point?

RobbieCrash
  • 1,181
  • 9
  • 26
0

I would check the HOSTS file (http://en.wikipedia.org/wiki/Hosts_%28file%29#Location_in_the_file_system) on the machine doesn't contain any entries for the hosts you're trying to get to. I think the NSLOOKUP tool bypasses the hosts file but the web-browser will not.

I would also check you do not have a proxy configured in the web-browser as some types of proxies also resolve the DNS.

I would also try running the browser in its "safe mode" (i.e. with all addons and plugins disabled) with IE ("iexplore -extoff") or Firefox (hold down shift key when starting or "firefox -safe-mode").

Ideally if possible try with another web-browser to narrow down whether it is the web-browser or OS.

Then if I still wasn't getting anywhere I would check what services are bound to the network adapter (crazy firewall with specific rules getting in the way?)

Finally, and this is straying into the increasingly unlikely but NSLOOKUP will append the computer or connection specific domain name onto queries automatically. For instance my router sets the domain name as "router" so any nslookup for something like "matthew" actually searches DNS for "matthew.router", it's possible the web-browser is not doing this.. as you said you did a packet capture it doesn't sound like this is your problem.. but just in case you missed it in the packet capture or your capture environment wasn't quite right :-).

These are the things I would try and hopefully this will help you too :-).

Matthew1471
  • 317
  • 2
  • 4