systemd
Daemonjournalctl
: Query the systemd
Journaludev
DNS (domain name system) is needed to resolve the domain names and host
names into IP addresses. In this way, the IP address 192.168.2.100 is
assigned to the host name jupiter
, for example.
Before setting up your own name server, read the general information
about DNS in Section 13.3, “Name Resolution”. The following
configuration examples refer to BIND, the default DNS server.
The domain name space is divided into regions called zones. For
instance, if you have example.com
, you have
the example
section (or zone) of the
com
domain.
The DNS server is a server that maintains the name and IP information for a domain. You can have a primary DNS server for master zone, a secondary server for slave zone, or a slave server without any zones for caching.
The master zone includes all hosts from your network and a DNS server master zone stores up-to-date records for all the hosts in your domain.
A slave zone is a copy of the master zone. The slave zone DNS server obtains its zone data with zone transfer operations from its master server. The slave zone DNS server responds authoritatively for the zone as long as it has valid (not expired) zone data. If the slave cannot obtain a new copy of the zone data, it stops responding for the zone.
Forwarders are DNS servers to which your DNS server should send
queries it cannot answer. To enable different configuration sources in
one configuration, netconfig
is used (see also
man 8 netconfig
).
The record is information about name and IP address. Supported records and their syntax are described in BIND documentation. Some special records are:
An NS record tells name servers which machines are in charge of a given domain zone.
The MX (mail exchange) records describe the machines to contact for directing mail across the Internet.
SOA (Start of Authority) record is the first record in a zone file. The SOA record is used when using DNS to synchronize data between multiple computers.
To install a DNS server, start YaST and select
› . Choose › and select . Confirm the installation of the dependent packages to finish the installation process.Use the YaST DNS module to configure a DNS server for the local network. When starting the module for the first time, a wizard starts, prompting you to make a few decisions concerning administration of the server. Completing this initial setup produces a basic server configuration. Use the expert mode to deal with 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 can enter the expert configuration mode.
When starting the module for the first time, the Figure 19.1, “DNS Server Installation: Forwarder Settings”, opens. The allows to set the following options:
dialog, shown in
auto
, but here you can
either set interface names or select from the two special policy
names STATIC
and
STATIC_FALLBACK
.
In
, specify which service to use: , , or .
For more information about all these settings, see man 8
netconfig
.
Forwarders are DNS servers to which your DNS server sends queries it cannot answer itself. Enter their IP address and click
.
The Section 19.6, “Zone Files”. For a new zone, provide a name for
it in . To add a reverse zone, the name must
end in .in-addr.arpa
. Finally, select the
(master, slave, or forward). See
Figure 19.2, “DNS Server Installation: DNS Zones”. Click to configure other settings of an existing zone. To remove
a zone, click .
In the final dialog, you can open the DNS port in the firewall by clicking Figure 19.3, “DNS Server Installation: Finish Wizard”.
. Then decide whether to start the DNS server when booting ( or ). You can also activate LDAP support. SeeAfter 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
, define whether the DNS server should be started when the booting the system or manually. To start the DNS server immediately, click . To stop the DNS server, click . To save the current settings, select . You can open the DNS port in the firewall with and modify the firewall settings with .By selecting
, 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.
If your local DNS server cannot answer a request, it tries to forward
the request to a man 8
netconfig
.
In this section, set basic server options. From the
menu, select the desired item then specify the value in the corresponding text box. Include the new entry by selecting .To set what the DNS server should log and how, select
. Under , specify where the DNS server should write the log data. Use the system-wide log by selecting or specify a different file by selecting . In the latter case, additionally specify a name, the maximum file size in megabytes and the number of log file versions to store.Further options are available under 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 . To log the data traffic during a zone transfer from master to slave, enable . See Figure 19.4, “DNS Server: Logging”.
. Enabling causesUse this dialog to define ACLs (access control lists) to enforce access restrictions. After providing a distinct name under
, specify an IP address (with or without netmask) under in the following fashion:{ 192.168.1/24; }
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 19.8, “Secure Transactions”.
To generate a TSIG key, enter a distinctive name in the field labeled
and specify the file where the key should be stored ( ). Confirm your choices with .To use a previously created key, leave the
field blank and select the file where it is stored under . After that, confirm with .To add a slave zone, select
, choose the zone type , write the name of the new zone, and click .In the
sub-dialog under , specify the master from which the slave should pull its data. To limit access to the server, select one of the ACLs from the list.
To add a master zone, select example.com
that points to hosts in a subnet
192.168.1.0/24
, you should also add a reverse zone
for the IP-address range covered. By definition, this should be named
1.168.192.in-addr.arpa
.
To edit a master zone, select
, select the master zone from the table, and click . The dialog consists of several pages: (the one opened first), , , , and .The basic dialog, shown in Figure 19.5, “DNS Server: Zone Editor (Basics)”, lets you define settings for dynamic DNS and access options for zone transfers to clients and slave name servers. To permit the dynamic updating of zones, select 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.
In the
dialog, select whether to enable zone transfers. Use the listed ACLs to define who can download zones.The Figure 19.6, “DNS Server: Zone Editor (NS Records)”.
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 then confirm with . SeeTo 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 Figure 19.7, “DNS Server: Zone Editor (MX Records)”.
. SeeThis page allows you to create SOA (start of authority) records. For an explanation of the individual options, refer to Example 19.6, “The /var/lib/named/example.com.zone File”. Changing SOA records is not supported for dynamic zones managed via LDAP.
This dialog manages name resolution. In A
record. is for reverse zones. It is the
opposite of an A
record, for example:
hostname.example.com. IN A 192.168.0.1 1.0.168.192.in-addr.arpa IN PTR hostname.example.com.
To add a reverse zone, follow this procedure:
Start
› › .If you have not added a master forward zone, add it and
it.In the
tab, fill the corresponding and , then add the record with and confirm with . If YaST complains about a non-existing record for a name server, add it in the tab.Back in the
window, add a reverse master zone.the reverse zone, and in the tab, you can see the record type. Add the corresponding and , then click and confirm with .
Add a name server record if needed.
After adding a forward zone, go back to the main menu and select the reverse zone for editing. There in the tab
activate the check box and select your forward zone. That way, all changes to the forward zone are automatically updated in the reverse zone.
On a openSUSE® Leap system, the name server BIND (Berkeley
Internet Name Domain) comes preconfigured so it can be started
right after installation without any problems. 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 it becomes a proper DNS. Find a simple example documented
in /usr/share/doc/packages/bind/config
.
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
NETCONFIG_DNS_POLICY
variable in the
/etc/sysconfig/network/config
file to
auto
.
However, do not set up an official domain until one is assigned to you 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 systemctl start
named
as
root
. Check with
systemctl status named
whether 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. For the
first test, enter
host
127.0.0.1
, which should
always work. If you get an error message, use systemctl status
named
to see whether the server is actually running. If
the name server does not start or behaves unexpectedly, check the output
of journalctl -e
.
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 19.1, “Forwarding Options in named.conf” are examples only. 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.1.116; }; allow-query { 127/8; 192.168/16 }; 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 systemctl reload
named
. Achieve the same by stopping and restarting the
name server with systemctl restart named
. Stop
the server at any time by entering systemctl stop
named
.
All the settings for the BIND name server itself are stored in the
/etc/named.conf
file. 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 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 19.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"; };
Specifies the directory in which BIND can find the files containing
the zone data. Usually, this is /var/lib/named
.
Specifies the name servers (mostly of the provider) to which DNS
requests should be forwarded if they cannot be resolved directly.
Replace ip-address with an IP address like
192.168.1.116
.
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 on which network interfaces and port to accept client
queries. port 53
does not need to be specified
explicitly, because 53
is the default port. Enter
127.0.0.1
to permit requests from the local host.
If you omit this entry entirely, all interfaces are used by default.
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 wild card addresses.
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.
Replace net with address information like
192.168.2.0/24
. 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 the system's journal. Set it to 0 to suppress these statistics completely or set an interval in minutes.
This option defines at which time intervals BIND clears its cache. This triggers an entry in the system's journal each time it occurs. The time specification is in minutes. The default is 60 minutes.
BIND regularly searches the network interfaces for new or nonexistent
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.
For a list of available options, read the manual page man 5
named.conf
.
What, how, and where logging takes place can be extensively configured in BIND. Normally, the default settings should be sufficient. Example 19.3, “Entry to Disable Logging”, shows the simplest form of such an entry and completely suppresses any logging.
logging { category default { null; }; };
zone "example.com" in { type master; file "example.com.zone"; notify no; };
After zone
, specify the name of the domain to
administer (example.com
)
followed by in
and a block of relevant options
enclosed in curly braces, as shown in Example 19.4, “Zone Entry for example.com”.
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 19.5, “Zone Entry for example.net”.
zone "example.net" in { type slave; file "slave/example.net.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.
example.com.zone
or file
“slave/example.net.zone”;
This entry specifies the file where zone data for the domain is
located. This file is not required for a slave, because this data is
pulled 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: it supplies a host name for an IP address.
The "."
has an important meaning in the zone files.
If host names are given without a final dot (.
), the
zone is appended. Complete host names specified with a full domain name
must end with a dot (.
) to avoid having the domain
added to it again. A missing or wrongly placed "." is probably the most
frequent cause of name server configuration errors.
The first case to consider is the zone file
example.com.zone
, responsible for the domain
example.com
, shown in
Example 19.6, “The /var/lib/named/example.com.zone File”.
1. $TTL 2D 2. example.com. IN SOA dns root.example.com. ( 3. 2003072441 ; serial 4. 1D ; refresh 5. 2H ; retry 6. 1W ; expiry 7. 2D ) ; minimum 8. 9. IN NS dns 10. IN MX 10 mail 11. 12. gate IN A 192.168.5.1 13. IN A 10.0.0.1 14. dns IN A 192.168.1.116 15. mail IN A 192.168.3.108 16. jupiter IN A 192.168.2.100 17. venus IN A 192.168.2.101 18. saturn IN A 192.168.2.102 19. mercury IN A 192.168.2.103 20. ntp IN CNAME dns 21. dns6 IN A6 0 2002:c0a8:174::
$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
example.com
in the first position. This
ends with "."
, 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
dns
to dns.example.com
, 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@example.com
the entry must read
root.example.com.
. 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 10
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, 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. dns
is extended
to dns.example.com
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
example.com
. In
this example, this is the host
mail.example.com
. 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
example.com
is
added to all of them. Two IP addresses are assigned to the host
gate
, as 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 AAAA
.
The IPv6 record has a slightly different syntax than IPv4. Because of the fragmentation possibility, it is necessary to provide information about missed bits before the address. To fill up the IPv6 address with the needed number of “0”, add two colons at the correct place in the address.
pluto AAAA 2345:00C1:CA11::1234:5678:9ABC:DEF0 pluto AAAA 2345:00D2:DA11::1234:5678:9ABC:DEF0
The alias ntp
can be used to address
dns
(CNAME
means
canonical name).
The pseudo domain 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
is resolved into
168.192.in-addr.arpa
. See
Example 19.7, “Reverse Lookup”.
1. $TTL 2D 2. 168.192.in-addr.arpa. IN SOA dns.example.com. root.example.com. ( 3. 2003072441 ; serial 4. 1D ; refresh 5. 2H ; retry 6. 1W ; expiry 7. 2D ) ; minimum 8. 9. IN NS dns.example.com. 10. 11. 1.5 IN PTR gate.example.com. 12. 100.3 IN PTR www.example.com. 13. 253.2 IN PTR cups.example.com.
$TTL defines the standard TTL that applies to all entries here.
The configuration file should activate reverse lookup for the network
192.168
. Given
that the zone is called 168.192.in-addr.arpa
,
it 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
example.com
example.
See the previous example for
example.com
.
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 problems.
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 19.8, “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
/etc/named.conf
file to enable a secure
communication between host1
and
host2
:
key host1-host2 { algorithm hmac-md5; secret "ejIkuCyyGJwwuN3xAteKgg=="; };
/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
10.1.2.3
in this example), the server's
/etc/named.conf
must include the following rule:
server 10.1.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
, as
are 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-signzone
, you can create sets
of generated keys (keyset-
files), transfer them to
the parent zone in a secure manner, and sign them. This generates the
files to include for each zone in /etc/named.conf
.
For more information, see the BIND Administrator Reference
Manual from the
bind-doc
package, which is
installed under /usr/share/doc/packages/bind/arm
.
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 openSUSE Leap.