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.
Well, the client's on the outside interface - DNS doctoring is behaving exactly as intended, really.
Do you actually need DNS doctoring enabled on that translation? Are you serving public DNS from an internal server with the internal addresses, and just having doctoring catch that address on the way out the door?
If not, then just tear the dns off of your static line and you're all set.
If so, consider setting up a DNS server that just serves public DNS.
If you're set on keeping doctoring enabled, then I can think of one ugly workaround that should do it: two policy static translations - one for when the destination is internal with DNS doctoring disabled, then a lower priority one with doctoring enabled. Like I said: ugly.
Best Answer
Not everyone's network uses devices that can NAT at LAN speeds. It's not unusual to have devices that can route 100Mb/s but NAT a tenth of that while your LAN is all gigabit.
Often you have servers in the DMZ that you need high-speed access to locally. You want to back up your mail and web servers, right? And do you want your backups in the DMZ?
NAT also breaks long-lived, idle connections because the translation times out. Hairpin obscures the origin IP address, making audit trails useless. NAT, other than 1-to-1, is a painful hack, and you want internal traffic to be reliable.
Attack resistance is another issue. Connection flooding can cause your NAT device to run out of slots and there are companies that reboot their Internet-facing equipment regularly and would prefer not to disturb long-lived internal connections. Even if your equipment is entirely reliable, separating the internal network from the devices that handle the public IP space is just a good idea.