> The list of DNS servers that Windows maintains means "Ask this >server first. If that server *doesn't respond*, ask this other server >next." It does *not* mean, "Ask this server first. If we don't get >an answer we like, ask this other server next."
Not exactly true. It is true for multiple DNS's assigned to a single adapter. When there are multiple adapters each with their own DNS, DNS resolution is attempted on each adapter in turn until one resolves it and only fails if none of them resolve it. Carl -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Wednesday, December 10, 2008 9:35 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Wed, Dec 10, 2008 at 4:29 PM, Carl Houseman <[email protected]> wrote: > The default DNS after connecting (the one that > NSLOOKUP identifies) is a server on the client > network's in the client's AD domain ... I'd bet money (or, at least, popcorn) that's your problem. The list of DNS servers that Windows maintains means "Ask this server first. If that server *doesn't respond*, ask this other server next." It does *not* mean, "Ask this server first. If we don't get an answer we like, ask this other server next." What happens to most people is they've got something like <corp.example.com> which is their Active Directory domain name. However, that domain name is not delegated in the public DNS. <example.com> exists in the public DNS, but there are no NS records delegating control to your Active Directory DNS servers. In other words, if I sit here on my home PC and type <dig corp.example.com.>, I'm going to get an NXDOMAIN (non-existent domain) response from the nameservers authoritative for <example.com>. When that happens to your Windows DNS client, *it stops looking*. It takes that "non-existent domain" message as authoritative (because it is). DNS does *not* then go and try your own corporate DNS servers to see if *they* happen to know about a <corp.example.com>. Since AD depends on DNS to find and authenticate to domain controllers, if DNS isn't working, everything will fall apart. The varied delays are prolly due to various kinds of caching and timeouts. You can check this theory by running an NSLOOKUP for SRV records associated with the Active Directory domain name. If your own AD domain is <corp.example.com>, connect with the VPN, then run the command: NSLOOKUP -type=SRV _ldap._tcp.corp.example.com. The <_ldap._tcp> SRV record is the magic that lets an Active Directory client find the Domain Controller(s) for a domain. It all hinges on that. If this is your problem, you should be able to do something about it, but it's not without complications. On Win XP (I dunno about Vista): 1. Open the "Network Connections" folder 2. From the menu bar, open the "Advanced" menu, then choose "Advanced Settings" 3. Select the "Adapters and Bindings" tab 4. Look in the "Connections" list 5. Move the icon for the VPN all the way down to the bottom 6. Move the icon for whatever connects you to your own private network all the way up to the top That will mean your private DNS servers then take precedence over VPN-provided DNS servers. Now, possible complications... Complication #1: It's entirely likely you now won't be able to connect to resources on the customer's network. That's because your own DNS servers will now be telling your computer that *their* network domain name doesn't exist. Solution #1 to complication #1: You might be able to get away with HOSTS and LMHOSTS file entries for the customer servers. Solution #2 to complication #1: If your local DNS servers are running on Win 2003 or later, you can configure selective forwarding, such that your customer's domain name is forwarded to the customer's DNS servers. However, that will require your local DNS servers to be able to reach customer DNS servers via IP, which likely won't work with your VPN. You'd need to configure a VPN gateway for your whole local network. Complication #2: If you use the same VPN for yourself to connect to your own company network, you might find you have the same problem the other way around: When VPN'ing in, you can't resolve your company's private domain. Solution #1 to complication #2: Manually adjust binding order before each connection. Solution #2 to complication #2: HOSTS/LMHOSTS again. Complication #3: If you're using customer-provided VPN software that forces settings upon you, you might not be able to make these adjustments. If so, you'll have to negotiate with your customer. Hope this helps, -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
