Views

In Chapter 8, I discussed split DNS and internal and external views of zones. BIND 8 requires different instances of BIND serving the different zone data. BIND 9 (and, in fact, 8.2) enables implementation of split DNS more easily with the view option. With a view set up, different clients can be answered from different zone data. So, an internal client can be answered from the full internal zone data, and an external client can be answered from the limited, externally available zone data all from one instance of BIND, instead of the two different BINDs required in the setup described in Chapter 8. The setup is as follows:

 view "internal" {     // This is the internal network, and the host itself:     match-clients {192.168.70.0/24; 127.0.0.1; };     recursion yes;  // Provide recursion to internal hosts     zone "penguin.bv" {         type master;         file "pz/full-penguin.bv";     }; }; view "external" {     match-clients { any; };     recursion no;  // No recursion to foreign cretins     zone "penguin.bv" {         type master;         file "pz/limited-penguin.bv";     }; }; 

The order of the view options is significant, as you might imagine. When the client address is matched, no further views are checked, and the zone data available in the matched view is presented to the client. The following is the full (implemented) syntax for views:

 view "view_name" [ ( in | hs | hesiod | chaos ) ] {   match-clients { address_match_list };   [ zone … ]   [ auth-nxdomain yes_or_no; ]   [ notify yes_or_no; ]   [ recursion yes_or_no; ]   [ also-notify { ip_addr; [ ip_addr; … ] }; ]   [ forward ( only | first ); ]   [ forwarders { [ in_addr ; [ in_addr ; … ] ] }; ]   [ allow-query { address_match_list }; ]   [ allow-transfer { address_match_list }; ]   [ allow-recursion { address_match_list }; ]   [ query-source … ]   [ query-source-v6 … ]   [ max-transfer-time-out number; ]   [ max-transfer-idle-out number; ]   [ max-cache-ttl number; ]   [ max-ncache-ttl number; ]   [ transfer-format ( one-answer | many-answers ); ]   [ transfer-source ip_addr; ]   [ transfer-source-v6 ip_addr; ]   [ request-ixfr yes_or_no; ]   [ provide-ixfr yes_or_no;]   [ cleaning-interval number; ]   [ key … ]   [ server … ]   [ trusted-keys … ] }; 

As you can see, this gives you quite a few possibilities in the way of differentiated service based on the client address. I for one have been missing this.