| SUSE LINUX Enterprise Server – Installation and Administration Chapter 21. Linux in the Network / 21.7. DNS — Domain Name System | ||||
|---|---|---|---|---|
 | 21.6. SLP Services in the Network | 21.8. LDAP — A Directory Service |  | |
| SUSE LINUX Enterprise Server – Installation and Administration Chapter 21. Linux in the Network / 21.7. DNS — Domain Name System | ||||
|---|---|---|---|---|
| 21.6. SLP Services in the Network | 21.8. LDAP — A Directory Service | | |
DNS (domain name system) is needed to resolve the domain and host names into IP addresses. In this way, the IP address 192.168.0.0 is assigned to the host name earth, for example. Before setting up your own name server, read the general information about DNS in Section 21.1.3. “Domain Name System”. The configuration examples below are only valid for BIND 9.
On a SUSE LINUX 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 the 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 as /usr/share/doc/packages/bind/sample-config.
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 to use it, as BIND would otherwise not forward any more requests for this domain. The provider's web server, 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 in an unexpected way, 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 21.10. “Forwarding Options in named.conf” are just examples. Adjust these entries according to your own setup.
Example 21.10. Forwarding Options in named.conf
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, for localhost, 0.0.127.in-addr.arpa, and the type hint entry under “.”, which should always be present. The corresponding files do not need to be modified and should work as is. 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 host names, IP addresses, and so on, are stored in separate files in the /var/lib/named directory. The details of this are described further below.
/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 minimalistic /etc/named.conf is shown in Example 21.11. “A Basic /etc/named.conf”.
Example 21.11. 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";
};![[Important]](admon/important.png) | Further Information on BIND |
|---|---|
Refer to /usr/share/doc/packages/bind/README.SuSE for further up-to-date information on BIND in SUSE LINUX. | |
Specifies the directory where BIND can find the files containing the zone data.
Specifies the name servers (mostly of the provider) to which DNS requests should be forwarded if they cannot be resolved directly.
Causes DNS requests to be forwarded before an attempt is made to resolve them via the root name servers. Instead of forward first, forward only can be written to have all requests forwarded and none sent to the root name servers. This makes sense for firewall configurations.
Tells BIND to which network interface and port to listen. The port 53 specification can be left out, as 53 is the default port. If this entry is completely omitted, BIND accepts requests on all interfaces.
Tells BIND on which port it should listen for IPv6 client requests. The only alternative to any is none. As far as IPv6 is concerned, the server only accepts a wild card address.
This entry is necessary if a firewall is blocking outgoing DNS requests. This tells BIND to post requests externally from port 53 and not from any of the high ports above 1024.
Tells BIND which port to use for IPv6 queries.
Defines the networks from which clients can post DNS requests. The /24 at the end is an abbreviated expression for the netmask, in this case, 255.255.255.0.
controls which hosts can request zone transfers. In the example, such requests are completely denied with ! *. Without this entry, zone transfers can be requested from anywhere without restrictions.
In the absence of this entry, BIND generates several lines of statistical information per hour in /var/log/messages. Specify 0 to completely suppress such statistics or specify an interval in minutes.
This option defines at which time intervals BIND clears its cache. This triggers an entry in /var/log/messages each time it occurs. The time specification is in minutes. The default is sixty minutes.
BIND regularly searches the network interfaces for new or nonexisting interfaces. If this value is set to 0, this is not done and BIND only listens at the interfaces detected at start-up. Otherwise, the interval can be defined in minutes. The default is sixty minutes.
no prevents other name servers from being informed when changes are made to the zone data or when the name server is restarted.
What, how, and where logging takes place can be extensively configured in BIND. Normally, the default settings should be sufficient. Example 21.12. “Entry to Disable Logging” shows the simplest form of such an entry and completely suppresses any logging.
Example 21.13. Zone Entry for my-domain.de
zone "my-domain.de" in {
type master;
file "my-domain.zone";
notify no;
};After zone, specify the name of the domain to administer, my-domain.de, followed by in and a block of relevant options enclosed in curly braces, as shown in Example 21.13. “Zone Entry for my-domain.de”. To define a slave zone, switch the type to slave and specify a name server that administers this zone as master (which, in turn, may be a slave of another master), as shown in Example 21.14. “Zone Entry for other-domain.de”.
Example 21.14. Zone Entry for other-domain.de
zone "other-domain.de" in {
type slave;
file "slave/other-domain.zone";
masters { 10.0.0.1; };
};The zone options:
By specifying master, tell BIND that the zone is handled by the local name server. This assumes that a zone file has been created in the correct format.
This zone is transferred from another name server. It must be used together with masters.
The zone . of the hint type is used to set the root name servers. This zone definition can be left as is.
This entry specifies the file where zone data for the domain is located. This file is not required for a slave, as this data is fetched from another name server. To differentiate master and slave files, use the directory slave for the slave files.
This entry is only needed for slave zones. It specifies from which name server the zone file should be transferred.
This option controls external write access, which would allow clients to make a DNS entry — something not normally desirable for security reasons. Without this entry, zone updates are not allowed at all. The above entry achieves the same because ! * effectively bans any such activity.
Two types of zone files are needed. One assigns IP addresses to host names and the other does the reverse — supplies a host name for an IP address.
![[Tip]](admon/tip.png) | Using the Dot in Zone Files |
|---|---|
The . has an important meaning in the zone files. If host names are given without a final ., the zone is appended. Complete host names 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 21.15. “File /var/lib/named/world.zone”.
Example 21.15. 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
$TTL defines the default time to live that should apply to all the entries in this file. In this example, entries are valid for a period of two days (2 D).
This is where the SOA (start of authority) control record begins:
The name of the domain to administer is world.cosmos in the first position. This ends with a ., because otherwise the zone would be appended a second time. Alternatively, @ can be entered here, in which case the zone would be extracted from the corresponding entry in /etc/named.conf.
After IN SOA is the name of the name server in charge as master for this zone. The name is expanded from gateway to gateway.world.cosmos, because it does not end with a ..
An e-mail address of the person in charge of this name server follows. Because the @ sign already has a special meaning, . is entered here instead. For root@world.cosmos the entry must read root.world.cosmos.. The . must be included at the end to prevent the zone from being added.
The ( includes all lines up to ) into the SOA record.
The serial number is an arbitrary number that is increased each time this file is changed. It is needed to inform the secondary name servers (slave servers) of changes. For this, a ten-digit number of the date and run number, written as YYYYMMDDNN, has become the customary format.
The refresh rate specifies the time interval at which the secondary name servers verify the zone serial number. In this case, one day.
The retry rate specifies the time interval at which a secondary name server, in case of error, attempts to contact the primary server again. Here, two hours.
The expiration time specifies the time frame after which a secondary name server discards the cached data if it has not regained contact to the primary server. Here, it is a week.
The last entry in the SOA record specifies the negative caching TTL — the time for which results of unresolved DNS queries from other servers may be cached.
The IN NS specifies the name server responsible for this domain. gateway is extended to gateway.world.cosmos because it does not end with a .. There can be several lines like this — one for the primary and one for each secondary name server. If notify is not set to no in /etc/named.conf, all the name servers listed here are informed of the changes made to the zone data.
The MX record specifies the mail server that accepts, processes, and forwards e-mails for the domain world.cosmos. In this example, this is the host sun.world.cosmos. The number in front of the host name is the preference value. If there are multiple MX entries, the mail server with the smallest value is taken first and, if mail delivery to this server fails, an attempt is made with the next higher value.
These are the actual address records where one or more IP addresses are assigned to host names. The names are listed here without a . because they do not include their domain, so world.cosmos is added to all of them. Two IP addresses are assigned to the host gateway, because it has two network cards. Wherever the host address is a traditional one (IPv4), the record is marked with A. If the address is an IPv6 address, the entry is marked with A6. (The previous token for IPv6 addresses was AAAA, which is now obsolete.)
The alias www can be used to address mond (CNAME means canonical name).
The pseudodomain in-addr.arpa is used for the reverse lookup of IP addresses into host names. 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 21.16. “Reverse Lookup”.
Example 21.16. 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.
$TTL defines the standard TTL that applies to all entries here.
The configuration file should activate reverse lookup for the network 192.168.1.0. Given that the zone is called 1.168.192.in-addr.arpa, should not be added to the host names. Therefore, all host names are entered in their complete form — with their domain and with a . at the end. The remaining entries correspond to those described for the previous world.cosmos example.
See the previous example for world.cosmos.
Again this line specifies the name server responsible for this zone. This time, however, the name is entered in its complete form with the domain and a . at the end.
These are the pointer records hinting at the IP addresses on the respective hosts. Only the last part of the IP address is entered at the beginning of the line, without the . at the end. Appending the zone to this (without the .in-addr.arpa) results in the complete IP address in reverse order.
Normally, zone transfers between different versions of BIND should be possible without any problem.
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 the 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 instance). 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==;
};![[Warning]](admon/warning.png) | File Permissions of /etc/named.conf |
|---|---|
Make sure 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 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.
In addition to any ACLs (Access Control Lists — not to be confused with filesystem ACLs) that are defined for IP addresses and address ranges, add TSIG keys for these 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.
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 21.7.7. “Secure Transactions”.
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. Currently the DSA encryption algorithm is 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.
You can use the DNS module of YaST to configure a DNS server for your local network. The module can work in two different modes:
When starting the module for the first time, you will be prompted to make just a few basic decisions concerning the server administration. 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 the more advanced configuration tasks, such as setting up ACLs, logging, TSIG keys, and other options.
The wizard consists of three steps or dialogs. At the appropriate places in the dialogs, you are given the opportunity to enter the expert configuration mode.
When starting the module for the first time, see the dialog shown in Figure 21.9. “DNS Server Installation: Forwarder Settings”. It allows you to decide whether the PPP daemon should provide a list of forwarders on dial-up via DSL or ISDN (PPP Daemon Sets Forwarders) or whether you want to supply your own list (Set Forwarders Manually).
The individual entries shown are explained in the discussion of the expert configuration (see Section DNS Server: DNS Zones).
In the final step, specify whether the DNS server should always be started as part of the boot procedure and whether it should use LDAP support. See Figure 21.10. “DNS Server Installation: Finish Wizard”.
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:
Under Booting, define whether the DNS server should be On or Off by default. To start the DNS server right away, select .
By selecting LDAP Support Active, have the zone files managed by an LDAP database. Any changes of zone data as written to the LDAP database are picked up by the DNS server as soon as it is restarted or prompted to reload its configuration.
This is the same dialog as the one opened after starting the wizard configuration (see Section DNS Server Installation: Forwarder Settings).
In this section, set basic server options. From the menu, select the desired item then specify the value in the corresponding entry field. Include the new entry by selecting .
This section allows you to set options concerning the contents and the location of the DNS server's log data. Under Log Type, specify where the DNS server should write its log data. Use the system-wide log file /var/log/messages by selecting Log to System Log orspecify a different file by selecting Log to File. In the latter case, additionally specify the maximum file size in megabytes and the number of log files to store.
Further options are available under Additional Logging: Enabling Log Named 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 21.11. “DNS Server: Logging”.
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.
The main purpose of TSIGs (transaction signatures) is to secure communications between DHCP and DNS servers. They are described in Section 21.7.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 (File Name). Confirm your choices with .
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 .
This part of the configuration uses several dialogs to configure the management of zone files (see Section 21.7.6. “Structure of Zone Files”). For a new zone, provide a name for it in Zone Name. To add a reverse zone, the name must end in .in-addr.arpa. Finally, select the Zone Type (master or slave). See Figure 21.12. “DNS Server: DNS Zones”. For each zone, set additional options after selecting .
This dialog opens if you select the zone type Slave in the step described in Section DNS Server: DNS Zones. Under Master DNS Server, specify the master from which the slave shall fetch its data. To limit access to the server, you can select one of the previously defined ACLs from the list. See Figure 21.13. “DNS Server: Slave Zone Editor”.
This dialog is opened if you selected the zone type Master in the step described in Section DNS Server: DNS Zones. The dialog comprises several pages: Basic (the one opened first), NS Records, MX Records, SOA, and Records. For each of these pages, find a description in the following paragraphs.
The dialog shown in Figure 21.14. “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.
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 .
To add a mail server for the current zone to the existing list, enter the corresponding address and the priority value. After doing so, confirm by selecting .
This page allows you to create SOA (start of authority) records. For an explanation of the individual options, refer to Example 21.15. “File /var/lib/named/world.zone”. Please note that the changing SOA records is not supported for dynamic zones managed via LDAP.
This dialog lets you manage a list of IP addresses and the corresponding names as assigned to them. In Name, enter the host name then select its type. A-Record represents the main entry. CNAME is an alias. Under MX-Relay the entry (name) is replaced with its value.
