This short excerpt from an Informit article on building Linux VPNs examines how to properly set up DNS for your...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
One often-overlooked requirement of a functioning VPN is DNS. For any host-network or network-network VPN, you will be enabling access to machines that are not available on the Internet at large. Unless you want to access machines only by their IP address, you want to have DNS work cleanly.
The easiest way to accomplish this is to create a new domain name for your internal networks. Let's say our company owns example.com, which we use for our external systems. We could create chicago.example.com and atlanta.example.com as internal domain names. We then would run a DNS server internally to support those domains.
Let's assume we install a DNS server on the internal machines Cubs and Braves. We can make Cubs authoritative for the chicago.example.com domain and Braves authoritative for the atlanta.example.com domain. We set up each machine to be secondary for the internal domains it does not serve, which will enable them to send updates cleanly between them.
You then configure Cubs and Braves to relay all other queries to an external DNS server (say, one at your ISP), making sure you have recursive queries allowed from internal addresses. You configure all your internal machines to use Cubs and Braves as their DNS servers, preferring whichever is on the local network to avoid sending DNS traffic across the VPN.
Let's say a user on Bulls wants the IP address for thrashers.atlanta.example.com. Cubs already knows the answer because it is a secondary DNS server for the domain. Should Bulls request the IP for http://www.buildinglinuxvpns.net, Cubs will forward the query to an external DNS server and return the answer to Bulls when it is received.
This situation works seamlessly for all hosts on networks that are connected via dedicated VPNs. The only tricky situation is supporting roaming users. Because those VPNs are created only periodically and the users might want to be connected to the Internet without using the VPN, you cannot hard-code their DNS setting to use the internal DNS servers.
If possible, configure their machines to use the internal DNS servers only when the VPN is active. This can be done by munging the ip-up script when using a PPP-related VPN, for example, or by any other method you desire to rewrite /etc/resolv.conf when the VPN is established.
The worst-case scenario (next to remembering IP addresses, that is) is to simply point first to an internal DNS server and then to an external server, as seen here:
$ cat /etc/resolv.conf search chicago.example.com example.com nameserver 192.168.1.10 # cubs nameserver 3220.127.116.11 # My ISP
The internal DNS server Cubs (192.168.1.10) is first in the list. If the VPN is available, Cubs will handle your DNS requests for both internal and external domains. If the VPN is not up, the DNS request to Cubs will fail, and your machine will then query 318.104.22.168. This machine will be able to respond for all Internet addresses but not the internal chicago.example.com addresses. This is not a problem, however, because the internal addresses aren't available except when the VPN is running anyway.
You will experience some name-resolution lag when using such a setup when the VPN is not established. DNS queries contact hosts in the order specified in /etc/resolv.conf, only moving onto the next in the list after determining that the first server isn't responding. Some resolver libraries try to consider this and will stop asking a nonresponding server for a while.
Read more of this article on Linux VPNs at Informit.