Bind Easy Tutorial (2): Bind view Configuration

Directory:
Bind easy Tutorial (1): Installation and basic configuration
Bind Easy Tutorial (2): Bind view configuration (this article)
Bind easy Tutorial (3): DNSSEC configuration

The instrument says, we have aaa.apple.tree to 192.168.4.100. Then any person in the world in the request Aaa.apple.tree, the resolution is the IP address, and then access the domain name (of course, this IP address is only experimental, and my domain name is not registered, in addition to my intranet, no one in the world can access). Then the question came, two people one in the telecommunications, one in the Unicom, want to access this domain name, my server to put in which operator better? After all, "the furthest distance in the world, is not you in front of me I do not know you, but you in telecommunications, I am in Unicom." So can I now provide two servers, one placed in the telecommunications, one put in Unicom, then, let the telecommunications users query Aaa.apple.tree, the resolution to the telecommunications server up, Unicom users query aaa.apple.tree time, the resolution to the Unicom server up? The answer is yes, yes. That's what I'm going to talk about today. The advanced features of BIND: View query.

To configure a view, the main three steps are:

1. Collects a collection of IP addresses. For example, I now have a collection of 3 IP addresses, so that each collection can access a different address, that is, one IP in a collection provides another result when querying, providing a parse result, and another IP query in another set;
2. Provides a view for each IP collection. In this view, you need to write down which collection to which domain you can request.
3. Provides a parse file for each domain of each view.

Below, we assume 192.168.4.x this network segment is telecommunications, 192.168.1.x this network segment is Unicom, compare configuration view.
Write the IP collection first:
Telecom Address Collection: Dianxin.acl

ACL "Dianxin" {    192.168.4.0/24;};

Unicom Address Collection: Liantong.acl

ACL "Liantong" {    192.168.1.0/24;};

To write the view again:
Telco View: Dianxin.view

Include "/etc/bind/views/acls/dianxin.acl"; View "Dianxin" {    match-clients {"Dianxin";};    Zone "Apple.tree" in {        type master;        File "/etc/bind/views/zones/dianxin.apple.tree.zone";};    };

Unicom View: Liantong.view

Include "/etc/bind/views/acls/liantong.acl"; View "Liantong" {    match-clients {"Liantong";};    Zone "Apple.tree" in {        type master;        File "/etc/bind/views/zones/liantong.apple.tree.zone";};    };

Finally, the parsing of the domain:

Telecom Apple.tree Domain: Dianxin.apple.tree.zone

$TTL 86400@   in  SOA apple.tree. Apple.apple.tree. (          2016090100     ; Serial               28800     ; Refresh                7200     ; Retry              604800     ; Expire               86400     ; Negative Cache TTL) @   in  NS  apple.tree.@   in  a   192.168.4.43aaa     in      a       192.168.4.100bbb     in      A       192.168.4.101ccc     in      CNAME   BBB

Unicom apple.tree Domain: Liantong.apple.tree.zone

$TTL 86400@   in  SOA apple.tree. Apple.apple.tree. (          2016090100     ; Serial               28800     ; Refresh                7200     ; Retry              604800     ; Expire               86400     ; Negative Cache TTL) @   in  NS  apple.tree.@   in  a   192.168.4.43aaa     in      a       1.1.1.1bbb     in      A       2.2.2.2ccc     in      CNAME   BBB

Ok. This allows us to configure a set of telecom views and a set of unicom views (the so-called "Acl+view+zone" the three analysis).

If you like, you can also have a set of mobile views and a set of moving views, probably all of the sauce. Test it first (don't forget the sudo rndc reload load):
When I inquire from a telecommunications machine (192.168.4.43):

$ dig Aaa.apple.tree @192.168.4.43; <<>> DiG 9.9.5-3ubuntu0.8-ubuntu <<>> aaa.apple.tree @192.168.4.43; Global options: +cmd;; Got answer:;; ->>header<<-opcode:query, Status:noerror, id:57758; FLAGS:QR AA Rd; Query:1, Answer:1, authority:0, additional:1; Warning:recursion requested but not available;; OPT pseudosection:; edns:version:0, Flags:; udp:4096;; QUESTION Section:;aaa.apple.tree. in A;; ANSWER section:aaa.apple.tree. 86400 in A 192.168.4.100;; Query Time:4 msec;; server:192.168.4.43#53 (192.168.4.43); When:mon Jan 08:58:28 CST 2016;; MSG SIZE rcvd:59

And when I query from the Unicom machine (192.168.1.100):

$ dig Aaa.apple.tree @192.168.4.43; <<>> DiG 9.9.5-3ubuntu0.5-ubuntu <<>> aaa.apple.tree @192.168.4.43; Global options: +cmd;; Got answer:;; ->>header<<-opcode:query, Status:noerror, id:40018; FLAGS:QR AA Rd; Query:1, Answer:1, authority:0, additional:1; Warning:recursion requested but not available;; OPT pseudosection:; edns:version:0, Flags:; udp:4096;; QUESTION Section:;aaa.apple.tree. in A;; ANSWER section:aaa.apple.tree. 86400 in A 1.1.1.1;; Query Time:3 msec;; server:192.168.4.43#53 (192.168.4.43); When:sun Sep 12:32:56 CST 2016;; MSG SIZE rcvd:59

This is the view configuration. There is a question I have not introduced, that is: How do I know which IP is the IP of telecommunications, which is Unicom? If you have seen my blog before, you should have read this article, "Resolve the pure IP address library." Yes, write the program to get the IP collection for each carrier. What else can we get out of the brain? In addition to the operators, we can also divide the IP according to the region, write out the views of each province.

The Gospel of patients with intense phobias. I personally suggest that if you really want to configure the national provinces and even the city view, do not manually write the configuration file, write a script to generate it. Moreover, the memory of a machine may not hold, may have to consider the master and slave.
Even, we can use the combination of geographical and operator. Of course, this combination of different dimensions, need to have a way to resolve the conflict, for example, the telecommunications resolution to the P address, and Beijing resolution to the Q address. So what do you want Beijing telecom users to think? In fact, this is how bind is handled: first, when we collect IP collections, a Beijing telecom IP is both in the IP collection of Beijing, and in the IP collection of telecommunications, when the client accesses the DNS server, bind first matches the client IP, Find this IP belongs to a collection, it will query the corresponding view of the collection. Who first who? That depends on the order in which the two ACLs are loaded at named.conf. Who writes in front, who first loads. Bind does not consider this conflict to be an error. Saying this is not a mistake, Beijing telecom users belong to both Beijing and telecommunications, this is right Ah!
This is probably what the view configuration is about.

Bind Easy Tutorial (2): Bind view Configuration