DNS – How to Provide Different IP for Server Based on Client Network with Unbound

domain-name-systemsplit-dnsunbound

We have an intranet DNS server using Unbound in FreeBSD. We have another file server with multiple network IP, First one is 10.10.10.10 and Second one in 192.168.10.10.

Is there any way that DNS server provide different IP for this file server based on the client network?

Eg:
For the user from 10.10.x.x network, fileserver ip should be 10.10.10.10
For the user from 192.168.x.x network, fileserver ip should be 192.168.10.10.

Best Answer

How to provide different IP for a server based on client network

The jargon for that is normally "split horizon DNS".

In Unbound that is implemented via "tags and views" functionality. Those make it possible to send specific DNS answers based on the IP address of the client.

The tags functionality makes it possible to divide client source addresses in categories (tags), and use local-zone and local-data information for these specific tags.

A view is a named list of configuration options. The supported view configuration options are local-zone and local-data.

A view is configured using a view clause. There may be multiple view clauses, each with a unique name. For example:
view:
    name: "firstview"
    local-zone: example.com inform
    local-data: 'example.com TXT "this is an example"'
    local-zone: refused.example.nl refuse
...

Mapping a view to a client can be done using the access-control-view element:
 access-control-view: 10.0.5.0/24 firstview

Related Solutions

Why is DNS failover not recommended

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.

Dns – BIND – how to return a different IP based on request’s subnet

You need to use views:

view "officeA" {
   match-clients { 192.168.1.0/24; };

   include "/etc/named.conf.zones-rfc1912";
   include "/etc/named.conf.zones-common";
   include "/etc/named.conf.zones-officeA";
};

view "officeB" {
   match-clients { 192.168.2.0/24; };

   include "/etc/named.conf.zones-rfc1912";
   include "/etc/named.conf.zones-common";
   include "/etc/named.conf.zones-officeB";
};

Best Answer

Related Solutions

Why is DNS failover not recommended

Dns – BIND – how to return a different IP based on request’s subnet

Related Topic