You can use the DNS module of YaST to configure a DNS server for your local network. To configure a Samba server, start YaST and select Network Services+DNS Server. When starting the module for the first time, a wizard starts, prompting you to make just a few basic decisions concerning administration of the server. Completing this initial setup produces a very basic server configuration that should be functioning in its essential aspects. The expert mode can be used to deal with more advanced configuration tasks, such as setting up ACLs, logging, TSIG keys, and other options.

33.2.2. Expert Configuration¶

After starting the module, YaST opens a window displaying several configuration options. Completing it results in a DNS server configuration with the basic functions in place:

33.2.2.1. Starting the DNS Server¶

Under Service Start, define whether the DNS server should be started when the system boots (during booting the system) or manually. To start the DNS server immediately, select Start DNS Server Now. To stop the DNS server, select Stop DNS Server Now. To save the current settings, select Save Settings and Restart DNS Server Now. You can open the DNS port in the firewall with Open Port in Firewall and modify the firewall settings with Firewall Details.

By selecting LDAP Support Active, the zone files are managed by an LDAP database. Any changes to zone data written to the LDAP database are picked up by the DNS server as soon as it is restarted or prompted to reload its configuration.

33.2.2.2. DNS Server: Basic Options¶

In this section, set basic server options. From the Option menu, select the desired item then specify the value in the corresponding entry field. Include the new entry by selecting Add.

33.2.2.3. Logging¶

To set what the DNS server should log and how, select Logging. Under Log Type, specify where the DNS server should write the log data. Use the systemwide log file /var/log/messages by selecting System Log or specify a different file by selecting File. In the latter case, additionally specify a name, the maximum file size in megabytes, and the number of versions of log files to store.

Further options are available under Additional Logging. Enabling Log All DNS Queries causes every query to be logged, in which case the log file could grow extremely large. For this reason, it is not a good idea to enable this option for other than debugging purposes. To log the data traffic during zone updates between DHCP and DNS server, enable Log Zone Updates. To log the data traffic during a zone transfer from master to slave, enable Log Zone Transfer. See Figure 33.4, “DNS Server: Logging”.

Figure 33.4. DNS Server: Logging¶

33.2.2.4. Using ACLs¶

Use this window to define ACLs (access control lists) to enforce access restrictions. After providing a distinct name under Name, specify an IP address (with or without netmask) under Value in the following fashion:

{ 10.10/16; }

The syntax of the configuration file requires that the address ends with a semicolon and is put into curly braces.

33.2.2.5. TSIG Keys¶

The main purpose of TSIGs (transaction signatures) is to secure communications between DHCP and DNS servers. They are described in Section 33.7, “Secure Transactions”.

To generate a TSIG key, enter a distinctive name in the field labeled Key ID and specify the file where the key should be stored (Filename). Confirm your choices with Add.

To use a previously created key, leave the Key ID field blank and select the file where it is stored under File Name. After that, confirm with Add.

33.2.2.6. Adding a Slave Zone¶

To add a slave zone, select DNS Zones, choose the zone type Slave, and click Add.

In the Zone Editor under Master DNS Server IP, specify the master from which the slave should fetch its data. To limit access to the server, select one of the ACLs from the list. See Figure 33.5, “DNS Server: Slave Zone Editor”.

Figure 33.5. DNS Server: Slave Zone Editor¶

33.2.2.7. Adding a Master Zone¶

To add a master zone, select DNS Zones, choose the zone type Master, write the name of the new zone, and click Add.

33.2.2.8. Editing a Master Zone¶

To edit a master zone, select DNS Zones, choose the zone type Master, select the master zone from the table, and click Edit. The dialog consists of several pages: Basic (the one opened first), NS Records, MX Records, SOA, and Records.

The basic dialog, shown in Figure 33.6, “DNS Server: Zone Editor (Basic)”, lets you define settings for dynamic DNS and access options for zone transfers to clients and slave name servers. To permit the dynamic update of zones, select Allow Dynamic Updates as well as the corresponding TSIG key. The key must have been defined before the update action starts. To enable zone transfers, select the corresponding ACLs. ACLs must have been defined already.

Figure 33.6. DNS Server: Zone Editor (Basic)¶

Zone Editor (NS Records)

This dialog allows you to define alternative name servers for the zones specified. Make sure that your own name server is included in the list. To add a record, enter its name under Name Server to Add then confirm with Add. See Figure 33.7, “DNS Server: Zone Editor (NS Records)”.

Figure 33.7. DNS Server: Zone Editor (NS Records)¶

Zone Editor (MX Records)

To add a mail server for the current zone to the existing list, enter the corresponding address and priority value. After doing so, confirm by selecting Add. See Figure 33.8, “DNS Server: Zone Editor (MX Records)”.

