Bind

WhyInstallation of a DNS server (bind) to allow to perform: recursive hostname resolution for a subset of clients, DNS zone management (ie: primary) and zone replication for other servers (ie: secondary).

Configuration

ACL

ACLs (Access Control List) are defined with the acl directive to limit or deny access to some resources. For this example, two distinct ACLs are used, one named can_xfr to list clients authorized to perform zone transfer, the other can_recurse to list clients allowed to ask for recursive name resolution.

acl can_xfr {      // Allow zone transfer
       217.70.177.40;        // ns6.gandi.net         (secondary | Gandi    )
       213.186.33.199;       // ns.kimsufi.com        (secondary | OVH      )
       127.0.0.1;            // loopback
       ::1;                  // loopback
};

acl can_recurse {  // Allow recursive name resolution
        2001:db8:0:1::/64;   // IPv6 for *.home.example.com
    192.168.1.0/24;          // IPv4 for *.home.example.com
    192.168.2.0/24;          // IPv4 for another network
};

Control

The named process can be controlled with the rndc command:

restrictions are put in place to allow access only from local host:

    controls {
        inet 127.0.0.1 port 953 allow { localhost; } keys { rndc-key; };
        inet ::1       port 953 allow { localhost; } keys { rndc-key; };
    };

authorization is done by knowing a shared secret:

Creating the shared secret can be done for the rndc.key file with the rndc-confgen command:
Creating shared secret (overwrites the rndc.key file)
```
rndc-confgen -a
```
```
    key "rndc-key" {
        algorithm hmac-sha256;
        secret Secret;
    };
```
```
include "rndc.key";
```

Logs

Log files are a way to keep a trace and monitor DNS server activity, and particularly to detect potential problems. The following configuration allows to record events either directly or through the syslog daemon.

Events corresponding to the configuration, the databases, or the notifications are transferred to syslog. If diagnostic or monitoring is needed, you can uncomment //1// to record all name resolution requests, and //2// to record dynamic zone updates — useful when a zone is being written to by something other than a hand edit.

logging {
        // Defining channels
        channel "null"           {  // Discard
                null;
        };

        channel "default_syslog" {  // Use syslog, with "info" severity
                syslog daemon;
                severity info;
        };

        channel "query_log"      {  // Record to the query.log file
                file "/var/log/query.log";
        };

        channel "debug"          {  // Record to the bind-debug.log file
                file "/var/log/bind-debug.log";
		print-time yes;
		print-category yes;
        };

        // Associate message categories and channels
//1//   category queries         { "query_log";      };
        category database        { "default_syslog"; };
        category config          { "default_syslog"; };
        category notify          { "default_syslog"; };
//2//   category update          { "default_syslog"; };
        category lame-servers    { "null";           };
};

Options

In this section are configured:

the path of files needed to run the DNS server or to setup some of the options;
the interfaces on which the server is listening: all interfaces (keyword any) in both IPv4 and IPv6 will be used.
the authorization for recursive name resolution: the localhost for both IPv4 and IPv6 and the list of hosts specified in the ACL can_recurse.

options {
	directory	"/usr/local/etc/namedb";
	pid-file	"/var/run/named/pid";
	dump-file	"/var/dump/named_dump.db";
	statistics-file	"/var/stats/named.stats";

	listen-on	{ any; };
	listen-on-v6	{ any; };

	allow-recursion {
		127.0.0.1; ::1;   // Loopback IPv4/IPv6
		can_recurse;      // List of authorized host
	};

//3//   forwarders {
//3//           192.168.200.2;
//3//   };
//4//   forward only;
};

By uncommenting //3//, it is possible to benefit from the existence of another name server, the one provided by the ISP for example, to resolve the requests in a first attempt (for which we do not have the zone), if this resolution fails, a fallback solution is applied and the resolution is directly performed by our server. By uncommenting //4//, the fallback solution is disabled.

Zones

In different records, if the names are not fully qualified, that is to say, do not refer to the root (ie: name not terminated by a “.”), then the origin $ORIGIN (by default the DNS current zone) will be automatically added.

Hint

So to start the delegation process and resolve name, it is necessary to know the server able to give information about the first zones: com, net, org, fr, eu, … The named.root file holds the list of the initial servers and is part of the bind distribution.

zone "." {
	type hint;
	file "named.root";
};

Primary

It defines a DNS zone. The zone description is detailed in the master/example.com file. The list of hosts authorised to perform a zone transfer (to allow a secondary zone to be set up) is indicated by ACLs and the allow-transfer directive.

zone "example.com" {
        type primary;
        file "master/example.com";
        allow-transfer { can_xfr; };
};

Secondary

The secondary type zone allows replication of a primary zone. You can then use several servers (through the NS records) to publish the zone, make this zone more reliable in case of a server loss or unavailability.

Information to give is: the filename where the zone will be saved, the address of the server holding the primary zone and at last, optionally, the address of the server authorised to notify us of possible modifications.

zone "sample.com" {
        type secondary;
        file "slave/sample.com";
        primaries { 192.168.3.5; };
        allow-notify { 192.168.3.5; };
};