ISC BIND Nameserver unter CentOS 7.x
Mit BIND1) des Internet Systems Consortium richten wir uns für unsere (Kunden-)Umgebung/-LAN ein Domain-Name-System-Server oder kurz DNS2)ein.
DNS wurde in den beiden RFC 1034 und RFC 1035 definiert und bekam von der Internet Assigned Numbers Authority die beiden Ports 53/UDP und 53/TCP.
In dem sehr ausführlichen Wikipedia-Artikel findet man eine ausführliche Beschreibung rund um den Nameserver ISC-Bind, dem u.a. weltweit am meisten eingesetzten Nameserver sowie bei den weltweiten Root-Nameservern.
Installation
Zu erst installieren wir uns die beiden Pakete bind und bind-chroot. Letzters hilft uns, unseren DNS in einem chroot3)-Umgebung laufen zu lassen. Für die Anfragen an unseren DNS-Server installieren wir uns dann noch das Paket bind-utils, falls es nicht schon bei der Grundinstallation unseres Servers als Basispaket mit installiert wurde.
# yum install bind bind-chroot bind-utils -y
RPM-Pakete
Bei Bedarf, um z.B. zu erfahren welche Dateien installiert und wohin diese gespeichert wurden, werfen wir einen Blick in die soeben installierten RPM-Pakete. Hierzu nutzen wir wie immer den Befehl rpm mit der Option -qil.
bind
# rpm -qil bind
Name : bind
Epoch : 32
Version : 9.9.4
Release : 51.el7_4.1
Architecture: x86_64
Install Date: Thu 28 Dec 2017 05:25:27 PM CET
Group : System Environment/Daemons
Size : 4552573
License : ISC
Signature : RSA/SHA256, Sat 02 Dec 2017 03:33:24 PM CET, Key ID 24c6a8a7f4a80eb5
Source RPM : bind-9.9.4-51.el7_4.1.src.rpm
Build Date : Thu 30 Nov 2017 08:30:11 PM CET
Build Host : c1bm.rdu2.centos.org
Relocations : (not relocatable)
Packager : CentOS BuildSystem <http://bugs.centos.org>
Vendor : CentOS
URL : http://www.isc.org/products/BIND/
Summary : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
Description :
BIND (Berkeley Internet Name Domain) is an implementation of the DNS
(Domain Name System) protocols. BIND includes a DNS server (named),
which resolves host names to IP addresses; a resolver library
(routines for applications to use when interfacing with DNS); and
tools for verifying that the DNS server is operating properly.
/etc/logrotate.d/named
/etc/named
/etc/named.conf
/etc/named.iscdlv.key
/etc/named.rfc1912.zones
/etc/named.root.key
/etc/rndc.conf
/etc/rndc.key
/etc/rwtab.d/named
/etc/sysconfig/named
/run/named
/usr/lib/systemd/system/named-setup-rndc.service
/usr/lib/systemd/system/named.service
/usr/lib/tmpfiles.d/named.conf
/usr/lib64/bind
/usr/libexec/generate-rndc-key.sh
/usr/sbin/arpaname
/usr/sbin/ddns-confgen
/usr/sbin/dnssec-checkds
/usr/sbin/dnssec-coverage
/usr/sbin/dnssec-dsfromkey
/usr/sbin/dnssec-importkey
/usr/sbin/dnssec-keyfromlabel
/usr/sbin/dnssec-keygen
/usr/sbin/dnssec-revoke
/usr/sbin/dnssec-settime
/usr/sbin/dnssec-signzone
/usr/sbin/dnssec-verify
/usr/sbin/genrandom
/usr/sbin/isc-hmac-fixup
/usr/sbin/lwresd
/usr/sbin/named
/usr/sbin/named-checkconf
/usr/sbin/named-checkzone
/usr/sbin/named-compilezone
/usr/sbin/named-journalprint
/usr/sbin/nsec3hash
/usr/sbin/rndc
/usr/sbin/rndc-confgen
/usr/share/doc/bind-9.9.4
/usr/share/doc/bind-9.9.4/Bv9ARM.ch01.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch02.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch03.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch04.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch05.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch06.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch07.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch08.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch09.html
/usr/share/doc/bind-9.9.4/Bv9ARM.ch10.html
/usr/share/doc/bind-9.9.4/Bv9ARM.html
/usr/share/doc/bind-9.9.4/Bv9ARM.pdf
/usr/share/doc/bind-9.9.4/CHANGES
/usr/share/doc/bind-9.9.4/README
/usr/share/doc/bind-9.9.4/isc-logo.pdf
/usr/share/doc/bind-9.9.4/man.arpaname.html
/usr/share/doc/bind-9.9.4/man.ddns-confgen.html
/usr/share/doc/bind-9.9.4/man.dig.html
/usr/share/doc/bind-9.9.4/man.dnssec-checkds.html
/usr/share/doc/bind-9.9.4/man.dnssec-coverage.html
/usr/share/doc/bind-9.9.4/man.dnssec-dsfromkey.html
/usr/share/doc/bind-9.9.4/man.dnssec-keyfromlabel.html
/usr/share/doc/bind-9.9.4/man.dnssec-keygen.html
/usr/share/doc/bind-9.9.4/man.dnssec-revoke.html
/usr/share/doc/bind-9.9.4/man.dnssec-settime.html
/usr/share/doc/bind-9.9.4/man.dnssec-signzone.html
/usr/share/doc/bind-9.9.4/man.dnssec-verify.html
/usr/share/doc/bind-9.9.4/man.genrandom.html
/usr/share/doc/bind-9.9.4/man.host.html
/usr/share/doc/bind-9.9.4/man.isc-hmac-fixup.html
/usr/share/doc/bind-9.9.4/man.named-checkconf.html
/usr/share/doc/bind-9.9.4/man.named-checkzone.html
/usr/share/doc/bind-9.9.4/man.named-journalprint.html
/usr/share/doc/bind-9.9.4/man.named.html
/usr/share/doc/bind-9.9.4/man.nsec3hash.html
/usr/share/doc/bind-9.9.4/man.nsupdate.html
/usr/share/doc/bind-9.9.4/man.rndc-confgen.html
/usr/share/doc/bind-9.9.4/man.rndc.conf.html
/usr/share/doc/bind-9.9.4/man.rndc.html
/usr/share/doc/bind-9.9.4/named.conf.default
/usr/share/doc/bind-9.9.4/sample
/usr/share/doc/bind-9.9.4/sample/etc
/usr/share/doc/bind-9.9.4/sample/etc/named.conf
/usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones
/usr/share/doc/bind-9.9.4/sample/var
/usr/share/doc/bind-9.9.4/sample/var/named
/usr/share/doc/bind-9.9.4/sample/var/named/data
/usr/share/doc/bind-9.9.4/sample/var/named/my.external.zone.db
/usr/share/doc/bind-9.9.4/sample/var/named/my.internal.zone.db
/usr/share/doc/bind-9.9.4/sample/var/named/named.ca
/usr/share/doc/bind-9.9.4/sample/var/named/named.empty
/usr/share/doc/bind-9.9.4/sample/var/named/named.localhost
/usr/share/doc/bind-9.9.4/sample/var/named/named.loopback
/usr/share/doc/bind-9.9.4/sample/var/named/slaves
/usr/share/doc/bind-9.9.4/sample/var/named/slaves/my.ddns.internal.zone.db
/usr/share/doc/bind-9.9.4/sample/var/named/slaves/my.slave.internal.zone.db
/usr/share/man/man1/arpaname.1.gz
/usr/share/man/man5/named.conf.5.gz
/usr/share/man/man5/rndc.conf.5.gz
/usr/share/man/man8/ddns-confgen.8.gz
/usr/share/man/man8/dnssec-checkds.8.gz
/usr/share/man/man8/dnssec-coverage.8.gz
/usr/share/man/man8/dnssec-dsfromkey.8.gz
/usr/share/man/man8/dnssec-keyfromlabel.8.gz
/usr/share/man/man8/dnssec-keygen.8.gz
/usr/share/man/man8/dnssec-revoke.8.gz
/usr/share/man/man8/dnssec-settime.8.gz
/usr/share/man/man8/dnssec-signzone.8.gz
/usr/share/man/man8/dnssec-verify.8.gz
/usr/share/man/man8/genrandom.8.gz
/usr/share/man/man8/isc-hmac-fixup.8.gz
/usr/share/man/man8/lwresd.8.gz
/usr/share/man/man8/named-checkconf.8.gz
/usr/share/man/man8/named-checkzone.8.gz
/usr/share/man/man8/named-compilezone.8.gz
/usr/share/man/man8/named-journalprint.8.gz
/usr/share/man/man8/named.8.gz
/usr/share/man/man8/nsec3hash.8.gz
/usr/share/man/man8/rndc-confgen.8.gz
/usr/share/man/man8/rndc.8.gz
/var/log/named.log
/var/named
/var/named/data
/var/named/dynamic
/var/named/named.ca
/var/named/named.empty
/var/named/named.localhost
/var/named/named.loopback
/var/named/slaves
bind-chroot
# rpm -qil bind-chroot
Name : bind-chroot
Epoch : 32
Version : 9.9.4
Release : 51.el7_4.1
Architecture: x86_64
Install Date: Thu 28 Dec 2017 05:25:27 PM CET
Group : System Environment/Daemons
Size : 3562
License : ISC
Signature : RSA/SHA256, Sat 02 Dec 2017 03:33:27 PM CET, Key ID 24c6a8a7f4a80eb5
Source RPM : bind-9.9.4-51.el7_4.1.src.rpm
Build Date : Thu 30 Nov 2017 08:30:11 PM CET
Build Host : c1bm.rdu2.centos.org
Relocations : /var/named/chroot
Packager : CentOS BuildSystem <http://bugs.centos.org>
Vendor : CentOS
URL : http://www.isc.org/products/BIND/
Summary : A chroot runtime environment for the ISC BIND DNS server, named(8)
Description :
This package contains a tree of files which can be used as a
chroot(2) jail for the named(8) program from the BIND package.
Based on the code from Jan "Yenya" Kasprzak <kas@fi.muni.cz>
/usr/lib/systemd/system/named-chroot-setup.service
/usr/lib/systemd/system/named-chroot.service
/usr/libexec/setup-named-chroot.sh
/var/named/chroot
/var/named/chroot/dev
/var/named/chroot/dev/null
/var/named/chroot/dev/random
/var/named/chroot/dev/zero
/var/named/chroot/etc
/var/named/chroot/etc/named
/var/named/chroot/etc/named.conf
/var/named/chroot/etc/pki
/var/named/chroot/etc/pki/dnssec-keys
/var/named/chroot/run
/var/named/chroot/run/named
/var/named/chroot/usr
/var/named/chroot/usr/lib64
/var/named/chroot/usr/lib64/bind
/var/named/chroot/var
/var/named/chroot/var/log
/var/named/chroot/var/named
/var/named/chroot/var/run
/var/named/chroot/var/tmp
bind-utils
# rpm -qil bind-utils
Name : bind-utils
Epoch : 32
Version : 9.9.4
Release : 51.el7_4.1
Architecture: x86_64
Install Date: Tue 05 Dec 2017 07:38:22 AM CET
Group : Applications/System
Size : 445201
License : ISC
Signature : RSA/SHA256, Sat 02 Dec 2017 03:33:53 PM CET, Key ID 24c6a8a7f4a80eb5
Source RPM : bind-9.9.4-51.el7_4.1.src.rpm
Build Date : Thu 30 Nov 2017 08:30:11 PM CET
Build Host : c1bm.rdu2.centos.org
Relocations : (not relocatable)
Packager : CentOS BuildSystem <http://bugs.centos.org>
Vendor : CentOS
URL : http://www.isc.org/products/BIND/
Summary : Utilities for querying DNS name servers
Description :
Bind-utils contains a collection of utilities for querying DNS (Domain
Name System) name servers to find out information about Internet
hosts. These tools will provide you with the IP addresses for given
host names, as well as other information about registered domains and
network addresses.
You should install bind-utils if you need to get information from DNS name
servers.
/etc/trusted-key.key
/usr/bin/dig
/usr/bin/host
/usr/bin/nslookup
/usr/bin/nsupdate
/usr/share/man/man1/dig.1.gz
/usr/share/man/man1/host.1.gz
/usr/share/man/man1/nslookup.1.gz
/usr/share/man/man1/nsupdate.1.gz
Grund-/Basis-Konfiguration
Name Server Control Utility
Zur administrativen Interaktion und Steuerung mit unserem DNS-Server nutzen wir das Name Server Control Utility rndc aus dem RPM bind. Die Optionen dieses User Interface finden am einfachsten in der zugehörigen manpage.
RNDC(8) BIND9 RNDC(8)
NAME
rndc - name server control utility
SYNOPSIS
rndc [-b source-address] [-c config-file] [-k key-file] [-s server] [-p port] [-V]
[-y key_id] {command}
DESCRIPTION
rndc controls the operation of a name server. It supersedes the ndc utility that was
provided in old BIND releases. If rndc is invoked with no command line options or
arguments, it prints a short summary of the supported commands and the available
options and their arguments.
rndc communicates with the name server over a TCP connection, sending commands
authenticated with digital signatures. In the current versions of rndc and named, the
only supported authentication algorithm is HMAC-MD5, which uses a shared secret on
each end of the connection. This provides TSIG-style authentication for the command
request and the name server's response. All commands sent over the channel must be
signed by a key_id known to the server.
rndc reads a configuration file to determine how to contact the name server and
decide what algorithm and key it should use.
OPTIONS
-b source-address
Use source-address as the source address for the connection to the server.
Multiple instances are permitted to allow setting of both the IPv4 and IPv6
source addresses.
-c config-file
Use config-file as the configuration file instead of the default, /etc/rndc.conf.
-k key-file
Use key-file as the key file instead of the default, /etc/rndc.key. The key in
/etc/rndc.key will be used to authenticate commands sent to the server if the
config-file does not exist.
-s server
server is the name or address of the server which matches a server statement in
the configuration file for rndc. If no server is supplied on the command line,
the host named by the default-server clause in the options statement of the rndc
configuration file will be used.
-p port
Send commands to TCP port port instead of BIND 9's default control channel port,
953.
-V
Enable verbose logging.
-y key_id
Use the key key_id from the configuration file. key_id must be known by named
with the same algorithm and secret string in order for control message validation
to succeed. If no key_id is specified, rndc will first look for a key clause in
the server statement of the server being used, or if no server statement is
present for that host, then the default-key clause of the options statement. Note
that the configuration file contains shared secrets which are used to send
authenticated control commands to name servers. It should therefore not have
general read or write access.
COMMANDS
A list of commands supported by rndc can be seen by running rndc without arguments.
Currently supported commands are:
reload
Reload configuration file and zones.
reload zone [class [view]]
Reload the given zone.
refresh zone [class [view]]
Schedule zone maintenance for the given zone.
retransfer zone [class [view]]
Retransfer the given zone from the master.
sign zone [class [view]]
Fetch all DNSSEC keys for the given zone from the key directory (see the
key-directory option in the BIND 9 Administrator Reference Manual). If they are
within their publication period, merge them into the zone's DNSKEY RRset. If the
DNSKEY RRset is changed, then the zone is automatically re-signed with the new
key set.
This command requires that the auto-dnssec zone option be set to allow or
maintain, and also requires the zone to be configured to allow dynamic DNS. (See
"Dynamic Update Policies" in the Administrator Reference Manual for more
details.)
loadkeys zone [class [view]]
Fetch all DNSSEC keys for the given zone from the key directory. If they are
within their publication period, merge them into the zone's DNSKEY RRset. Unlike
rndc sign, however, the zone is not immediately re-signed by the new keys, but is
allowed to incrementally re-sign over time.
This command requires that the auto-dnssec zone option be set to maintain, and
also requires the zone to be configured to allow dynamic DNS. (See "Dynamic
Update Policies" in the Administrator Reference Manual for more details.)
freeze [zone [class [view]]]
Suspend updates to a dynamic zone. If no zone is specified, then all zones are
suspended. This allows manual edits to be made to a zone normally updated by
dynamic update. It also causes changes in the journal file to be synced into the
master file. All dynamic update attempts will be refused while the zone is
frozen.
thaw [zone [class [view]]]
Enable updates to a frozen dynamic zone. If no zone is specified, then all frozen
zones are enabled. This causes the server to reload the zone from disk, and
re-enables dynamic updates after the load has completed. After a zone is thawed,
dynamic updates will no longer be refused. If the zone has changed and the
ixfr-from-differences option is in use, then the journal file will be updated to
reflect changes in the zone. Otherwise, if the zone has changed, any existing
journal file will be removed.
sync [-clean] [zone [class [view]]]
Sync changes in the journal file for a dynamic zone to the master file. If the
"-clean" option is specified, the journal file is also removed. If no zone is
specified, then all zones are synced.
notify zone [class [view]]
Resend NOTIFY messages for the zone.
reconfig
Reload the configuration file and load new zones, but do not reload existing zone
files even if they have changed. This is faster than a full reload when there is
a large number of zones because it avoids the need to examine the modification
times of the zones files.
stats
Write server statistics to the statistics file.
querylog [on|off]
Enable or disable query logging. (For backward compatibility, this command can
also be used without an argument to toggle query logging on and off.)
Query logging can also be enabled by explicitly directing the queries category to
a channel in the logging section of named.conf or by specifying querylog yes; in
the options section of named.conf.
dumpdb [-all|-cache|-zone] [view ...]
Dump the server's caches (default) and/or zones to the dump file for the
specified views. If no view is specified, all views are dumped.
secroots [view ...]
Dump the server's security roots to the secroots file for the specified views. If
no view is specified, security roots for all views are dumped.
stop [-p]
Stop the server, making sure any recent changes made through dynamic update or
IXFR are first saved to the master files of the updated zones. If -p is specified
named's process id is returned. This allows an external process to determine when
named had completed stopping.
halt [-p]
Stop the server immediately. Recent changes made through dynamic update or IXFR
are not saved to the master files, but will be rolled forward from the journal
files when the server is restarted. If -p is specified named's process id is
returned. This allows an external process to determine when named had completed
halting.
trace
Increment the servers debugging level by one.
trace level
Sets the server's debugging level to an explicit value.
notrace
Sets the server's debugging level to 0.
flush
Flushes the server's cache.
flushname name [view]
Flushes the given name from the server's DNS cache and, if applicable, from the
server's nameserver address database or bad-server cache.
flushtree name [view]
Flushes the given name, and all of its subdomains, from the server's DNS cache.
Note that this does not affect he server's address database or bad-server cache.
status
Display status of the server. Note that the number of zones includes the internal
bind/CH zone and the default ./IN hint zone if there is not an explicit root zone
configured.
recursing
Dump the list of queries named is currently recursing on.
validation ( on | off | check ) [view ...]
Enable, disable, or check the current status of DNSSEC validation. Note
dnssec-enable also needs to be set to yes or auto to be effective. It defaults to
enabled.
tsig-list
List the names of all TSIG keys currently configured for use by named in each
view. The list both statically configured keys and dynamic TKEY-negotiated keys.
tsig-delete keyname [view]
Delete a given TKEY-negotiated key from the server. (This does not apply to
statically configured TSIG keys.)
addzone zone [class [view]] configuration
Add a zone while the server is running. This command requires the allow-new-zones
option to be set to yes. The configuration string specified on the command line
is the zone configuration text that would ordinarily be placed in named.conf.
The configuration is saved in a file called hash.nzf, where hash is a
cryptographic hash generated from the name of the view. When named is restarted,
the file will be loaded into the view configuration, so that zones that were
added can persist after a restart.
This sample addzone command would add the zone example.com to the default view:
$rndc addzone example.com '{ type master; file "example.com.db"; };'
(Note the brackets and semi-colon around the zone configuration text.)
delzone zone [class [view]]
Delete a zone while the server is running. Only zones that were originally added
via rndc addzone can be deleted in this manner.
signing [( -list | -clear keyid/algorithm | -clear all | -nsec3param ( parameters |
none ) ) ] zone [class [view]]
List, edit, or remove the DNSSEC signing state for the specified zone. The status
of ongoing DNSSEC operations (such as signing or generating NSEC3 chains) is
stored in the zone in the form of DNS resource records of type sig-signing-type.
rndc signing -list converts these records into a human-readable form, indicating
which keys are currently signing or have finished signing the zone, and which
NSEC3 chains are being created or removed.
rndc signing -clear can remove a single key (specified in the same format that
rndc signing -list uses to display it), or all keys. In either case, only
completed keys are removed; any record indicating that a key has not yet finished
signing the zone will be retained.
rndc signing -nsec3param sets the NSEC3 parameters for a zone. This is the only
supported mechanism for using NSEC3 with inline-signing zones. Parameters are
of ongoing DNSSEC operations (such as signing or generating NSEC3 chains) is
stored in the zone in the form of DNS resource records of type sig-signing-type.
rndc signing -list converts these records into a human-readable form, indicating
which keys are currently signing or have finished signing the zone, and which
NSEC3 chains are being created or removed.
rndc signing -clear can remove a single key (specified in the same format that
rndc signing -list uses to display it), or all keys. In either case, only
completed keys are removed; any record indicating that a key has not yet finished
signing the zone will be retained.
rndc signing -nsec3param sets the NSEC3 parameters for a zone. This is the only
supported mechanism for using NSEC3 with inline-signing zones. Parameters are
specified in the same format as an NSEC3PARAM resource record: hash algorithm,
flags, iterations, and salt, in that order.
Currently, the only defined value for hash algorithm is 1, representing SHA-1.
The flags may be set to 0 or 1, depending on whether you wish to set the opt-out
bit in the NSEC3 chain. iterations defines the number of additional times to
apply the algorithm when generating an NSEC3 hash. The salt is a string of data
expressed in hexidecimal, or a hyphen (`-') if no salt is to be used.
So, for example, to create an NSEC3 chain using the SHA-1 hash algorithm, no
opt-out flag, 10 iterations, and a salt value of "FFFF", use: rndc signing
-nsec3param 1 0 10 FFFF zone. To set the opt-out flag, 15 iterations, and no
salt, use: rndc signing -nsec3param 1 1 15 - zone.
rndc signing -nsec3param none removes an existing NSEC3 chain and replaces it
with NSEC.
LIMITATIONS
There is currently no way to provide the shared secret for a key_id without using the
configuration file.
Several error messages could be clearer.
SEE ALSO
rndc.conf(5), rndc-confgen(8), named(8), named.conf(5), ndc(8), BIND 9 Administrator
Reference Manual.
AUTHOR
Internet Systems Consortium
COPYRIGHT
Copyright © 2004, 2005, 2007, 2013 Internet Systems Consortium, Inc. ("ISC")
Copyright © 2000, 2001 Internet Software Consortium.
BIND9 June 7, 2013 RNDC(8)
Die Kommunikation zwischen der UI4) rndc und dem DNS-Daemon erfolgt bei CentOS 7 nur noch über eine digital signierten Zugangskanal, der auf einem entsprechenden symetrischen Schlüssel basiert. Dieser zugehörige Schlüssel muss direkt in einer entsprechenden Konfigurationsdateien hinterlegt werden und so dem Client rndc und dem Server bind bekannt gegeben werden.
rndc-confgen
Mit Hilfe des Befehls rndc-confgen aus dem RPM-Paket bind kann sowohl dieser symetrische Schlüssel wie auch die zugehörige Client-Konfigurationsdatei /etc/rndc.conf erzeugt, wie auch die benötigten Konfigurationsoptionen für die DNS-Server-Konfigurationsdatei /etc/named.conf angezeigt werden.
RNDC-CONFGEN(8) BIND9 RNDC-CONFGEN(8) NAME rndc-confgen - rndc key generation tool SYNOPSIS rndc-confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user] DESCRIPTION rndc-confgen generates configuration files for rndc. It can be used as a convenient alternative to writing the rndc.conf file and the corresponding controls and key statements in named.conf by hand. Alternatively, it can be run with the -a option to set up a rndc.key file and avoid the need for a rndc.conf file and a controls statement altogether. OPTIONS -a Do automatic rndc configuration. This creates a file rndc.key in /etc (or whatever sysconfdir was specified as when BIND was built) that is read by both rndc and named on startup. The rndc.key file defines a default command channel and authentication key allowing rndc to communicate with named on the local host with no further configuration. Running rndc-confgen -a allows BIND 9 and rndc to be used as drop-in replacements for BIND 8 and ndc, with no changes to the existing BIND 8 named.conf file. If a more elaborate configuration than that generated by rndc-confgen -a is required, for example if rndc is to be used remotely, you should run rndc-confgen without the -a option and set up a rndc.conf and named.conf as directed. -b keysize Specifies the size of the authentication key in bits. Must be between 1 and 512 bits; the default is 128. -c keyfile Used with the -a option to specify an alternate location for rndc.key. -h Prints a short summary of the options and arguments to rndc-confgen. -k keyname Specifies the key name of the rndc authentication key. This must be a valid domain name. The default is rndc-key. -p port Specifies the command channel port where named listens for connections from rndc. The default is 953. Specifies the key name of the rndc authentication key. This must be a valid domain name. The default is rndc-key. -p port Specifies the command channel port where named listens for connections from rndc. The default is 953. -r randomfile Specifies a source of random data for generating the authorization. If the operating system does not provide a /dev/random or equivalent device, the default source of randomness is keyboard input. randomdev specifies the name of a character device or file containing random data to be used instead of the default. The special value keyboard indicates that keyboard input should be used. -s address Specifies the IP address where named listens for command channel connections from rndc. The default is the loopback address 127.0.0.1. -t chrootdir Used with the -a option to specify a directory where named will run chrooted. An additional copy of the rndc.key will be written relative to this directory so that it will be found by the chrooted named. -u user Used with the -a option to set the owner of the rndc.key file generated. If -t is also specified only the file in the chroot area has its owner changed. EXAMPLES To allow rndc to be used with no manual configuration, run rndc-confgen -a To print a sample rndc.conf file and corresponding controls and key statements to be manually inserted into named.conf, run rndc-confgen SEE ALSO rndc(8), rndc.conf(5), named(8), BIND 9 Administrator Reference Manual. AUTHOR Internet Systems Consortium COPYRIGHT Copyright © 2004, 2005, 2007, 2009 Internet Systems Consortium, Inc. ("ISC") Copyright © 2001, 2003 Internet Software Consortium. BIND9 Aug 27, 2001 RNDC-CONFGEN(8)
In folgendem Konfigurationsbeispiel, welches wir lediglich zum Anzeigen der später benötigten Konfigurationsoptionen benutzen, nutzen wir folgende Optionen beim Aufruf des Hilfsprogramms rndc-confgen
- -b keysize = 512
- -k keyname = rndc-key
- -r randomfile = /dev/random
- -u user = named
# rndc-confgen -b 512 -k rndc-key -r /dev/random -u named
# Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "FnqGCTNassQ6o5djkYN7pdgWifhUznPY+A2xqmvSRVvlWYphzSUHcJnqLciTZWAKJ9ogKIeQ763/tU8OZeta9A=="; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; # End of rndc.conf # Use with the following in named.conf, adjusting the allow list as needed: # key "rndc-key" { # algorithm hmac-md5; # secret "FnqGCTNassQ6o5djkYN7pdgWifhUznPY+A2xqmvSRVvlWYphzSUHcJnqLciTZWAKJ9ogKIeQ763/tU8OZeta9A=="; # }; # # controls { # inet 127.0.0.1 port 953 # allow { 127.0.0.1; } keys { "rndc-key"; }; # }; # End of named.conf
Wichtig:
Der symmetrische Schlüssel muss sowohl in der Client-Konfigurationsdatei /etc/rndc.conf wie auch Server-Konfigurationsdatei /etc/named.conf hinterlegt werden. Zweckmäßiger ist es jedoch diesen Schlüssel in eine eigene Konfigurationsdatei zu hinterlegen und diese Datei dann entsprechend zu inkludieren!
Bei der Installation des RPM-Paketes bind wurde auch ein zugehörige Key-Datei /etc/rndc.conf mit installiert.
# ll /etc/rndc.key
-rw-r-----. 1 root named 77 Dec 28 18:26 /etc/rndc.key
# less /etc/rndc.key
- /etc/rndc.key
key "rndc-key" { algorithm hmac-md5; secret "LXQvnV2ZbqG9QMg8eV7fsQ=="; };
WICHTIG:
Damit es später beim Aufruf von rndc status nicht zu folgender Fehlermeldung
WARNING: key file (rndc.key) exists, but using default configuration file (rndc.conf)
kommen wird, werden wir die mitgelieferte Datei löschen und in unserer chroot-Umgebung dafür später noch sorgen, dass unsere eigene lokale Datei in das chroot-jail mit übernommen wird.
Diese Datei werden wir also nun zunächst sichern und dann automatisch eine neue lokale Datei anlegen lassen.
# mv /etc/rndc.key /etc/rndc.key.orig
Nun erzeugen wir uns unsere eigenen Schlüssel.
# rndc-confgen -a -b 512 -c /etc/rndc_local.key -k rndc-key -r /dev/random -u named
wrote key file "/etc/rndc_local.key"
Den Inhalt dieser Schlüsseldatei können wir uns nun auch anzeigen lassen.
# less /etc/rndc_local.key
- /etc/rndc_local.key
key "rndc-key" { algorithm hmac-md5; secret "prjseECUq/pzTKCwQKQoraA9KlYeuTMpwRd1qmQSYsKOOIw9b3QRN0ctcDlTvTs/6Urassjq0y+Vgi8eQPXQDA=="; };
Anschließend passen wir dann noch die User- und Gruppen-Eigenschaften an:
# chown root:named /etc/rndc_local.key # chmod 640 /etc/rndc_local.key
Somit weist die Schlüsseldatei nunmehr die gleichen Rechte auf, die die original Datei aus dem RPM auf:
# ll /etc/rndc*key*
-rw-r-----. 1 root named 74 Dec 29 08:14 /etc/rndc.key.orig -rw-r-----. 1 root named 141 Dec 29 11:10 /etc/rndc_local.key
Zu guter Letzt legen wir nun noch die benötigte Konfigurationsdatei /etc/rndc.conf an.
# vim /etc/rndc.conf
- /etc/rndc.conf
include "/etc/rndc_local.key"; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; };
change root - Umgebung
Be der Installation des zugehörigen RPM-Paketes bind-chroot wurde der Verzeichnisbaum /var/named/chroot als Mustervorlage auf unseren Server installiert, welcher als chroot jail für den IDC BIND Nameserver fungiert.
/var/named/chroot /var/named/chroot/dev /var/named/chroot/dev/null /var/named/chroot/dev/random /var/named/chroot/dev/zero /var/named/chroot/etc /var/named/chroot/etc/named /var/named/chroot/etc/named.conf /var/named/chroot/etc/pki /var/named/chroot/etc/pki/dnssec-keys /var/named/chroot/run /var/named/chroot/run/named /var/named/chroot/usr /var/named/chroot/usr/lib64 /var/named/chroot/usr/lib64/bind /var/named/chroot/var /var/named/chroot/var/log /var/named/chroot/var/named /var/named/chroot/var/run /var/named/chroot/var/tmp
Beim Starten des named Daemon wird dann das chroot jail mit den zugehörigen Konfigurationsdateien gemountet und so dem Daemon verfügbar gemacht. In dem Bash-Sctript /usr/libexec/setup-named-chroot.sh ist so unter anderem vermerkt welche Verzeichnispfade ge(un)mounted werden sollen.
Damit auch unser zuvor generierte RNDC-Schlüssel kopiert wird, werden wir das Bash-Script aber ein klein wenig an unsere Umgebung anpassen. Zunächst machen wir von dem originalen Script eine Sicherheitskopie.
# cp -a /usr/libexec/setup-named-chroot.sh /usr/libexec/setup-named-chroot.sh.orig
Anschließend korrigieren wir den Dateinamen der RNDC-Schlüsseldatei auf unseren lokalen Dateinamen /etc/rndc_local.kex
.
# vim /usr/libexec/setup-named-chroot.sh
- /usr/libexec/setup-named-chroot.sh
#!/bin/bash # Warning: the order is important # If a directory containing $ROOTDIR is listed here, # it MUST be listed last. (/var/named contains /var/named/chroot) # Django : 2017-12-29 # default: ROOTDIR_MOUNT='/etc/localtime /etc/named /etc/pki/dnssec-keys /etc/named.root.key /etc/named.conf # /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key /etc/named.iscdlv.key /etc/protocols /etc/services # /usr/lib64/bind /usr/lib/bind /run/named # /var/named' ROOTDIR_MOUNT='/etc/localtime /etc/named /etc/pki/dnssec-keys /etc/named.root.key /etc/named.conf /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc_local.key /etc/named.iscdlv.key /etc/protocols /etc/services /usr/lib64/bind /usr/lib/bind /run/named /var/named' usage() { echo echo 'This script setups chroot environment for BIND' echo 'Usage: setup-named-chroot.sh ROOTDIR [on|off]' } if ! [ "$#" -eq 2 ]; then echo 'Wrong number of arguments' usage exit 1 fi ROOTDIR="$1" # Exit if ROOTDIR doesn't exist if ! [ -d "$ROOTDIR" ]; then echo "Root directory $ROOTDIR doesn't exist" usage exit 1 fi mount_chroot_conf() { if [ -n "$ROOTDIR" ]; then for all in $ROOTDIR_MOUNT; do # Skip nonexistant files [ -e "$all" ] || continue # If mount source is a file if ! [ -d "$all" ]; then # mount it only if it is not present in chroot or it is empty if ! [ -e "$ROOTDIR$all" ] || [ `stat -c'%s' "$ROOTDIR$all"` -eq 0 ]; then touch "$ROOTDIR$all" mount --bind "$all" "$ROOTDIR$all" fi else # Mount source is a directory. Mount it only if directory in chroot is # empty. if [ -e "$all" ] && [ `ls -1A $ROOTDIR$all | wc -l` -eq 0 ]; then mount --bind --make-private "$all" "$ROOTDIR$all" fi fi done fi } umount_chroot_conf() { if [ -n "$ROOTDIR" ]; then for all in $ROOTDIR_MOUNT; do # Check if file is mount target. Do not use /proc/mounts because detecting # of modified mounted files can fail. if mount | grep -q '.* on '"$ROOTDIR$all"' .*'; then umount "$ROOTDIR$all" # Remove temporary created files [ -f "$all" ] && rm -f "$ROOTDIR$all" fi done fi } case "$2" in on) mount_chroot_conf ;; off) umount_chroot_conf ;; *) echo 'Second argument has to be "on" or "off"' usage exit 1 esac exit 0
Später können wir dann über den Befehl df -ah | grep named
das gemountete chroot-jail abfragen, sofern der Dameon gestartet worden ist.
rsyslogd
Da der Dameon, welcher in seinem chroot-jail gefangen ist, nicht mehr das Logverzeichnis /var/log/ erreichen kann, müssen wir bei m Betrieb des chroot'eten Daemon dafür soregn dass er in sein eigenes Logverzeichnis /var/named/chroot/var/log seine Logdaten bei Bedarf schreiben kann. Hierzu passen wir als erste Konfigurationsmaßnahme die Konfiguration iunseres rsyslog-Daemon passend an.
Hierzu öffnen wir mit dem Editor unserer Wahl die Konfigurationsdatei /etc/rsyslog.conf und tragen folgende Option in der Sektion GLOBAL DIRECTIVES nach:
$AddUnixListenSocket /var/named/chroot/dev/log
.
# vim /etc/rsyslog.conf
- /etc/rsyslog.conf
# rsyslog configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### MODULES #### # Django : 2017-2-14 # default: unset $DefaultNetstreamDriver gtls #make gtls driver the default # The imjournal module bellow is now used as a message source instead of imuxsock. $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) # Django : 2017-09-26 # default: $ModLoad imjournal # provides access to the systemd journal #$ModLoad imklog # reads kernel messages (the same are read from journald) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # Provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 #### GLOBAL DIRECTIVES #### # Where to place auxiliary files $WorkDirectory /var/lib/rsyslog # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # File syncing capability is disabled by default. This feature is usually not required, # not useful and an extreme performance hit #$ActionFileEnableSync on # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf # Turn off message reception via local log socket; # local messages are retrieved through imjournal now. # Django : 2017-09-26 # default: $OmitLocalLogging on # File to store the position in the journal # Django : 2017-09-26 # default: $IMJournalStateFile imjournal.state # Django : 2017-02-14 - certificate files for TLS # default: unset $DefaultNetstreamDriverCAFile /etc/pki/ca-trust/source/anchors/root-ca.certifikate.pem $DefaultNetstreamDriverCertFile /etc/pki/tls/certs/rsyslog.vml000027.dmz.nausch.org.certificate.pem $DefaultNetstreamDriverKeyFile /etc/pki/tls/private/rsyslog.vml000027.dmz.nausch.org.key.pem $ActionSendStreamDriverAuthMode x509/name $ActionSendStreamDriverPermittedPeer graylog-server.dmz.nausch.org # run driver in TLS-only mode $ActionSendStreamDriverMode 1 # Django: 2017-12-28 # Erweiterung für die chroot-Umgebung des bind Nameservers eingetragen $AddUnixListenSocket /var/named/chroot/dev/log #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg :omusrmsg:* # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log # ### begin forwarding rule ### # The statement between the begin ... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # # Django : 2017-02-14 $template GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n" *.* @@10.0.0.117:6514;RSYSLOG_SyslogProtocol23Format # # ### end of the forwarding rule ###
Zur Aktivierung unserer Änderung bedarf es nur noch eines Restarts des rsyslogd Daemon.
# systemctl restart rsyslog
● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2017-12-28 17:52:05 CET; 8s ago Docs: man:rsyslogd(8) http://www.rsyslog.com/doc/ Main PID: 3494 (rsyslogd) CGroup: /system.slice/rsyslog.service └─3494 /usr/sbin/rsyslogd -n Dec 28 17:52:05 vml000027.dmz.nausch.org systemd[1]: Starting System Logging Service... Dec 28 17:52:05 vml000027.dmz.nausch.org rsyslogd[3494]: [origin software="rsyslogd" swVersion="8.24.0" x-pid="3494" x-info="http://www.rsyslog.com"] start Dec 28 17:52:05 vml000027.dmz.nausch.org systemd[1]: Started System Logging Service. Hint: Some lines were ellipsized, use -l to show in full.
Paketfilter/Firewall
Damit unsere berechtigten Clients auch Verbindungen zu den geöffneten Ports UDP/53 UND TCP/53 unseres BIND-Name-Server aufbauen können müssen wir für diese noch Änderungen am Paketfilter firewalld vornehmen.
Unter CentOS 7 wird als Standard-Firewall die dynamische firewalld verwendet. Ein großer Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbiundungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.
Mit Hilfe des Programms firewall-cmd legen wir nun eine permanente Regel in den zugehörigen Zonen, in diesem Konfigurationsbeispiel internal und external, an. Genug der Vorrede, mit nachfolgendem Befehl werden den Port 35 für die beiden Protokolle UDP und TCP geöffnet.
# firewall-cmd --permanent --zone=internal --add-service=dns
success
# firewall-cmd --permanent --zone=external --add-service=dns
success
Anschließend können wir den Firewall-Daemon einmal durchstarten und anschließend überprüfen, ob die Regeln auch entsprechend unserer Definition, gezogen haben.
# firewall-cmd --reload
success
Anschließend können wir abfragen, welche Dienste in der Zone public geöffnet sind.
# firewall-cmd --zone=public --list-services
dns
Genauso können wir natürlich mit mit dem Befehl iptables abfragen, ob die Erweiterung unseres Paketfilter aktiv ist.
# iptables -nvL IN_internal_allow
Chain IN_internal_allow (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ctstate NEW 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ctstate NEW
Das Gleiche gilt natürlich auch für die Zone external
# iptables -nvL IN_external_allow
Chain IN_internal_allow (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ctstate NEW 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ctstate NEW
Start des Daemon
Nun können wir unseren DNS-Daemon das erste mal starten und prüfen, ob unsere Basis-Konfiguration den gewünschten Erfolg mitbringt.
# systemctl start named-chroot.service
Den Status des laufenden Daemon fragen wir wie gewohnt wie folgt ab.
# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2017-12-28 18:26:38 CET; 8s ago Process: 4391 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} -t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS) Process: 4389 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Main PID: 4394 (named) CGroup: /system.slice/named-chroot.service └─4394 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: command channel listening on ::1#953 Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: managed-keys-zone: loaded serial 0 Dec 28 18:26:38 vml000027.dmz.nausch.org systemd[1]: Started Berkeley Internet Name Domain (DNS). Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: zone 0.in-addr.arpa/IN: loaded serial 0 Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: zone localhost/IN: loaded serial 0 Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: zone localhost.localdomain/IN: loaded serial 0 Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: all zones loaded Dec 28 18:26:38 vml000027.dmz.nausch.org named[4394]: running
Damit der ISC-BIND-DNS-Daemon beim Starten des Server automatisch in seiner chroot-Umgebung auch gestartet wird, aktivieren wir den Autostart des Daemon.
# systemctl enable named-chroot.service
Created symlink from /etc/systemd/system/multi-user.target.wants/named-chroot.service to /usr/lib/systemd/system/named-chroot.service.
Wollen wir prüfen ob die Autostartfunktion des DNS-Daemon gesetzt ist, nutzen wir folgenden Aufruf:
# systemctl is-enabled named-chroot.service
enabled
Da wir noch gezielte Konfiguration unseres DNS-Server vorgenommen haben, lauscht dieser erst einmal auf den UDP/TCP Port 53, was wir mit dem Befehl netstat auch überprüfen können.
# netstat -tulpen | grep named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 25 10197099 4394/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 25 10197104 4394/named tcp6 0 0 ::1:53 :::* LISTEN 25 10197101 4394/named tcp6 0 0 ::1:953 :::* LISTEN 25 10197105 4394/named udp 0 0 127.0.0.1:53 0.0.0.0:* 25 10197098 4394/named udp6 0 0 ::1:53 :::* 25 10197100 4394/named
Dass der DNS-Daemon auch mit der wirklich in einer chroot-Umgebung läuft sehen wird bei nachfolgenden Befehls-Check. Da die Option -t /var/named/chroot gesetzt wurde, sehen wir, dass dies auch entsprechend erfolgt ist.
# ps auxwf | grep named
root 4517 0.0 0.0 112660 948 pts/0 S+ 18:30 0:00 \_ grep --color=auto named named 4394 0.0 0.7 163712 14928 ? Ssl 18:26 0:00 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot
Wie zuvor schon erwähnt werden beim Starten des DNS-Daemon in seinem chroot-jail die benötigten Verzeichnisse und Dateien gemountet. Dies können wir nun über den Befehl df -ah | grep named
auch entsprechend überprüfen.
# df -ah | grep named
/dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/localtime /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/named /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/named.root.key /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/named.conf /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/named.rfc1912.zones /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/rndc.key /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/named.iscdlv.key /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/protocols /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/etc/services /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/usr/lib64/bind tmpfs 920M 90M 831M 10% /var/named/chroot/run/named /dev/mapper/centos-root 10G 3.9G 6.2G 39% /var/named/chroot/var/named
Der Dokumenten-Baum des chroot-jail ist entsprechend erweitert:
/var/named/chroot/ ├── dev │ ├── log │ ├── null │ ├── random │ └── zero ├── etc │ ├── localtime │ ├── named │ ├── named.conf │ ├── named.iscdlv.key │ ├── named.rfc1912.zones │ ├── named.root.key │ ├── pki │ │ └── dnssec-keys │ ├── protocols │ ├── rndc.key │ └── services ├── run │ └── named │ ├── named.pid │ └── session.key ├── usr │ └── lib64 │ └── bind └── var ├── log ├── named │ ├── chroot │ │ ├── dev │ │ │ ├── log │ │ │ ├── null │ │ │ ├── random │ │ │ └── zero │ │ ├── etc │ │ │ ├── localtime │ │ │ ├── named │ │ │ ├── named.conf │ │ │ ├── named.iscdlv.key │ │ │ ├── named.rfc1912.zones │ │ │ ├── named.root.key │ │ │ ├── pki │ │ │ │ └── dnssec-keys │ │ │ ├── protocols │ │ │ ├── rndc.key │ │ │ └── services │ │ ├── run │ │ │ └── named │ │ ├── usr │ │ │ └── lib64 │ │ │ └── bind │ │ └── var │ │ ├── log │ │ ├── named │ │ ├── run -> ../run │ │ └── tmp │ ├── data │ │ └── named.run │ ├── dynamic │ │ ├── managed-keys.bind │ │ └── managed-keys.bind.jnl │ ├── named.ca │ ├── named.empty │ ├── named.localhost │ ├── named.loopback │ └── slaves ├── run -> ../run └── tmp
Zum Testen, ob beim Stoppen auch diese Mountpoints wieder verschwinden, testen wir nun auch noch. Hierzu stoppen wir erst einmal den laufenden DNS-Deamon.
# systemctl stop named-chroot.service
Dass der Daemon auch wirklich nicht mehr läft sehen wir beim Abfragen des Server-Statuses.
# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: inactive (dead) since Thu 2017-12-28 18:35:53 CET; 6s ago Process: 4677 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS) Main PID: 4394 (code=exited, status=0/SUCCESS) Dec 28 18:35:53 vml000027.dmz.nausch.org systemd[1]: Stopping Berkeley Internet Name Domain (DNS)... Dec 28 18:35:53 vml000027.dmz.nausch.org named[4394]: received control channel command 'stop' Dec 28 18:35:53 vml000027.dmz.nausch.org systemd[1]: Stopped Berkeley Internet Name Domain (DNS).
Die Abfrage nach den Mount-Points bleibt daher auch entsprechend „unbeantwortet“.
# df -ah | grep named
Der Dokumenten-Baum des bind-daemon ist nunmehr nur noch der ursprüngliche Basiszustand bei der Installation des Daemon selbst.
/var/named/chroot/ ├── dev │ ├── log │ ├── null │ ├── random │ └── zero ├── etc │ ├── named │ └── pki │ └── dnssec-keys ├── run │ └── named ├── usr │ └── lib64 │ └── bind └── var ├── log ├── named ├── run -> ../run └── tmp
Zu guter Letzt starten wir den Daemon wieder um weiter testen zu können.
# systemctl start named-chroot.service
Ohne jegliche individuelle Konfiguration fungiert der DNS-Server als caching-only-resolver; daher könne wir auch unsere erste Anfrage gegen unseren „neuen“ DNS-Server machen.
# dig @127.0.0.1 ccc.de
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> @127.0.0.1 ccc.de ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43047 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ccc.de. IN A ;; ANSWER SECTION: ccc.de. 7200 IN A 213.73.89.123 ;; AUTHORITY SECTION: ccc.de. 86400 IN NS ns.ham.ccc.de. ccc.de. 86400 IN NS ns.ber.ccc.de. ccc.de. 86400 IN NS s-dns.irz42.net. ccc.de. 86400 IN NS ns.vie.ccc.de. ;; ADDITIONAL SECTION: ns.vie.ccc.de. 86400 IN A 146.255.57.228 ns.vie.ccc.de. 86400 IN AAAA 2a02:1b8:10:31::228 s-dns.irz42.net. 172800 IN A 212.12.50.130 s-dns.irz42.net. 3600 IN AAAA 2a00:14b0:4200:3280::130 ns.ber.ccc.de. 86400 IN A 195.54.164.36 ns.ber.ccc.de. 86400 IN AAAA 2001:67c:20a0:2:0:164:0:36 ns.ham.ccc.de. 86400 IN A 212.12.55.77 ns.ham.ccc.de. 86400 IN AAAA 2a00:14b0:4200:3000:23:55:0:77 ;; Query time: 210 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Dec 28 20:01:32 CET 2017 ;; MSG SIZE rcvd: 319
Erweiterte Konfigurationsbeispiele
caching-only Nameserver
Im ersten Schritt wollen wir erst einmal einen caching-only Nameserver aufsetzen. Die mitgelieferte Konfigurationsdate /etc/named.conf des RPM-Pakets bind passen wir unseren Gegebenheiten an.
# vim /etc/named.conf
- /etc/named.conf
// // named.conf // // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS // server as a caching only nameserver (as a localhost DNS resolver only). // // See /usr/share/doc/bind*/sample/ for example named configuration files. // // See the BIND Administrator's Reference Manual (ARM) for details about the // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html // Django : 2017-12-28 - Variablendefinition // default: unset acl dmz { 10.0.0.0/24; }; acl intra { 10.0.10.0/25; }; options { // Django : 2017-12-28 // default: listen-on port 53 { 127.0.0.1; }; listen-on port 53 { 127.0.0.1; 10.0.0.27; 10.0.10.27;}; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; // Django : 2017-12-28 // default: allow-query { localhost; }; allow-query { localhost; dmz; intra; }; /* - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion. - If you are building a RECURSIVE (caching) DNS server, you need to enable recursion. - If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users. Failing to do so will cause your server to become part of large scale DNS amplification attacks. Implementing BCP38 within your network would greatly reduce such attack surface */ recursion yes; dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; // Django : 2017-12-28 - Rückmeldung Programm und Version verstecken // default: unset version "DNS - nausch.org"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key";
Bevor wir die Konfigurationsänderung aktivieren, prüfen wir noch kurz, ob in der Konfigurationsdatei kein syntaktischer Fehler eingeschlichen hat.
# named-checkconf
Erfolgt keine Fehlermeldung bedeutet dies, dass alles O.K. ist. Nun starten wir den DNS-Daemon einmal durch.
# systemctl restart named-chroot.service
Nun können wir prüfen, ob unser neuer DNS-Server von einem berechtigten Client-Rechner aus nach einer Anfrage zu einem externen Host.
# dig @10.0.0.27 heise.de
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> @10.0.0.27 heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30660
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de. IN A
;; ANSWER SECTION:
heise.de. 85044 IN A 193.99.144.80
;; AUTHORITY SECTION:
heise.de. 85043 IN NS ns.s.plusline.de.
heise.de. 85043 IN NS ns.plusline.de.
heise.de. 85043 IN NS ns.heise.de.
heise.de. 85043 IN NS ns.pop-hannover.de.
heise.de. 85043 IN NS ns2.pop-hannover.net.
;; ADDITIONAL SECTION:
ns.pop-hannover.de. 85043 IN A 193.98.1.200
ns.s.plusline.de. 85043 IN A 212.19.40.14
ns.heise.de. 85043 IN A 193.99.145.37
ns.heise.de. 85043 IN AAAA 2a00:e68:14:800::d1ce
ns2.pop-hannover.net. 171443 IN A 62.48.67.66
ns.plusline.de. 85043 IN A 212.19.48.14
;; Query time: 1 msec
;; SERVER: 10.0.0.27#53(10.0.0.27)
;; WHEN: Do Dez 28 20:58:43 CET 2017
;; MSG SIZE rcvd: 287
Natürlich kann unser caching-resolver auch DNSsec-Anfragen bearbeiten, dies bedarf keiner gesonderten aufwändigen Konfiguration!
$ dig @10.0.0.27 sys4.de +dnssec
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> @10.0.0.27 sys4.de +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57125
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sys4.de. IN A
;; ANSWER SECTION:
sys4.de. 3600 IN A 194.126.158.154
sys4.de. 3600 IN RRSIG A 8 2 3600 20180101183221 20171225211210 44430 sys4.de. YN5f4A3fjghKXy49Nou2ew8pxBC/8P2++NDEpD94WOe7vaqu2TivfW1r dxxomo/6KoonenENnMMzLEUGXIKCZ9bgref+6ihxN1j8CwBes38z+xdS xgaBaIan/P7MTTqADKssjmwoGvLOhHrgi2MWt/QB5idhN6ZpBNdaxY5Y R6A=
;; AUTHORITY SECTION:
sys4.de. 3599 IN NS ns.sys4.de.
sys4.de. 3599 IN NS ns.schiffbauer.net.
sys4.de. 3599 IN RRSIG NS 8 2 3600 20180104123423 20171228151217 44430 sys4.de. wmcNWlp1AbLQbqvMSjN1jTYl7NT+MVSDFEwGUWuAdfc93/PwVmEulRLj LPZ5o8N+Eiv52PVow9D07FjETDUpdirMOjUk55Omq+e+bt5j8TXYxkjH xkvBziyAciQf/77HazZKG2NpI6ASnPa2l3Hrm5KeVcmVVWAwYOlpPmHR WeY=
;; ADDITIONAL SECTION:
ns.sys4.de. 86399 IN A 194.126.158.143
ns.schiffbauer.net. 172799 IN A 188.40.110.137
ns.schiffbauer.net. 3599 IN AAAA 2a01:4f8:221:2c82::2
ns.sys4.de. 3599 IN RRSIG A 8 3 3600 20171231181435 20171224191208 44430 sys4.de. h0hEMpr8zmYlrc5NI/yEkP7w6eZrAqRWqCmCnHYMRRT6bCE7TLYbo73A r1/BKK7fV4hdwRwXIeP28Mle9igBqm42m/JessFGzanLo+ckWSRfAx2/ sCrUNzIM+cy0BGTLXg7Pld8r7aouKT83kSwBAuxQr0ZK4S4j1zNWOvrW MbE=
;; Query time: 297 msec
;; SERVER: 10.0.0.27#53(10.0.0.27)
;; WHEN: Do Dez 28 20:38:01 CET 2017
;; MSG SIZE rcvd: 662
Root Hints Data File
Bei der Installation unseres Nameservers mit Hilfe des RPMs wurde eine Datei mit den 13 ROOT-Nameservern mitgeliefert. Diese Liste ist jedoch nicht statisch und sollte erfahrungsgemäß alle sechs Monate einmal aktualisiert werden.
Wir können uns diese Datei direkt vom FTP-Server der InterNIC laden. Hierzu benutzen wir z.B. folgenden Befehl:
# wget --user=ftp --password=ftp ftp://ftp.rs.internic.net/domain/db.cache -O /var/named/named.ca
; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.cache ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: November 16, 2017 ; related version of root zone: 2017111601 ; ; FORMERLY NS.INTERNIC.NET ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30 ; ; FORMERLY NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201 B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b ; ; FORMERLY C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c ; ; FORMERLY TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13 D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d ; ; FORMERLY NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 E.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:a8::e ; ; FORMERLY NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f ; ; FORMERLY NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 G.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:12::d0d ; ; FORMERLY AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53 H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53 ; ; FORMERLY NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53 ; ; OPERATED BY VERISIGN, INC. ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30 ; ; OPERATED BY RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1 ; ; OPERATED BY ICANN ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42 L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42 ; ; OPERATED BY WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
Zum Neueinlesen der Root Hints Daten Datei starten wir den BIND-Daemon einmal durch.
# systemctl restart named-chroot.service
Alternativ dazu können wir auch die Datei mit Hilfe eines DNS-Lookups aktualisieren.
# dig +bufsize=1200 +norec NS . @a.root-servers.net > /var/named/named.ca
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> +bufsize=1200 +norec NS . @a.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42016 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS e.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: e.root-servers.net. 518400 IN A 192.203.230.10 e.root-servers.net. 518400 IN AAAA 2001:500:a8::e h.root-servers.net. 518400 IN A 198.97.190.53 h.root-servers.net. 518400 IN AAAA 2001:500:1::53 l.root-servers.net. 518400 IN A 199.7.83.42 l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 i.root-servers.net. 518400 IN A 192.36.148.17 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 a.root-servers.net. 518400 IN A 198.41.0.4 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 d.root-servers.net. 518400 IN A 199.7.91.13 d.root-servers.net. 518400 IN AAAA 2001:500:2d::d c.root-servers.net. 518400 IN A 192.33.4.12 c.root-servers.net. 518400 IN AAAA 2001:500:2::c b.root-servers.net. 518400 IN A 199.9.14.201 b.root-servers.net. 518400 IN AAAA 2001:500:200::b j.root-servers.net. 518400 IN A 192.58.128.30 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 518400 IN A 193.0.14.129 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 g.root-servers.net. 518400 IN A 192.112.36.4 g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d m.root-servers.net. 518400 IN A 202.12.27.33 m.root-servers.net. 518400 IN AAAA 2001:dc3::35 f.root-servers.net. 518400 IN A 192.5.5.241 f.root-servers.net. 518400 IN AAAA 2001:500:2f::f ;; Query time: 39 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Fri Dec 29 10:07:19 CET 2017 ;; MSG SIZE rcvd: 811
Auch hier müssen wir natürlich zum Neueinlesen der Datei den Daemon einmal durchstarten.
# systemctl restart named-chroot.service
Damit wir die Datei nun nicht manuell aktualisieren müssen, werden wir uns einen cronjob anlegen. Wir werden dabei die erste Variante verwenden, da in der heruntergeladenen Datei auch das Aktualisierungsdatum steht, welches wir ggf. später auswerten bzw. überwachen können.
# vim /root/bin/update-dns-roots
- /root/bin/update-dns-roots
#!/bin/bash # Django : 2017-12-29 - Script zum Aktualisieren des Root Hints Data File /usr/bin/wget --user=ftp --password=ftp ftp://ftp.rs.internic.net/domain/db.cache -O /var/named/named.ca /usr/bin/systemctl restart named-chroot.service
Anschließen statten wir die Datei noch mit den eXecutable-Rechten aus, damit wir es direkt aufrufen können.
# chmod +x /root/bin/update-dns-roots
Abschließend tragen wir noch in die crontab ein, dass alle 5 Monate die Datei aktualisiert werden soll.
# vim /etc/crontab
- /etc/crontab
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed # Django : 2017-12-29 - alle fünft Monate Aktualisieren der BIND Root Hints Data File 20 3 * */5 * /root/bin/update-dns-roots >/dev/null 2>&1
Zonen-Dateien für lokale Adressen
In nun folgenden Konfigurationsbeispiel wollen wir einen primären DNS-Server aufsetzen, der folgende zwei Zonen verwalten soll:
- DMZ : Domäne dmz.nausch.org - IP-Netz: 10.0.0.0/24
- INTRA : Domäne intra.nausch.org - IP-Netz: 10.0.10.0/25
Die Clientanfragen aus den beiden Netzen sollen dabei mit Hilfe unterschiedlicher views voneinander getrennt werden, so dass ein Client aus dem Intranet für die gleiche Anfrage wie von einen anderen Client aus der DMZ unterschiedliche Antworten bekommen soll.
- view - INTRA
- view - DMZ
Bevor wir nun die notwendigen Zonen-Dateien für unseren DNS-Server anlegen werden, legen wir uns zunächst eine eigenen Verzeichnis an, in dem wir später dann die Zonen-Dateien ablegen werden.
# mkdir /var/named/master # mkdir /var/named/intra
Anschließend statten wir unser neues Konfigurationsverzeichnis noch mit den nötigen Datei, Benutzer- und Gruppenrechten aus.
# chown named:named /var/named/master # chown named:named /var/named/intra
# chmod 770 /var/named/master # chmod 770 /var/named/intra
Nun können wir für jede Zone in unserem neuen Verzeichnis /var/named/master jeweils die benötigten Dateien anlegen.
- Zone INTRANET
- Zonen-Datei für die Forward-Auflösung - /var/named/master/intra.nausch.org.zone.db
- Zonen-Datei für die Reverse-Auflösung - /var/named/master/10.0.10.zone.db - Netz 10.0.10.0/25
- Zone DMZ (für die Anfragen aus der DMZ)
- Zonen-Datei für die Forward-Auflösung - /var/named/master/dmz.nausch.org.zone.db
- Zonen-Datei für die Reverse-Auflösung - /var/named/master/0.0.10.zone.db - Netz 10.0.0.0/24
- Zone DMZ (für die Anfragen aus dem Intranet)
- Zonen-Datei für die Forward-Auflösung - /var/named/intra/dmz.nausch.org.zone.db für die Anfragen aus dem Intranet
- Zonen-Datei für die Reverse-Auflösung - /var/named/intra/0.0.10.zone.db - Netz 10.0.0.0/24 für die Anfragen aus dem Intranet
intra.nausch.org.zone.db
Zunächst legen wir uns also die Zonen-Datei für die Forward-Auflösung der Zone INTRANET an.
# vim /var/named/master/intra.nausch.org.zone.db
- /var/named/master/intra.nausch.org.zone.db
$ORIGIN . $TTL 86400 ; 1 day intra.nausch.org IN SOA ns1.intra.nausch.org. hostmaster.nausch.org. ( 2017122901 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.intra.nausch.org. MX 10 mx1.nausch.org. $ORIGIN intra.nausch.org. ns1 A 10.0.10.27 vml010027 A 10.0.10.27 pml010051 A 10.0.10.17 $ORIGIN intra.nausch.org. test CNAME ns1 fwi CNAME vml010027 gateway CNAME vml010027 proton CNAME pml010051
Zur Prüfung unserer gerade angelegten Zonendatei nutzen wir folgenden Befehl:
# named-checkzone intra.nausch.org /var/named/master/intra.nausch.org.zone.db
zone intra.nausch.org/IN: loaded serial 2017122901 OK
10.0.10.zone.db
Nun legen wir für die Reverseauflösung der Zone INTRANET für das IP-Netz 10.0.10.0/25 das zugehörige Zonenfile an.
# vim /var/named/master/10.0.10.in-addr.arpa.zone.db
- /var/named/master/10.0.10.in-addr.arpa.zone.db
$TTL 86400 ; 1 day @ IN SOA ns1.intra.nausch.org. hostmaster.nausch.org. ( 2017122901 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.intra.nausch.org. MX 10 mx1.nausch.org. 27 PTR ns1.intra.nausch.org. 51 PTR pml010051.intra.nausch.org.
Wie schon zuvor bei der Zonen-Datei für die Forward-Auflösung checken wir nun auch hier die gerade angelegte Datei auf Tippfehler mit folgenden Befehl:
# named-checkzone 10.0.10 /var/named/master/10.0.10.in-addr.arpa.zone.db
zone 10.0.10/IN: loaded serial 2017122901 OK
dmz.nausch.org.zone.db
Nachdem wir die Konfiguration der Zone Intranet abgeschlossen haben, werden wir nun als nächstes die Zone DMZ konfigurieren. Als erstes werden wir auch hier das Zonefile für die Forwardauflösung anlegen.
# vim /var/named/master/dmz.nausch.org.zone.db
- /var/named/master/dmz.nausch.org.zone.db
$ORIGIN . $TTL 86400 ; 1 day dmz.nausch.org IN SOA ns1.dmz.nausch.org. hostmaster.nausch.org. ( 2017122901 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.dmz.nausch.org. MX 10 mx1.nausch.org. $ORIGIN dmz.nausch.org. ns1 A 10.0.0.27 vml000017 A 10.0.0.17 vml000027 A 10.0.0.27 $ORIGIN dmz.nausch.org. test CNAME ns1 fwe CNAME vml000017 fwi CNAME vml000027
Auch hier führen wir den Syntax- und Plausibilitäts-Check durch.
# named-checkzone dmz.nausch.org /var/named/master/dmz.nausch.org.zone.db
zone dmz.nausch.org/IN: loaded serial 2017122901 OK
0.0.10.zone.db
Was nun noch fehlt ist das Zonenfile für die Zonendatei für die Reverseauflösung der Zone DMZ.
# vim /var/named/master/0.0.10.in-addr.arpa.zone.db
- /var/named/master/0.0.10.in-addr.arpa.zone.db
$TTL 86400 ; 1 day @ IN SOA ns1.dmz.nausch.org. hostmaster.nausch.org. ( 2017122901 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.dmz.nausch.org. MX 10 mx1.nausch.org. 17 PTR vml000017.dmz.nausch.org. 27 PTR vml000027.dmz.nausch.org.
Wie schon zuvor bei der Zonen-Datei für die Forward-Auflösung checken wir nun auch hier die gerade angelegte Datei auf Tippfehler mit folgenden Befehl:
# named-checkzone 0.0.10 /var/named/master/0.0.10.in-addr.arpa.zone.db
zone 0.0.10/IN: loaded serial 2017122901 OK
dmz.nausch.org.zone.db (intra)
Nachdem wir die Konfiguration der Zone Intranet abgeschlossen haben, werden wir nun als nächstes die Zone DMZ konfigurieren. Als erstes werden wir auch hier das Zonefile für die Forwardauflösung anlegen.
# vim /var/named/intra/dmz.nausch.org.zone.db
- /var/named/intra/dmz.nausch.org.zone.db
$ORIGIN . $TTL 86400 ; 1 day dmz.nausch.org IN SOA ns1.dmz.nausch.org. hostmaster.nausch.org. ( 2017122901 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.dmz.nausch.org. MX 10 mx1.nausch.org. $ORIGIN dmz.nausch.org. ns1 A 10.0.0.27
Auch hier führen wir den Syntax- und Plausibilitäts-Check durch.
# named-checkzone dmz.nausch.org /var/named/intra/dmz.nausch.org.zone.db
zone dmz.nausch.org/IN: loaded serial 2017122901 OK
0.0.10.zone.db (intra)
Was nun noch fehlt ist das Zonenfile für die Zonendatei für die Reverseauflösung der Zone DMZ.
# vim /var/named/intra/0.0.10.in-addr.arpa.zone.db
- /var/named/intra/0.0.10.in-addr.arpa.zone.db
$TTL 86400 ; 1 day @ IN SOA ns1.dmz.nausch.org. hostmaster.nausch.org. ( 2017122901 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.dmz.nausch.org. MX 10 mx1.nausch.org. 27 PTR ns1.dmz.nausch.org.
Wie schon zuvor bei der Zonen-Datei für die Forward-Auflösung checken wir nun auch hier die gerade angelegte Datei auf Tippfehler mit folgenden Befehl:
# named-checkzone 0.0.10 /var/named/intra/0.0.10.in-addr.arpa.zone.db
zone 0.0.10/IN: loaded serial 2017122901 OK
named.conf
Für unser Konfigurationsbeispiel legen wir uns nun eine eigene individuelle Konfigurationsdatei an, die all unsere Anwendungsfälle abdeckt. Die enizelnen Optionen sind in der Konfigurationsdatei /etc/named.conf ausführlich beschrieben.
# vim /etc/named.conf
- /etc/named.conf
/* ****************************** named.conf ****************************** */ // ISC Bind Konfigurationsdatei auf Basis der Beispiels-Konfigurationsdatei // /usr/share/doc/bind*/sample/ aus dem zugehörigen RPM-Paket // Konfig-Beschreibung: https://dokuwiki.nausch.org/doku.php/centos:bind_c7 /* ********** Variablendefinition für die unterschiedlichen ACLs ********** */ acl dmz { 10.0.0.0/24; }; acl intra { 10.0.10.0/25; }; acl primary { 10.0.0.27/32; }; acl interfaces { 10.0.0.27/32; 10.0.10.27/32; }; /* *********************** rndc Schlüsseldefinition *********************** */ include "/etc/rndc_local.key"; /* *********************** rndc Control-Definition ************************ */ controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; /* ***************** Definition der allgemeinen Optionen ****************** */ options { // Arbeitsverzeichnis des Servers directory "/var/named"; // Das Verzeichnis, in dem sich die öffentlichen und privaten // DNSSEC-Schlüsseldateien befinden sollen. key-directory "/var/named"; // Das Verzeichnis, in dem die Dateien gespeichert werden, welche // die verwalteten DNSSEC-Schlüssel verfolgen. managed-keys-directory "/var/named/dynamic"; // Pfadname der Datei, um die eingebauten vertrauenswürdigen Schlüssel // von named zu überschreiben. Pfad zum ISC DLV Schlüssel. bindkeys-file "/etc/named.iscdlv.key"; // Der Pfadname der Datei, in die ein TSIG-Sitzungsschlüssel geschrieben // werden soll, der mit named für die Verwendung durch nsupdate -l // erzeugt wurde. session-keyfile "/run/named/session.key"; // Der Pfadname der Datei, auf die der Server die security roots // schreibt, wenn er hierzu angewiesen wird. secroots-file "/var/named/data/named_secroots.db"; // Der Pfadname der Datei, auf die der Server die Datenbank übergibt, // wenn er angewiesen wird. dump-file "/var/named/data/cache_dump.db"; // Der Pfadname der Datei, an die der Server Statistiken anhängt, // wenn er Server hierzu angewiesen wird. statistics-file "/var/named/data/named_stats.txt"; // Der Pfadname der Datei, in die der Server beim Beenden die // Speicherverbrauchsstatistik schreibt. memstatistics-file "/var/named/data/named_mem_stats.txt"; // Pfadname der Datei, in die der Server Abfragen, die gerade // wiederkehren, ausgibt, wenn er dazu angewiesen wird. recursing-file "/var/named/data/named_recursing.db"; // Pfadname der Datei, in die der Server seine Prozess-ID schreibt. pid-file "/run/named/named.pid"; // Wird folgender Parameter auf "yes" gesetzt, dann fügt der Server // bei der Generierung von Antworten nur dann Datensätze zur authority // und additional data sections hinzu, wenn sie benötigt werden. minimal-responses no; /* Wird folgender Parameter auf "yes" gesetzt, dann wird der Server versuchen bei einer rekursiven DNS-Abfrage, alles versuchen um die Anfrage bestmöglich abzuarbeiten. Ist die Rekursion ausgeschaltet ist und der Server die Antwort noch nicht kennt, gibt er eine referral response (Empfehlungsantwort) zurück. Die Default-Einstellung ist "yes". Wichtig: Das Setzen der Rekursions-Option auf "no" verhindert nicht, dass Clients Daten aus dem Server-Cache beziehen; es verhindert nur, dass neue Daten als Folge von Client-Abfragen zwischengespeichert werden. Sofern der rekursiver DNS-Server über eine öffentliche IP-Adresse verfügt, MUSS zwingend eine Zugriffskontrolle aktiviert werden, um Abfragen auf die legitimen Benutzer zu beschränken! Nichtbeachtung kann zu Folgen haben, dass sonst der Server ein Teil von groß angelegten DNS-Amplifikations-Angriffen werden könnte. Die Implementierung von BCP38 in Ihrem Netzwerk würde diese Angriffsfläche erheblich reduzieren! */ recursion yes; // DNSsec-Support aktivieren dnssec-enable yes; /* DNSsec-Validierung aktivieren und mit den Root-Zertificaten abgleichen. "yes" = DNSSEC-Validierung ist aktiviert, aber ein Vertrauensanker muss manuell konfiguriert werden. Eine Validierung findet erst dann statt, wenn mindestens einen vertrauenswürdigen Schlüssel manuell konfiguriert haben. Dies ist die Voreinstellung. "no" = Die DNSSEC-Validierung ist deaktiviert, und rekursive Server verhalten sich in der "altmodischen" Art und Weise, unsichere DNS-Lookups durchzuführen. "auto"= Die DNSSEC-Validierung ist aktiviert, und es wird ein Standard-Trust-Anker (als Teil von BIND enthalten) für die DNS-Rootzone verwendet. */ dnssec-validation auto; /* Wird diese option gesetzt, stellt dnssec-lookaside dem validator eine alternative Methode zur Verfügung, um DNSKEY-Einträge bei Start einer Zone (top of a zone) zu validieren. Wenn dnssec-lookaside auf auto gesetzt ist, dann werden die eingebauten Standardwerte für die DLV-Domäne und den Vertrauensanker verwendet, zusammen mit einem eingebauten Schlüssel für die Validierung. */ dnssec-lookaside auto; // Diese Option wird verwendet, um den Zeichensatz und die Syntax // bestimmter Domänennamen in Masterdateien und/oder DNS-Antworten, // die vom Netzwerk empfangen werden, einzuschränken. check-names master warn; // Gibt an, welche Hosts diesen Server, einen Slave, zusätzlich zu den // Zonen-Mastern über Zonenänderungen benachrichtigen dürfen. allow-notify { 127.0.0.1; }; // Definiert, welche Hosts gewöhnliche DNS-Fragen stellen dürfen. allow-query { ::1; 127.0.0.1; dmz; intra; }; // Legt fest, welche Hosts rekursive Abfragen über diesen Server // durchführen dürfen. allow-recursion { ::1; 127.0.0.1; dmz; intra; }; // Gibt an, welche Hosts Zonentransfers vom Server empfangen dürfen. allow-transfer { 127.0.0.1; primary; }; // Gibt eine Liste von Adressen an, von denen der Server keine Anfragen // annimmt oder die zur Lösung einer Anfrage verwendet werden. Anfragen // von diesen Adressen werden nicht beantwortet. blackhole { none; }; // Die Schnittstellen und Ports, von denen der Server Anfragen // beantwortet, können mit der Listen-On-Option angegeben werden. listen-on port 53 { 127.0.0.1; interfaces; }; listen-on-v6 port 53 { ::1; }; // Sofern der Server die Antwort auf eine Frage nicht kennt, fragt er // andere Nameserver ab. query-source gibt die Adresse und den Port an, // die für solche Abfragen verwendet werden. query-source address * port *; // Maximale Größe eines Core Dump coresize default; // Maximale Größe an RAM, die der Server verbrauchen darf. datasize default; // Maximale Anzahl von geöffneten Dateien. files unlimited; // Maximale Menge an Stack-Speicher, die der Server verwenden darf. stacksize default; // Maximale Größe jeder Journaldatei fest. // (default ist unbegrenzt, was auch 2 Gigabyte bedeutet) max-journal-size unlimited; // Maximale Anzahl gleichzeitiger rekursiver Suchvorgänge, die der Server // für Clients durchführt. Der Standardwert ist 1000. recursive-clients 1000; // Maximale Anzahl gleichzeitiger TCP Verbindungen die der Server von // Clients akzeptiert. Der Standardwert ist 100. tcp-clients 100; /* Maximale Menge an Arbeitsspeicher (in Bytes), die für den Server-Cache verwendet werden kann. Ein Wert von 0 ist speziell, d.h. Datensätze werden nur aus dem Cache gelöscht, wenn ihre TTLs ablaufen ist. Ein weiteres spezielles Schlüsselwort unlimited bedeutet den maximalen Wert von 32-Bit-Ganzzahlen ohne Vorzeichen (0xffffffffffff), die haben nicht den gleichen Effekt wie 0 auf Maschinen, die mehr als 32 Bit unterstützen. Alle positiven Werte kleiner als 2MB werden ignoriert und auf 2MB gesetzt. Bei einem Server mit mehreren Views gilt die Begrenzung separat für den Cache der einzelnen Views. Der Standardwert ist 0. */ max-cache-size 0; /* List Queue Depth: Die Standardeinstellung und das Minimum ist 10. Sofern der Kernel Accept-Filter-Verbindungen unterstützt, werden die Daten im Kernel-Space gehalten und gewartet bevor die Anfrage weiterverarbeitet wird. Werte ungleich 0 unter 10 werden stillschweigend erhöht. ein Wert von 0 kann gesetzt werden und definiert auf den meisten Plattformen, dass die Länge der Listen-Warteschlange auf einen systembedingter Standardwert gesetzt wird. */ tcp-listen-queue 10; /* Der Server scannt die Liste der Netzwerkschnittstellen in regelmäßigen Abständen (Minuten). Die Standardeinstellung ist 60 Minuten. Der Maximalwert beträgt 28 Tage (40320 Minuten). Wird der wert auf 0 gesetzt, erfolgt die Überprüfung der Schnittstelle nur dann, wenn die Konfigurationsdatei geladen wird. Nach dem Scan beginnt der Server mit dem Abhören von Abfragen auf neu entdeckte Interfaces (vorausgesetzt, sie sind durch die Listen-On-Konfiguration erlaubt) und hört auf, auf nicht mehr vorhandene Interfaces zu hören. */ interface-interval 0; /* Definiert die Zeit in Sekunden, in denen eine lahme Serveranzeige zwischengespeichert wird. 0 deaktiviert das Caching. (Dies wird NICHT empfohlen!) Der Standardwert ist 600 (10 Minuten) und der Maximalwert ist 1800 (30 Minuten). */ lame-ttl 600; /* Um den Netzwerkverkehr zu reduzieren und die Leistung zu erhöhen, speichert der Server negative Antworten. max-ncache-ttl wird verwendet, um eine maximale Aufbewahrungszeit für diese Antworten im Server in Sekunden festzulegen. Die Standardeinstellung von max-ncache-ttl ist 10800 Sekunden (3 Stunden). max-ncache-ttl kann nicht länger als 7 Tage dauern und wird stillschweigend auf 7 Tage gekürzt, sollte er auf einen größeren Wert gesetzt werden! */ max-ncache-ttl 10800; /* Legt die maximale Zeit fest, für die der Server gewöhnliche (positive) Antworten zwischenspeichert. Der Standardwert ist eine Woche (7 Tage). Ein Wert von Null kann dazu führen, dass alle Abfragen SERVFAIL zurückgeben, da im Auflösungsprozess verloren gegangene Caches von Zwischen-RRsets (z.B. NS und glue AAAA/A-Records) verloren gehen! */ max-cache-ttl 604800; /* Definiert die Größe des angebotenen EDNS UDP-Puffers (in Bytes), um die Größe der empfangenen Pakete zu kontrollieren. Gültige Werte sind 512 bis 4096 (Werte außerhalb dieses Bereichs werden stillschweigend angepasst). Der Standardwert ist 4096. Der übliche Grund für das Setzen von edns-udp-size auf einen nicht standardmäßigen Wert ist es, UDP-Antworten zu erhalten, um durch gebrochene Firewalls zu gehen, die fragmentierte Pakete blockieren und/oder UDP-Pakete blockieren, die größer als 512 Bytes sind. named wird auf die Verwendung von 512 Bytes zurückgreifen, wenn es eine Reihe von Zeitüberschreitungen beim Anfangswert erhält. 512 Bytes werden nicht angeboten, um Websites zu ermutigen, ihre Firewalls zu reparieren. Kleine EDNS UDP-Größen führen zu einer übermäßigen Nutzung von TCP. */ edns-udp-size 4096; /* Legt die maximale EDNS UDP-Nachrichtengröße fest, die in Bytes gesendet wird. Gültige Werte sind 512 bis 4096 (Werte außerhalb dieses Bereichs werden stillschweigend angepasst). Der Standardwert ist 4096. Der übliche Grund für das Setzen von max-udp-size auf einen nicht standardmäßigen Wert ist es, UDP-Antworten zu erhalten, um durch defekte Firewalls zu gehen, die fragmentierte Pakete blockieren und/oder UDP-Pakete blockieren, die größer als 512 Bytes sind. Dies ist unabhängig vom beworbenen Empfangspuffer (edns-udp-size). Wird dieser Wert auf einen niedrigen Wert gesetzt, wird zusätzlicher TCP-Verkehr zum Nameserver erzeugt! */ max-udp-size 4096; /* Definiert den Anfangswert (Minimum) der Anzahl rekursiver gleichzeitiger Clients für eine beliebige Abfrage (<qname,qtype,qclass>) fest, die der Server akzeptiert, bevor er weitere Clients ignorieren wird. Named wird versuchen, diesen Wert selbst zu tunen und Änderungen werden protokolliert. Der Standardwerte ist 10. */ clients-per-query 10; /* Definiert den Anfangswert (Maximum) der Anzahl rekursiver gleichzeitiger Clients für eine beliebige Abfrage (<qname,qtype,qclass>) fest, die der Server akzeptiert, bevor er neue Client-Verbindungen anlehnen wird. Named wird versuchen, diesen Wert selbst zu tunen und Änderungen werden protokolliert. Die Standardeinstellung ist 100. */ max-clients-per-query 100; /* Festlegung der Angaben (Version), die der Server über eine Abfrage des Namens version.bind mit dem Typ TXT, Klasse CHAOS, melden soll. Der Default-Wert ist die reale Versionsnummer des Servers. Durch die Angabe der Version none wird die Verarbeitung der Abfragen deaktiviert. */ version "DNS - nausch.org"; /* Der Hostname, den der Server über eine Abfrage des Namens hostname.bind mit dem Typ TXT, Klasse CHAOS, melden soll. Dies ist standardmäßig der Hostname des Rechners, auf dem sich der Name-Server befindet, wie er von der Funktion gethostname() gefunden wird. Die ID, die der Server beim Empfang einer NSID-Abfrage (Name Server Identifier) oder einer Abfrage des Namens ID.SERVER vom Typ TXT, Klasse CHAOS, melden soll. Der primäre Zweck solcher Abfragen ist es, herauszufinden, welcher einer Gruppe von Anycast-Servern Ihre Anfragen tatsächlich beantwortet. Angabe von server-id none; deaktiviert die Verarbeitung der Abfragen. Die Angabe von server-id hostname; bewirkt, dass named den Hostnamen verwendet, wie er durch die Funktion gethostname() gefunden wurde. Der Standardwert ist none. */ server-id none; }; /* ******************* Definition der Logging-Parameter ******************* */ logging { // Definition der unterschiedlichen Kanäle // Standard-Startmeldungen channel default_debug { file "data/named.run"; severity dynamic; print-category yes; print-severity yes; print-time yes; }; // Genehmigung und Ablehnung von DNS-Anfragen channel custom_security { file "data/named.security"; severity info; print-category yes; print-severity yes; print-time yes; }; // Lame servers. Dabei handelt es sich um Fehlkonfigurationen bei // Remote-Servern, die von BIND 9 entdeckt wurden, als dieser // versuchte, diese Server während der Auflösung abzufragen. channel custom_lame-servers { file "data/named.lame-servers"; severity info; print-category yes; print-severity yes; print-time yes; }; // Definition der beiden Kathegorien security und lame-servers category security { custom_security; default_syslog; default_debug; }; category lame-servers { custom_lame-servers ; default_syslog; default_debug; }; }; /* ******************** Definition der Views and Zones ******************** */ /* WICHTIG: ======== Die Reihenfolge der View-Anweisungen ist signifikant. Eine Client-Anfrage wird im Kontext der ersten Ansicht beantwortet, zu der sie passt! */ view "intra" IN { // Ist der Anfragende Client aus dem Netz 10.0.10.0/25 (Intranet)? match-clients { intra; }; /* ACHTUNG: Eine Zone kann entweder durch Bearbeiten von Zonendateien und Neuladen des Servers oder durch dynamisches Update aktualisiert werden, aber NIEMALS durch beides! Ist die dynamische Aktualisierung für eine Zone mit der Option "allow-update" aktiviert, darf KEINENFALLS die Zonendatei manuell bearbeitet werden! Der Server würde dann nicht mehr versuchen, die Informationen zur Zone aus der Datei zu laden! */ // Zone: root server zone "." IN { type hint; file "named.ca"; }; // Zone: localhost include "/etc/named.rfc1912.zones"; // Zone: intra.nausch.org (forward) zone "intra.nausch.org" IN { type master; file "master/intra.nausch.org.zone.db"; }; // Zone: intra.nausch.org (reverse) zone "10.0.10.in-addr.arpa" IN { type master; file "master/10.0.10.in-addr.arpa.zone.db"; }; // Zone: dmz.nausch.org (forward) zone "dmz.nausch.org" IN { type master; file "intra/dmz.nausch.org.zone.db"; }; // Zone: dmz.nausch.org (reverse) zone "0.0.10.in-addr.arpa" IN { type master; file "intra/0.0.10.in-addr.arpa.zone.db"; }; }; view "dmz" IN { // Ist der Anfragende Client aus dem Netz 10.0.0.0/24 (DMZ)? match-clients { localhost; dmz; }; /* ACHTUNG: Eine Zone kann entweder durch Bearbeiten von Zonendateien und Neuladen des Servers oder durch dynamisches Update aktualisiert werden, aber NIEMALS durch beides! Ist die dynamische Aktualisierung für eine Zone mit der Option "allow-update" aktiviert, darf KEINENFALLS die Zonendatei manuell bearbeitet werden! Der Server würde dann nicht mehr versuchen, die Informationen zur Zone aus der Datei zu laden! */ // Zone: root server zone "." IN { type hint; file "named.ca"; }; // Zone: localhost include "/etc/named.rfc1912.zones"; // Zone: intra.nausch.org (forward) zone "intra.nausch.org" IN { type master; file "master/intra.nausch.org.zone.db"; }; // Zone: intra.nausch.org (reverse) zone "10.0.10.in-addr.arpa" IN { type master; file "master/10.0.10.in-addr.arpa.zone.db"; }; // Zone: dmz.nausch.org (forward) zone "dmz.nausch.org" IN { type master; file "master/dmz.nausch.org.zone.db"; }; // Zone: dmz.nausch.org (reverse) zone "0.0.10.in-addr.arpa" IN { type master; file "master/0.0.10.in-addr.arpa.zone.db"; }; }; /* *************************** sonstige includes ************************** */ include "/etc/named.root.key";
Bevor wir zur Aktivierung unserer Konfiguration nun den Nameserver einmal durchstarten überprüfen wir noch, ob sich kein Schreibfehler oder sonstiger Konfigurationsfehler eingeschlichen hat.
# named-checkconf
Geben wir beim Aufruf des Befehls named-checkconf die Option -p an, wird uns die (aufgelöste) Konfiguration ohne die ganzen Kommentare ausgegeben.
# named-checkconf -p
options { bindkeys-file "/etc/named.iscdlv.key"; blackhole { "none"; }; coresize default; datasize default; session-keyfile "/run/named/session.key"; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; files unlimited; interface-interval 0; listen-on port 53 { 127.0.0.1/32; "interfaces"; }; listen-on-v6 port 53 { ::1/128; }; managed-keys-directory "/var/named/dynamic"; memstatistics-file "/var/named/data/named_mem_stats.txt"; pid-file "/run/named/named.pid"; recursing-file "/var/named/data/named_recursing.db"; recursive-clients 1000; secroots-file "/var/named/data/named_secroots.db"; server-id none; stacksize default; statistics-file "/var/named/data/named_stats.txt"; tcp-clients 100; tcp-listen-queue 10; version "DNS - nausch.org"; allow-recursion { ::1/128; 127.0.0.1/32; "dmz"; "intra"; }; check-names master warn; clients-per-query 10; dnssec-enable yes; dnssec-lookaside auto; dnssec-validation auto; edns-udp-size 4096; lame-ttl 600; max-cache-size 0; max-cache-ttl 604800; max-clients-per-query 100; max-ncache-ttl 10800; max-udp-size 4096; minimal-responses no; query-source address 0.0.0.0 port 0; recursion yes; allow-notify { 127.0.0.1/32; }; allow-query { ::1/128; 127.0.0.1/32; "dmz"; "intra"; }; allow-transfer { 127.0.0.1/32; "primary"; }; key-directory "/var/named"; max-journal-size unlimited; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1/32; } keys { "rndc-key"; }; }; acl "dmz" { 10.0.0.0/24; }; acl "intra" { 10.0.10.0/25; }; acl "primary" { 10.0.0.27/32; }; acl "interfaces" { 10.0.0.27/32; 10.0.10.27/32; }; logging { channel "default_debug" { file "data/named.run"; severity dynamic; print-time yes; print-severity yes; print-category yes; }; channel "custom_security" { file "data/named.security"; severity info; print-time yes; print-severity yes; print-category yes; }; channel "custom_lame-servers" { file "data/named.lame-servers"; severity info; print-time yes; print-severity yes; print-category yes; }; category "security" { "custom_security"; "default_syslog"; "default_debug"; }; category "lame-servers" { "custom_lame-servers"; "default_syslog"; "default_debug"; }; }; view "intra" IN { match-clients { "intra"; }; zone "." IN { type hint; file "named.ca"; }; zone "localhost.localdomain" IN { type master; file "named.localhost"; allow-update { "none"; }; }; zone "localhost" IN { type master; file "named.localhost"; allow-update { "none"; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN { type master; file "named.loopback"; allow-update { "none"; }; }; zone "1.0.0.127.in-addr.arpa" IN { type master; file "named.loopback"; allow-update { "none"; }; }; zone "0.in-addr.arpa" IN { type master; file "named.empty"; allow-update { "none"; }; }; zone "intra.nausch.org" IN { type master; file "master/intra.nausch.org.zone.db"; }; zone "10.0.10.in-addr.arpa" IN { type master; file "master/10.0.10.in-addr.arpa.zone.db"; }; zone "dmz.nausch.org" IN { type master; file "intra/dmz.nausch.org.zone.db"; }; zone "0.0.10.in-addr.arpa" IN { type master; file "intra/0.0.10.in-addr.arpa.zone.db"; }; }; view "dmz" IN { match-clients { "localhost"; "dmz"; }; zone "." IN { type hint; file "named.ca"; }; zone "localhost.localdomain" IN { type master; file "named.localhost"; allow-update { "none"; }; }; zone "localhost" IN { type master; file "named.localhost"; allow-update { "none"; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN { type master; file "named.loopback"; allow-update { "none"; }; }; zone "1.0.0.127.in-addr.arpa" IN { type master; file "named.loopback"; allow-update { "none"; }; }; zone "0.in-addr.arpa" IN { type master; file "named.empty"; allow-update { "none"; }; }; zone "intra.nausch.org" IN { type master; file "master/intra.nausch.org.zone.db"; }; zone "10.0.10.in-addr.arpa" IN { type master; file "master/10.0.10.in-addr.arpa.zone.db"; }; zone "dmz.nausch.org" IN { type master; file "master/dmz.nausch.org.zone.db"; }; zone "0.0.10.in-addr.arpa" IN { type master; file "master/0.0.10.in-addr.arpa.zone.db"; }; }; key "rndc-key" { algorithm "hmac-md5"; secret "TLtbjaRq8ci9RivwIseG42qAL88Vt05UESRrOtT4Kh2oUvU81tosVmHQWeX488lbuVxYfdpKZMD7d76Q6jyCJw=="; }; managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; "." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU="; };
Neustart des Daemon
Da mit der zuvor erstellten Konfiguration unseres Servers alles in Ordnung war, spricht nun nichts mehr dagegen, zur Aktivierung unserer Konfiguration den Daemon einmal durchzustarten.
# systemctl restart named-chroot.service
Den Status des laufenden Daemon fragen wir wie gewohnt wie folgt ab.
# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2017-12-30 18:38:53 CET; 13s ago Process: 13221 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS) Process: 13324 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} -t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS) Process: 13322 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Main PID: 13327 (named) CGroup: /system.slice/named-chroot.service └─13327 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: automatic empty zone: view dmz: B.E.F.IP6.ARPA Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: automatic empty zone: view dmz: 8.B.D.0.1.0.0.2.IP6.ARPA Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: command channel listening on 127.0.0.1#953 Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: managed-keys-zone/intra: loaded serial 0 Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: managed-keys-zone/dmz: loaded serial 0 Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: zone 0.in-addr.arpa/IN/intra: loaded serial 0 Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: zone 10.0.10.in-addr.arpa/IN/intra: loaded serial 2017122901 Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: zone 1.0.0.127.in-addr.arpa/IN/intra: loaded serial 0 Dec 30 18:38:53 vml000027.dmz.nausch.org named[13327]: zone intra.nausch.org/IN/intra: loaded serial 2017122901 Dec 30 18:38:53 vml000027.dmz.nausch.org systemd[1]: Started Berkeley Internet Name Domain (DNS).
Natürlich können wir den Status des DNS-servers auch mit Hilfe des Name Server Control Utility rndc abfragen.
# rndc status
version: 9.9.4-RedHat-9.9.4-51.el7_4.1 (DNS - nausch.org) <id:8f9657aa> CPUs found: 1 worker threads: 1 UDP listeners per interface: 1 number of zones: 208 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running
Zur weiteren Überprüfung und/oder ggf. nötigen Fehlersuche ist ein Blick in folgende Logdateien vorzunehmen:
- /var/log/messages mit
# less /var/log/messages
oder
# tailf /var/log/messages
- /var/named/data/named.run mit
# less /var/named/data/named.run
oder
# tailf /var/named/data/named.run
- /var/named/data/named.lame-servers mit
# less /var/named/data/named.lame-servers
oder
# tailf /var/named/data/named.lame-servers
- /var/named/data/named.security mit
# less /var/named/data/named.security
oder
# tailf /var/named/data/named.security
DNSsec
… do gehda weida!