Figure 33.8. DNS Server: Zone Editor (MX Records)¶

Zone Editor (SOA)

This page allows you to create SOA (start of authority) records. For an explanation of the individual options, refer to Example 33.6, “File /var/lib/named/world.zone”. Changing SOA records is not supported for dynamic zones managed via LDAP.

Figure 33.9. DNS Server: Zone Editor (SOA)¶

Zone Editor (Records)

This dialog manages name resolution. In Record Key, enter the hostname then select its type. A-Record represents the main entry. The value for this should be an IP address. CNAME is an alias. Use the types NS and MX for detailed or partial records that expand on the information provided in the NS Records and MX Records tabs. These three types resolve to an existing A record. PTR is for reverse zones. It is the opposite of an A record.

On a SUSE Linux Enterprise® system, the name server BIND (Berkeley Internet name domain) comes preconfigured so it can be started right after installation without any problem. If you already have a functioning Internet connection and have entered 127.0.0.1 as the name server address for localhost in /etc/resolv.conf, you normally already have a working name resolution without needing to know the DNS of the provider. BIND carries out name resolution via the root name server, a notably slower process. Normally, the DNS of the provider should be entered with its IP address in the configuration file /etc/named.conf under forwarders to ensure effective and secure name resolution. If this works so far, the name server runs as a pure caching-only name server. Only when you configure its own zones will it become a proper DNS. A simple example of this is included in the documentation in /usr/share/doc/packages/bind/config.

	Automatic Adaptation of the Name Server Information
Depending on the type of Internet connection or the network connection, the name server information can automatically be adapted to the current conditions. To do this, set the variable MODIFY_NAMED_CONF_DYNAMICALLY in the file /etc/sysconfig/network/config to yes.

However, do not set up any official domains until assigned one by the responsible institution. Even if you have your own domain and it is managed by the provider, you are better off not using it, because BIND would otherwise not forward requests for this domain. The Web server at the provider, for example, would not be accessible for this domain.

To start the name server, enter the command rcnamed start as root. If “done” appears to the right in green, named, as the name server process is called, has been started successfully. Test the name server immediately on the local system with the host or dig programs, which should return localhost as the default server with the address 127.0.0.1. If this is not the case, /etc/resolv.conf probably contains an incorrect name server entry or the file does not exist at all. For the first test, enter host 127.0.0.1, which should always work. If you get an error message, use rcnamed status to see whether the server is actually running. If the name server does not start or behaves unexpectedly, you can usually find the cause in the log file /var/log/messages.

To use the name server of the provider or one already running on your network as the forwarder, enter the corresponding IP address or addresses in the options section under forwarders. The addresses included in Example 33.1, “Forwarding Options in named.conf” are just examples. Adjust these entries to your own setup.

options { 
        directory "/var/lib/named";
        forwarders { 10.11.12.13; 10.11.12.14; };
        listen-on { 127.0.0.1; 192.168.0.99; };
        allow-query { 127/8; 192.168.0/24; };
        notify no;
        };

The options entry is followed by entries for the zone, localhost, and 0.0.127.in-addr.arpa. The type hint entry under “.” should always be present. The corresponding files do not need to be modified and should work as they are. Also make sure that each entry is closed with a “;” and that the curly braces are in the correct places. After changing the configuration file /etc/named.conf or the zone files, tell BIND to reread them with rcnamed reload. Achieve the same by stopping and restarting the name server with rcnamed restart. Stop the server at any time by entering rcnamed stop.

All the settings for the BIND name server itself are stored in the file /etc/named.conf. However, the zone data for the domains to handle, consisting of the hostnames, IP addresses, and so on, are stored in separate files in the /var/lib/named directory. The details of this are described later.

/etc/named.conf is roughly divided into two areas. One is the options section for general settings and the other consists of zone entries for the individual domains. A logging section and acl (access control list) entries are optional. Comment lines begin with a # sign or //. A minimal /etc/named.conf is shown in Example 33.2, “A Basic /etc/named.conf”.

options { 
        directory "/var/lib/named"; 
        forwarders { 10.0.0.1; };
        notify no;
};

zone "localhost" in {
       type master;
       file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.0.0.zone";
};

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

logging {
        category default { null; };
};

zone "my-domain.de" in {
      type master;
      file "my-domain.zone";
      notify no;
};

zone "other-domain.de" in {
      type slave;
      file "slave/other-domain.zone";
      masters { 10.0.0.1; }; 
};

Two types of zone files are needed. One assigns IP addresses to hostnames and the other does the reverse: it supplies a hostname for an IP address.

	Using the Dot in Zone Files
The . has an important meaning in the zone files. If hostnames are given without a final ., the zone is appended. Complete hostnames specified with a full domain name must end with a . to avoid having the domain added to it again. A missing or wrongly placed dot is probably the most frequent cause of name server configuration errors.

