I have an internal network in which all services are registered under a internal domain (e.g.: coolcorp.io).

When users connect to the VPN, I want them to be able to resolve the internal services in *.coolcorp.io, without having any other "public" name resolution going through our internal DNS server.

In macOS and Linux I can do that creating a custom resolver setting under /etc/resolver to that specific domain.

I'm not sure how can I do that on Windows. We don't have AD and the DNS is not supposed to be the default gateway for our VPN.


For background, lets look at how the DNS Stack works on Windows.

When a resolution for an FQDN needs to happen say a.contoso.com

  • If no match is found in the Cache or hosts file
  • The OS looks at the Name Resolution Policy Table, this is an interface agnostic list where you can specify the DNS Server IP Address or Proxy Server to use for the Name or Suffix
  • If no match in the NRPT Table queries are sent on the interfaces and the response from the most preferred interface is selected (Lan > VPN > Wi-Fi > Cellular)

Now for your particular case the best thing to do is to add an NRPT entry for *.coolcorp.io and the Corporate DNS Servers. On Windows 10, this can be part of the Windows VPN Profile via the DomainNameInformationList property in the VPNv2 CSP for MDM's https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp. The NRPT Policies can also be added via the Add-DnsClientNrptRule powershell commandlet. This will make sure that all resolutions for *.coolcorp.io goto the VPN Server. Next, in your VPN profile itself you now need not give a DNS Server Address or a DNS Suffix.


If I'm reading you right, then I guess it depends on how you're assigning IPs from your VPN and whether or not you have the capability of setting the DNS Server address, guessing you would but not every implementation is the same. You'd want to configure the zones that you want to be answered internally on that DNS server and leave recursion intact (although this is generally a bad idea if that DNS server is exposed to the public, as it opens you to potential denial of service attacks, and you might need to be more complex if so). This way your DNS server will answer what it can first and if it has no zone for the query it will forward to the internet roots by default.

  • additionally, to resolve the "public" thought since you said you don't want them to go through that DNS server, you can set it up to point at another DNS server that you trust or build to handle the queries to the public instead of using the internet roots. If they are Server 2012 R2 or better, you can also use the new functionality designed for this: blogs.technet.microsoft.com/networking/2015/05/12/… – Kyp Oct 20 '17 at 23:11
  • I don't want to handle DNS queries that aren't about my domain (*.coolcorp.io). "Public" domains should be queried directly to whatever DHCP gave to that particular station. I.e.: I don't want anything not related to "work" passing through my network, even DNS queries. – greenboxal Oct 21 '17 at 19:28
  • You should be able to configure this with your VPN/Firewall device. I use a fortinet Fortigate 60d and can configure an internal DNS server and an external one for my VPN connected users. Split-tunnel, etc. and disable recursion on the internal DNS server, this will prevent it from reaching out to the public roots. – Kyp Oct 21 '17 at 19:43
  • Time expired before it occurred to me to add this: That means that if your internal DNS server received a query it could not resolve with an internal domain, it would return NXDOMAIN instead of forwarding it somewhere. – Kyp Oct 21 '17 at 19:50
  • Do you need help with some SplitBrain DNS (resolving external namens from internal domain with the same name) or DNS resolver sequence (which DNS a client should ask first)? – bjoster Oct 27 '17 at 14:54

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.