Resolving zones inside two different views

Issues related to configuring your network
hchunduru
Posts: 3
Joined: 2017/10/11 12:21:48

Resolving zones inside two different views

Postby hchunduru » 2017/10/11 12:37:01

Hi,

I've two DNS servers, one is at DC1 (192.1.1.1) and another one is at DC2 (172.2.2.1)
I've a zone "example.com" under a view "DC1"
the zone example.com is pointing to a webserver 192.1.1.11

Another view "DC2" with same zone name "example.com" is pointing to a web server 172.2.2.22

named.conf

view "DC1"
{
match-clients { 192.1.1.0/24; }

zone "example.com"{
type "master";
file "db.example.dns1"; --> 192.1.1.11
}
};

view "DC2"
{
match-clients { any; };
zone "example.com"{
type master;
file "db.example.dns2"; --> 172.2.2.22
}
};

everything is working good when I use "dig example.com" from the dns1 server (192.1.1.1)
It is returning the IP address 192.1.1.11

When I shut down the machine (192.1.1.11) I should get the IP address of webserver (172.2.2.22) located at DC2 i.e, DNS 2 (172.2.2.2)

but it is not happening now, it is returning the IP 192.1.1.11 because the first view (DC1) is resolving the query since I made a request from the local subnet/Data center 1 (192.1.1.1)

How to get the IP address of webserver at DC2 (172.2.2.22) when the web server of DC1 (192.1.1.11) is down?

Please share your ideas..

Thank you.

Hari

User avatar
TrevorH
Forum Moderator
Posts: 21158
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Resolving zones inside two different views

Postby TrevorH » 2017/10/11 13:29:06

I think you're misunderstanding what view does: it resolves differently depending on the ip address used by the requesting client. So if you make the request from a machine with an ip in 192.1.1.0/24 you'll get the DC1 view and if you query from any other ip you will get the DC2 view.
CentOS 5 died in March 2017 - migrate NOW!
Full time Geek, part time moderator. Use the FAQ Luke

hchunduru
Posts: 3
Joined: 2017/10/11 12:21:48

Re: Resolving zones inside two different views

Postby hchunduru » 2017/10/12 06:21:19

Hi Trevor,

Thank you for your reply.

Yes view works based on the IP address of the requesting client but in my scenario I need to return the IP address of other web server (172.2.2.22 DC2) when the first webserver with IP address (192.1.1.11) is down.

If I place both IP address on the same view zone file, the browser is resolving the issue since the DNS return both IP addresses.

Eg:
example.com. A 192.1.1.11 # DC1
example.com. A 172.2.2.22 #DC2

In the above example when the webserver 192.1.1.11 is down the browser is trying with 172.2.2.22 and resolving the query but both the webservers are at different data centers! round robin is working by default and for the second request I get the IP 172.2.2.22 which would cause the latency issue.

To avoid that situation, I have come across the views and implemented but strucked at that failover scenario.


Thank you..

Hari

hchunduru
Posts: 3
Joined: 2017/10/11 12:21:48

Re: Resolving zones inside two different views

Postby hchunduru » 2017/10/12 17:34:57

Hi

I found the solution for this issue on Bind.

Replica for Round robin - rrset-order

rrset-order { order cyclic; };


fixed - records are returned in the order they are defined in the zone file
random - records are returned in a random order
cyclic - records are returned in a round-robin fashion

Replica for netmask ordering - sortlist

sortlist
{

{
198.1.1/24
{
198.1.1.0/24; //first preference
172.2.2.0/24; //2nd preference
};

//and so on.,

};

};

I've added two DC1 web servers for a zone "www.example.com"

http://www.example.com A 198.1.1.11 //DC1
http://www.example.com A 198.1.1.12 //DC1
http://www.example.com A 172.2.2.22 //DC2

When I make a request to the DNS server for the first time it returns .11, .12, .22 (order cyclic)
when I make another request (2nd request) to the DNS server it returns .12,.11,.22
for the 3rd request it returns .11, .12, .22
for the 4th it returns .12, .11, .22

172.2.2.22 is treating as least priority because it is at Data center 2 (172.2.2.0/24)

Thank you.

Hari