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.
The best method is via the response policy zone in Bind 9.8.1 or newer. It allows you to override single records in arbitrary zones (and there's no need to create a whole subdomain for that, only the single record you want to change), it allows you to override CNAMEs, etc. Other solutions such as Unbound cannot override CNAMEs.
https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html
EDIT: Let's do this properly then. I will document what I've done based on the tutorial linked above.
My OS is Raspbian 4.4 for Raspberry Pi, but the technique should work without any changes on Debian and Ubuntu, or with minimal changes on other platforms.
Go to where your Bind config files are kept on your system - here it's in /etc/bind. Create in there a file called db.rpz with the following contents:
$TTL 60
@ IN SOA localhost. root.localhost. (
2015112501 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
localhost A 127.0.0.1
www.some-website.com A 127.0.0.1
www.other-website.com CNAME fake-hostname.com.
What does it do?
- it overrides the IP address for
www.some-website.com with the fake address 127.0.0.1, effectively sending all traffic for that site to the loopback address
- it sends traffic for
www.other-website.com to another site called fake-hostname.com
Anything that could go in a Bind zone file you can use here.
To activate these changes there are a few more steps:
Edit named.conf.local and add this section:
zone "rpz" {
type master;
file "/etc/bind/db.rpz";
};
The tutorial linked above tells you to add more stuff to zone "rpz" { } but that's not necessary in simple setups - what I've shown here is the minimum to make it work on your local resolver.
Edit named.conf.options and somewhere in the options { } section add the response-policy option:
options {
// bunch
// of
// stuff
// please
// ignore
response-policy { zone "rpz"; };
}
Now restart Bind:
service bind9 restart
That's it. The nameserver should begin overriding those records now.
If you need to make changes, just edit db.rpz, then restart Bind again.
Bonus: if you want to log DNS queries to syslog, so you can keep an eye on the proceedings, edit named.conf.local and make sure there's a logging section that includes these statements:
logging {
// stuff
// already
// there
channel my_syslog {
syslog daemon;
severity info;
};
category queries { my_syslog; };
};
Restart Bind again and that's it.
Test it on the machine running Bind:
dig @127.0.0.1 www.other-website.com. any
If you run dig on a different machine just use @the-ip-address-of-Bind-server instead of @127.0.0.1
I've used this technique with great success to override the CNAME for a website I was working on, sending it to a new AWS load balancer that I was just testing. A Raspberry Pi was used to run Bind, and the RPi was also configured to function as a WiFi router - so by connecting devices to the SSID running on the RPi I would get the DNS overrides I needed for testing.
Best Answer
Use at a Split DNS configuration in bind. You should be using this anyway to prevent the use of your bind server in amplification attacks. Once you have that running you proceed to a split configuration of your zone file.
Create a zone file for intranet (internal) users and another for Internet (external) users. Place only sub-domains that have different IP addresses in each file. Create a third file containing the rest of the IP addresses and include it in the first two zone files. I would place the serial number in the include file.
Using this configuration you will be able to edit in one place and reload. If you need to change the IP address of one of the servers which has different IP addresses for local and Internet users, you will need to increment the serial number in the third file.
The above approach may leak information about servers you don't want reachable from the Internet. You may be better using two zone files, one for intranet users, an the second for the Internet. If you plan your network well, IP addresses should only need to be changed in one file at time.
The zone file for the Internet should only contain information on domains you want to access from the Internet. It should only include Internet routeable IP addresses.
The zone file for the intranet can contain all the servers you want. It can include servers with private IP addresses: 10.0.0.0/8, 172.16.0.0/12, and/or 192.168.0.0/8. If you use a VPN, configure your split DNS to include VPN hosts on the intranet size.
EDIT: Work really hard at stabilizing the IP addresses visible on the Internet. I have yet to work on a project where they were dynamic. You really should have as few domains as possible visible from the Internet. They should all reside within a DMZ. If possible, multi-home IP address for domains that move frequently. If not, consider creating a sub-domain on the internet side where you change the IP addresses and use CNAMES to point to these records from both the Internet and intranet.
Server/services that must be exposed to the Internet include DNS, Web, SMTP (Mail), and VPN. Carefully consider the risk for other servers/services. (Multiple) Web domains are easily handled with CNAMES. In most cases, database servers should not be exposed to the Internet.