on my lan i have two servers. One windows server 2008 and one debian webserver. I would like to configure my windows DNS to redirect all traffic on my lan to, for example "example.com" to my local webserver (on 192.168.10.24). How do i configure my windows DNS to do this kind of redirection?
Windows server 2008 DNS http redirect
domain-name-systemredirectwindows-server-2008
Related Solutions
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 address127.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 calledfake-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.
By 'DNS failover' I take it you mean DNS Round Robin combined with some monitoring, i.e. publishing multiple IP addresses for a DNS hostname, and removing a dead address when monitoring detects that a server is down. This can be workable for small, less trafficked websites.
By design, when you answer a DNS request you also provide a Time To Live (TTL) for the response you hand out. In other words, you're telling other DNS servers and caches "you may store this answer and use it for x minutes before checking back with me". The drawbacks come from this:
- With DNS failover, a unknown percentage of your users will have your DNS data cached with varying amounts of TTL left. Until the TTL expires these may connect to the dead server. There are faster ways of completing failover than this.
- Because of the above, you're inclined to set the TTL quite low, say 5-10 minutes. But setting it higher gives a (very small) performance benefit, and may help your DNS propagation work reliably even if there is a short glitch in network traffic. So using DNS based failover goes against high TTLs, but high TTLs are a part of DNS and can be useful.
The more common methods of getting good uptime involve:
- Placing servers together on the same LAN.
- Place the LAN in a datacenter with highly available power and network planes.
- Use a HTTP load balancer to spread load and fail over on individual server failures.
- Get the level of redundancy / expected uptime you require for your firewalls, load balancers and switches.
- Have a communication strategy in place for full-datacenter failures, and the occasional failure of a switch / database server / other resource that cannot easily be mirrored.
A very small minority of web sites use multi-datacenter setups, with 'geo-balancing' between datacenters.
Best Answer
Are you trying to do a URL redirect or just point example.com to 192.168.10.24?
if it's the latter, just create a zone called example.com with an A record of 192.168.10.24.
If you're trying to do *.example.com to example.com then you still will want an A record as above, but you would create a cname called *.example.com to point to example.com.
Then simply make sure your clients have your local DNS server pushed out (via DHCP).
If i misunderstood the request, let me know.