The first case to consider is the zone file world.zone, responsible for the domain world.cosmos, shown in Example 33.6, “File /var/lib/named/world.zone”.

$TTL 2D
world.cosmos. IN SOA      gateway  root.world.cosmos. (
            2003072441  ; serial
            1D          ; refresh
            2H          ; retry
            1W          ; expiry
            2D )        ; minimum

            IN NS       gateway
            IN MX       10 sun

gateway     IN A        192.168.0.1
            IN A        192.168.1.1
sun         IN A        192.168.0.2
moon        IN A        192.168.0.3
earth       IN A        192.168.1.2
mars        IN A        192.168.1.3
www         IN CNAME    moon

The pseudodomain in-addr.arpa is used for the reverse lookup of IP addresses into hostnames. It is appended to the network part of the address in reverse notation. So 192.168.1 is resolved into 1.168.192.in-addr.arpa. See Example 33.7, “Reverse Lookup”.

    

$TTL 2D
1.168.192.in-addr.arpa. IN SOA gateway.world.cosmos. root.world.cosmos. (
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           gateway.world.cosmos.

1                       IN PTR          gateway.world.cosmos.
2                       IN PTR          earth.world.cosmos.
3                       IN PTR          mars.world.cosmos.

Normally, zone transfers between different versions of BIND should be possible without any problem.

The term dynamic update refers to operations by which entries in the zone files of a master server are added, changed, or deleted. This mechanism is described in RFC 2136. Dynamic update is configured individually for each zone entry by adding an optional allow-update or update-policy rule. Zones to update dynamically should not be edited by hand.

Transmit the entries to update to the server with the command nsupdate. For the exact syntax of this command, check the manual page for nsupdate (man 8 nsupdate). For security reasons, any such update should be performed using TSIG keys as described in Section 33.7, “Secure Transactions”.

Secure transactions can be made with the help of transaction signatures (TSIGs) based on shared secret keys (also called TSIG keys). This section describes how to generate and use such keys.

Secure transactions are needed for communication between different servers and for the dynamic update of zone data. Making the access control dependent on keys is much more secure than merely relying on IP addresses.

Generate a TSIG key with the following command (for details, see man dnssec-keygen):

   dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2
  

This creates two files with names similar to these:

Khost1-host2.+157+34265.private Khost1-host2.+157+34265.key
  

The key itself (a string like ejIkuCyyGJwwuN3xAteKgg==) is found in both files. To use it for transactions, the second file (Khost1-host2.+157+34265.key) must be transferred to the remote host, preferably in a secure way (using scp, for example). On the remote server, the key must be included in the file /etc/named.conf to enable a secure communication between host1 and host2:

key host1-host2. {
 algorithm hmac-md5;
 secret ";ejIkuCyyGJwwuN3xAteKgg==;
};

File Permissions of /etc/named.conf

Make sure that the permissions of /etc/named.conf are properly restricted. The default for this file is 0640, with the owner being root and the group named. As an alternative, move the keys to an extra file with specially limited permissions, which is then included from /etc/named.conf. To include an external file, use: include "filename" Replace filename with an absolute path to your file with keys.

To enable the server host1 to use the key for host2 (which has the address 192.168.2.3 in this example), the server's /etc/named.conf must include the following rule:

server 192.168.2.3 {
  keys { host1-host2. ;};
};

Analogous entries must be included in the configuration files of host2.

Add TSIG keys for any ACLs (access control lists, not to be confused with file system ACLs) that are defined for IP addresses and address ranges to enable transaction security. The corresponding entry could look like this:

allow-update { key host1-host2. ;};

This topic is discussed in more detail in the BIND Administrator Reference Manual under update-policy.

DNSSEC, or DNS security, is described in RFC 2535. The tools available for DNSSEC are discussed in the BIND Manual.

A zone considered secure must have one or several zone keys associated with it. These are generated with dnssec-keygen, just like the host keys. The DSA encryption algorithm is currently used to generate these keys. The public keys generated should be included in the corresponding zone file with an $INCLUDE rule.

With the command dnssec-makekeyset, all keys generated are packaged into one set, which must then be transferred to the parent zone in a secure manner. On the parent, the set is signed with dnssec-signkey. The files generated by this command are then used to sign the zones with dnssec-signzone, which in turn generates the files to include for each zone in /etc/named.conf.

For additional information, refer to the BIND Administrator Reference Manual from package bind-doc, which is installed under /usr/share/doc/packages/bind/. Consider additionally consulting the RFCs referenced by the manual and the manual pages included with BIND. /usr/share/doc/packages/bind/README.SuSE contains up-to-date information about BIND in SUSE Linux Enterprise.