Should / Can I use DNS Records to list "Private Hosts in Private LANs"?

This is a theoretical Question: Given I have several Serves that both have a Public IP Address as well as a private IP Adress (192.xxx Range). Both Addesses are used for different Services. I do not want to work internally (for the private LAN) with IP Adresses but also with hostnames, as they are much better to remember:

Example: foobar.myhost.com => Public IP 222.xxx AND Private IP 192.xxx

I know I can use the /etc/network/hosts file to define all the "Private LAN) hostnames but this is very cumbersome and errorprone. As I do have to keep all these files in sync.

What are Best Practices / Your Optionions to use the standard public DNS Records (of my domain) to also list the private Names? Does this make sense? This does however reval the structure of my private LAN, is this good? And the Public DNS Records will then also list Private IPs (thats something I have never seen before).

And the biggest problem is: Actually I wanted to have one single hostname but this Hostname having both a public an private IP Address. Is there any possiblity to define both of these in the DNS Records (with the same name foobar.myhost.com) but to later differencitate between the private and pubplic IP Adresss?

Any good Blogpostings / Best Practices / Articles / Opinions are very much appreciated.

Thanks jens

Solution 1:

There are a number of different ways to achieve this. Obviously, you don't want to create A records for both the public and private IP addresses and publish those records for public consumption, because then users will try to access via the private IP. If multiple A records are listed for a single name, they will be used in a round robin resulting in users sometimes being unable to connect.

Here are a few solutions I've used:

My favorite solution is to create a DNS sub-zone for these servers, perhaps called "private.example.com". Then the servers in "example.com" that have private IP addresses I list in the "private.example.com" zone. Then configure your /etc/resolv.conf (probably via DHCP) so that when you are connected to the private network your DNS search path is "private.example.com example.com". Now, if you try to access "hostname", it will first try looking up "hostname.private.example.com." and then "hostname.example.com". So you any hosts in that domain that don't have private IPs you don't have to list in multiple places. You can also explicitly reference the public IP by saying "hostname.example.com" and similarly for the private IP. But if you just say "hostname" it will search for a match.

Note: If third-parties realize there is a "private.example.com" zone they may be able to query or "dig" it and see IP addressing. Revealing of this information may be of concern to you, depending on your exact requirements, but for my needs revealing some private IP addresses has never been a problem.

You can configure what BIND calls "views". Here's a link to another question that shows an example configuration of views. Basically, you configure Access Control Lists saying what zone file to use to answer the request based on what IP address is requesting it. So if you get a request from the private network, you could respond with the private IP. Views can be difficult to configure and maintain, however. There is also an issue of keeping duplicate copies of records in the different views, see my next suggestion for more details.

If your private network has a host you can run DHCP and DNS on which is separate from your public DNS server, you may want to set up DNS on this host as the default DNS server for machines in the private network, and then set up the DNS server to answer queries for these machines using the private IPs. However, if not all machines in the DNS zones you are interested in are going to have private IPs, this may lead to duplication of records where you now have to list IP addresses for servers in both DNS servers. Similar to Views above, but conceptually a little simpler to setup and test as you have completely separate DNS servers.

Solution 2:

Certainly listing the private IP range in the same server as the authoritative public addresses is a bad idea. However if you are running an internal server which is not authoritative for your domain (i.e. is only accessible by internal servers), then there's no technical issues about replicating the public addresses within the same zone as the private addresses (other than the issue of updating the addresses which are changed in the public server). Indeed, it makes a lot of sense to provide an internal DNS service.

A log time ago, I wrote a script for setting up Bind but note that this is primarily intended for scenarios where the internal addresses are on a separate domain from the public addresses. These days (if you're running on Unix/Linux/POSIX) dnsmasq is a better solution (with the added benefit of DHCP addresses).

Solution 3:

If you don't want to mess with BIND views for a small number of records (or are running a DNS server that doesn't have that functionality like, say, Microsoft DNS) you can create zones on your internal DNS servers that correspond to the FQDN's of the internal hosts that contain only an @ A record. The rest of the records in your domain would resolve via your Internet DNS. For the clients on your LAN that use the internal DNS servers the FQDN'S zones with LAN IPs specified would be returned (since the LAN DNS server would be authoritative for those names).

Solution 4:

Adding globally non-routable IP ranges to DNS can lead to confusion, when accessing in different LAN, because there can be other servers with that IP range, potentially allowing phising attacks when tricking user in accessing LAN system outside LAN.

Setup DNS server with recursion in LAN, if you haven`t got one, add revelant zones / records there and point LANs DHCP / computers there or use BIND views or corresponding feature of your DNS server, to show different zone from your LAN