My computer is connected to the work domain, where it gets the local dns-servers along with the dhcp-settings.
For a certain customer, i'm connecting to their network using VPN (Open VPN / TAP-Device) which ofc. sets up a second ip along with their DNS Servers.
The problem i'm facing, is that Windows 10 seems to be unable to decide which DNS-Server to query: let's say the domains are ad.customer.com
and ad.mysite.com
.
When the connection is established, windows 10 by default uses the dns-server of the remote-site, i.e. dns1.ad.customer.com
. Local DNS resolution now fails, which makes local file-shares, printers, etc. pp. inaccessible.
The problem is obviously, that the domain-names are sub-domains of a valid tld:
- The PC starts to ask the remote-dns-server for
mysite.com
– which could be resolved online. - But then ofc, the online-domain-controller responsibe for
mysite.com
does not have any information forad.mysite.com
, because this is only handled by the local dns-server(s) - tracerouting any internal name shows, that windows clearly tries to resolve it this way…
If I modify the metrics of the network connections (local vs TAP) then it behaves the other way round: I'm able to access local resources even if VPN is established, but obviously i'm not able to resolve hostnames on the ad.customer.com
-domain, because now the same thing vice-versa happens:
- Windows is asking my local DNS for
customer.com
- the request is forwarded to the DNS Server responsible for
cusotmer.com
– which in turn is the "online-version" and not aware of the internalad
-subdomain.
Is there a way to tell Windows which Connection / DNS-Server should be used for a certain FQDN?
Or could I setup my dc1.ad.mysite.com
to respond in a way, that the client knows he needs to query dc1.ad.customer.com
(ip) instead?
(Setting up a dns-forwarder ofc. will not work, because the internal-dns servers aren't connected, since the VPN-Connection originates from my machine)
So to say, I would need DNS-Redirection, not DNS-Forwarding.
Local One is 2012 R2, if that has an impact on the options.
Best Answer
I figured it out: Both
online-dns
servers (customer.com
andmysite.com
) had wildcard records setup, i.e. aA-record
like*.mysite.com
Therefore, when the
ad.customer.com
internal DNS was queried for a fqdn onad.mysite.com
, it was forwarded to OUR online-dns, the online-DNS responsible formysite.com
answered with the primary IP due to it's wildcard-A-record:I cannot change the Domain-Records for the customer, but i can change ours. So, I configured the metrics in order that the
remote
connection is used first, but for our tld, I disabled the wildcard-record, leaving onlyvalid
hostnames to be answered.So, if a VPN-Connection is established now, Windows will start to query the customers local dns, even for internal hostnames, but then no longer receives a wrong answer (due to forwarding to the online-dns) but nothing.
NOW Windows seems to query the dns servers of the secondary connection (local one, higher metric), which then works and leads to the correct result:
Knowing the cause, another - maybe better - solution was easy to find: While Solution 1 would always query the customers local DNS first, this one works with querying our local dns first:
First, ofc. Metrics of the two connections have been changed, so that the local connection is used first.
Inside our local DNS-Server I setup a Primary-Zone, matching the customers domain:
customer.com
- and left it empty.Now, our local DNS will answer with
not found
rather than forwarding the query to the customers wildcard-using-online-dns-server. (Which cannot resolve their internal names)My PC will now use the second (remote) connection, where the query for internal names can be resolved.
Drawback: Without an established VPN-Connection, I can no longer access the customers website, because our local dns is no longer forwarding these queries.
If I would need that as well, I could setup A-records in the "Fake-primary-Zone" ofc.