Since the previous answers to this question were written, there have been a couple of RFCs that alter the guidance somewhat. RFC 6761 discusses special-use domain names without providing specific guidance for private networks. RFC 6762 still recommends not using unregistered TLDs, but also acknowledges that there are cases where it will be done anyway. Since the commonly used .local conflicts with Multicast DNS (the main topic of the RFC), Appendix G. Private DNS Namespaces recommends the following TLDs:
- intranet
- internal
- private
- corp
- home
- lan
IANA appears to recognize both RFCs but does not (currently) incorporate the names listed in Appendix G.
In other words: you shouldn't do it. But when you decide to do it anyway, use one of the above names.
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.
Best Answer
Some people will say no public DNS records should ever disclose private IP addresses....with the thinking being that you are giving potential attackers a leg up on some information that might be required to exploit private systems.
Personally, I think that obfuscation is a poor form of security, especially when we are talking about IP addresses because in general they are easy to guess anyway, so I don't see this as a realistic security compromise.
The bigger consideration here is making sure your public users don't pickup this DNS record as part of the normal public services of your hosted application. ie: External DNS lookups somehow start resolving to an address they can't get to.
Aside from that, I see no fundamental reason why putting private address A records into the public space is a problem....especially when you have no alternate DNS server to host them on.
If you do decide to put this record into the public DNS space, you might consider creating a separate zone on the same server to hold all the "private" records. This will make it clearer that they are intended to be private....however for just one A record, I probably wouldn't bother.