Assume you want to set up a LAN that provides all its systems and services to local users on internal systems, which may be behind a firewall, and only certain public servicessuch as Web, FTP, and mailto Internet (public) users. A split horizon (also called DMZ) DNS server takes care of this situation by treating queries from internal systems differently from queries from public systems (systems on the Internet).
View sections BIND 9 introduced View sections in named.conf. View sections facilitate the implementation of a split DNS server. Each view provides a different perspective of the DNS namespace to a group of clients. When there is no View section, all zones specified in named.conf are part of the implicit default view. Assume that an office has several systems on a LAN and public Web, FTP, DNS, and mail servers. The single connection to the Internet is NATed (page 1044) so that it is shared by the local systems and the servers. The gateway systemthe one connected directly to the Internetis a router, firewall, and server. This scenario takes advantage of the View sections in named.conf and supports separate secondary nameservers for local and public users. Although public users need access to the DNS server as the authority on the domain that supports the servers, they do not require the DNS server to support recursive queries. Not supporting recursion for public users limits the load on the DNS server and the Internet connection. For security reasons, public users must not have access to information about local systems other than the servers. Local users should have access to information about local systems and should be able to use the DNS server recursively. Figure 24-11 shows that the server responds differently to queries from the LAN and the Internet. Figure 24-11. A split horizon DNS serverThe iptables utility (page 763) controls which ports on which systems users on internal and external systems can access. DNS controls which systems are advertised to which users. The named.conf file has four sections: Options, two View sections, and Logging. The Options section specifies that the zone files are in the /var/named directory. The View sections specify the characteristics and zones that a resolver is given access to, which depend on the resolver's address. One zone is for use by the LAN/local users and the other by Internet/public users. The Logging section sets up the misc2.log file for default messages. There are several ways to specify which clients see a view. The following named.conf file uses match-clients statements: $ cat /etc/named.conf options { directory "/var/named"; }; //end options view "local" IN { // start local view match-clients { 127.0.0.1; 192.168.0.0/24;}; recursion YES; zone"zach.net" IN { type master; file "local.net"; notify YES; }; zone "0.168.192.in-addr.arpa" IN { type master; file "named.local"; notify YES; }; zone "." IN { type hint; file "named.ca"; }; }; // end local view view "public" IN { // start public view match-clients { "all";}; recursion NO; zone"zach.net" IN { type master; file "public.net"; notify YES; }; zone "0.168.192.in-addr.arpa" IN { type master; file "named.public"; notify YES; }; zone "." IN { type hint; file "named.ca"; }; }; // end public view logging{ channel "misc" { file "/var/log/bind/misc2.log" versions 2 size 1m; print-time YES; print-severity YES; print-category YES; }; category default { "misc"; }; }; //end logging The ordering of View sections within named.conf is critical: The view that is presented to a client is the first view that the client matches. The preceding named.conf file holds two View sections: one for local users and one for public users, in that order. Local users are defined to be those on the 192.168.0.0/24 subnet or localhost (127.0.0.1); public users are defined to be any users. If you reversed the order of the View sections, all usersincluding local userswould get the view intended for the public and no users would see the local view. Many statements from the Options section can be used within View sections, where they override statements in the (global) Options section. The recursion statement, which can appear within an Options section, appears in each View section. This named.conf file sets up a server that provides recursive answers to queries that originate locally and iterative answers to queries from the public. This setup provides quick, complete answers to local users, limiting the network and processor bandwidth that is devoted to other users while still providing authoritative name service for the local servers. To make named.conf easier to understand and maintain, zones in different View sections can have the same name while having different zone files. Both the local and public View sections in the example have zones named zach.net: The public zach.net zone file is named public.net, while the local one is named local.net. The Logging section is described on page 753. The zone files defining zach.net are similar to the ones in the previous examples; the public file is a subset of the local one. Following the SOA resource record in both files is a TXT, two NS, and two MX resource records. Next are three CNAME resource records that direct queries addressed to www.zach.net, ftp.zach.net, and mail.zach.net to the system named ns.zach.net. The next four resource records specify two nameserver addresses and two mail servers for the ns.zach.net domain. The final four resource records appear in the local zach.net zone file and not in the public zone file; they are address (A) resource records for local systems. Instead of keeping this information in /etc/hosts files on each system, you can keep it on the DNS server, where it can be updated easily. When you use DNS instead of /etc/hosts, you must change the hosts line in /etc/nsswitch.conf (page 435). $ cat local.net ; zach.net local zone file ; $TTL 3D @ IN SOA ns.zach.net. mgs@sobell.com. ( 200511118 ; serial 8H ; refresh 2H ; retry 4W ; expire 1D ) ; minimum IN TXT "Sobell Associates Inc." IN NS ns ; Nameserver address (unqualified) IN NS ns.speedy.net.; Nameserver address (qualified) IN MX 10 mail ; Mail exchange (primary/unqualified) IN MX 20 mail.max.net.; Mail exchange (2nd/qualified) www IN CNAME ns ftp IN CNAME ns mail IN CNAME ns ns IN A 192.168.0.1 IN A 192.168.0.6 IN MX 10 mail IN MX 20 mail.max.net. speedy IN A 192.168.0.1 grape IN A 192.168.0.3 potato IN A 192.168.0.4 peach IN A 192.168.0.6 The public version of the zach.net zone file follows: $ cat public.net ; zach.net public zone file ; $TTL 3D @ IN SOA ns.zach.net. mgs@sobell.com. ( 200511118 ; serial 8H ; refresh 2H ; retry 4W ; expire 1D ) ; minimum IN TXT "Sobell Associates Inc." IN NS ns ; Nameserver address(unqualified) IN NS ns.speedy.net.; Nameserver address (qualified) IN MX 10 mail; Mail exchange (primary/unqualified) IN MX 20 mail.max.net.; Mail exchange (2nd/qualified) www IN CNAME ns ftp IN CNAME ns mail IN CNAME ns ns IN A 192.168.0.1 IN A 192.168.0.6 IN MX 10 mail IN MX 20 mail.max.net. There are two reverse zone files, each of which starts with SOA and NS resource records followed by PTR resource records for each of the names of the servers. The local version of this file also lists the names of the local systems: $ cat named.local ;"0.168.192.in-addr.arpa" reverse zone file ; $TTL 3D @ IN SOA ns.zach.net. mgs@sobell.com. ( 2005110501 ; serial 8H ; refresh 2H ; retry 4W ; expire 1D) ; minimum IN NS ns.zach.net. IN NS ns.speedy.net. 1 IN PTR gw.zach.net. 1 IN PTR www.zach.net. 1 IN PTR ftp.zach.net. 1 IN PTR mail.zach.net. 1 IN PTR speedy.zach.net. 3 IN PTR grape.zach.net. 4 IN PTR potato.zach.net. 6 IN PTR peach.zach.net. |