Einrichten eines DNS-Daemons auf Basis von ISC Bind unter Arch Linux
BIND1) des Internet Systems Consortium ist eine Software, die für die Ausführung der Aufgabe des DNS-Servers verantwortlich ist. Bind ist derzeit ein Standard und wird häufig in Linux-Betriebssystemen und auch in Unix verwendet.
Das Domain Name System (DNS) ist ein hierarchisches verteiltes Namenssystem für Computer, Dienste oder andere Ressourcen, die mit dem Internet oder einem privaten Netzwerk verbunden sind. 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. Es verknüpft verschiedene Informationen mit Domain-Namen, die den einzelnen teilnehmenden Entitäten zugewiesen sind. Vor allem übersetzt es für Menschen verständliche Domain-Namen in numerische Kennungen, die mit Netzwerkgeräten verknüpft sind, um diese Geräte weltweit zu lokalisieren und anzusprechen.
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. BIND 9 ist eine transparente Open-Source-Software, die unter der MPL 2.0-Lizenz lizenziert ist.
In der nachfolgenden WIKI-Artikel wollen wir uns nun eingehender mit der Installation und Konfiguration unseres ISC Bind 9 unter Arch Linux beschäftigen.
Herausforderung / Aufgabenstellung
In unserer SOHO/HomeLAB Umgebung haben wir ein folgende Zonen, für die wir eine Namensauflösung haben:
extern (Internet), Domainspezifisch:
nausch.org mit jeweils öffentlichen IP-Adressen (IPv4 und IPv6)
und ggf. weitere Domains
intern:
EDMZ mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
IDMZ mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
INTRA mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
In unserer Umgebung wollen wir später dafür sorgen, dass je nachdem aus welcher Zone eine Anfrage kommt unterschiedliche Adressen genannt bekommen bzw. unter Umständen einzelne Netzbereich gar ausblenden. Werfen wir kurz einen Blick auf unsere Beispielumgebung:
Wie wir auf dem Schaubild sehen, sollen bestimmte Adressen, je nachdem von welcher Stelle aus diese abgefragt werden, keine Antwort liefern. So können aus dem Internet lediglich offizielle Adressen erfragt werden, nicht jedoch für Interne Adresse aus den beiden Zonen idmz und intra sowie
Anfragen aus der Zone edmz für Adressen aus der Zone intra sollen eben sowenig abfragbar sein. Nur Anfragen aus den beiden Sicherheitszonen idmz und intra sollen für alle Zonen entsprechende Antworten bekommen!
Ferner sollen Anfragen aus den beiden Schutzzonen intra und idmz, welche die offiziellen Domain nausch.org betreffen, als Antwort die „internen“ ULA aus der Zone IDMZ beinhalten, nicht aber die offiziellen GUA-Adressen!
Wir benötigen also einen primary DNS-Server, der als interner DNS-Server für ein privates Netzwerk mit den obigen Zonen agiert. Zusätzlich wollen wir auch noch definieren, wer bei einer Anfrage welche Adresse genannt bekommt. Hierzu werden wir views nutzen, die abhängig von der Stelle aus unserem Netzwerk von dem der Client eine Anfrage startet die passende IP-Adresse genannt bekommt. Ein Client von außen soll also zum Beispiel nach der Frage wie denn die AAAA Adresse von mx1.nausch.org lautet, als Antwort die Adresse 2003:a:e0d:7603:10:0:0:25 bekommen. Ein Client von Intern hingegen soll bei der gleichen Frage aber die Antwort fd00::3:10:0:0:25 bekommen. Realisieren werden wir das wie schon angeschnitten mit unterschiedlichen views für intern und extern.
Installation und Konfiguration des ISC-BIND-Servers
Die Installation und Konfiguration des BIND-Servers gestaltet sich relativ einfach. Bei der Installation des BIND-Paketes verwenden wir unter Arch Linux den Paketmanager pacman.
Als User:
$ sudo pacman -S bind
Als Nutzer mit Root-Rechten entsprechend:
# pacman -S bind
Was uns das Paket bind alles in das System unseres Arch Linux Server gebracht hat, können wir wie folgt abfragen:
Bevor wir nun unseren ISC-BIND konfigurieren und starten müssen wir natürlich sicherstellen, dass auf dem betreffendem Host auch die Kommunikationsbeziehungen entsprechend erlaubt sind.
Wie auch schon früher bei CentOS ab Release 7 bzw. den nachfolgenden Release-Kandidaten Stream von RHEL nutzen wir auch unter Arch Linux den dynamischen firewalld Service. Ein grosser 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 Verbindungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.
In folgendem Konfigurationsbeispiel gehen wir von einem Host aus, der zwei Firewall-Zonen hält, einmal die Zone idmz und einmal die Zone intra. In beiden Zone intra sollen später die DNS-Anfragen der Clients entsprechend beantworten werden.
Damit unsere Clients Verbindungen zu dem geöffneten dhcpv4-Port 67/UDP und dhcpv6-server-Port 547/UDP der beiden zugehörigen Kea-Daemons aufbauen können, müssen wir für diese noch Änderungen am Paketfilter firewalld vornehmen.
Mit Hilfe des Programms firewall-cmd legen wir nun jeweils eine permanente Regel in den beiden Zonen idmz und intra an. Genug der Vorrede, mit nachfolgendem Befehl werden die Ports für den Service dns geöffnet.
Damit der BIND-Servicedaemon namens named automatisch bei jedem Systemstart startet, kann die Einrichtung eines Start-Scriptes über folgenden Befehl erreicht werden:
# systemctl enable named.service
Created symlink '/etc/systemd/system/multi-user.target.wants/named.service' → '/usr/lib/systemd/system/named.service'.
Ein Überprüfung ob der Dienste (Daemon) named wirklich bei jedem Systemstart automatisch mit gestartet wird, kann durch folgenden Befehl erreicht werden:
# systemctl is-enabled named.service
enabled
Starten werden wir den Dienst aber jetzt noch nicht, da wir zunächst den BIND noch konfigurieren und die zugehörigen Zonen-Dateien anlegen müssen!
Basis-Konfiguration
Dokumentation / Man-Pages
Name Server Control Utility rndc
Zur administrativen Interaktion und Steuerung mit unserem DNS-Server nutzen wir das Name Server Control Utility rndc aus dem Paket bind. Die Optionen dieses User Interface finden am einfachsten in der zugehörigen manpage.
RNDC(8) BIND 9 RNDC(8)
NAME
rndc - name server control utility
SYNOPSIS
rndc [-b source-address] [-c config-file] [-k key-file] [-s server] [-p port] [-q] [-r] [-V] [-y server_key] [[-4] | [-6]] {command}
DESCRIPTION
rndc controls the operation of a name server. If rndc is invoked with no command line options or arguments, it prints a short summary of the supported com‐
mands 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 <#std-iscman-named>, the only supported authentication algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256 (default),
HMAC-SHA384, and HMAC-SHA512. They use a shared secret on each end of the connection, which 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 server_key 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
-4 This option indicates use of IPv4 only.
-6 This option indicates use of IPv6 only.
-b source-address
This option indicates 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
This option indicates config-file as the configuration file instead of the default, /etc/rndc.conf.
-k key-file
This option indicates key-file as the key file instead of the default, /etc/rndc.key. The key in /etc/rndc.key is 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 com‐
mand line, the host named by the default-server clause in the options statement of the rndc configuration file is used.
-p port
This option instructs BIND 9 to send commands to TCP port port instead of its default control channel port, 953.
-q This option sets quiet mode, where message text returned by the server is not printed unless there is an error.
-r This option instructs rndc to print the result code returned by named <#std-iscman-named> after executing the requested command (e.g., ISC_R_SUCCESS,
ISC_R_FAILURE, etc.).
-t timeout
This option sets the idle timeout period for rndc to timeout seconds. The default is 60 seconds, and the maximum settable value is 86400 seconds (1
day). If set to 0, there is no timeout.
-V This option enables verbose logging.
-y server_key
This option indicates use of the key server_key from the configuration file. For control message validation to succeed, server_key must be known by
named <#std-iscman-named> with the same algorithm and secret string. If no server_key is specified, rndc first looks for a key clause in the server
statement of the server being used, or if no server statement is present for that host, then in 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, and 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:
addzone zone [class [view]] configuration
This command adds 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 <#std-iscman-named.conf>.
The configuration is saved in a file called viewname.nzf (or, if named <#std-iscman-named> is compiled with liblmdb, an LMDB database file called
viewname.nzd). viewname is the name of the view, unless the view name contains characters that are incompatible with use as a file name, in which case
a cryptographic hash of the view name is used instead. When named <#std-iscman-named> is restarted, the file is loaded into the view configuration so
that zones that were added can persist after a restart.
This sample addzone command adds the zone example.com to the default view:
rndc addzone example.com '{ type primary; file "example.com.db"; };'
(Note the brackets around and semi-colon after the zone configuration text.)
See also rndc delzone and rndc modzone.
delzone [-clean] zone [class [view]]
This command deletes a zone while the server is running.
If the -clean argument is specified, the zone's master file (and journal file, if any) are deleted along with the zone. Without the -clean option,
zone files must be deleted manually. (If the zone is of type secondary or stub, the files needing to be removed are reported in the output of the rndc
delzone command.)
If the zone was originally added via rndc addzone, then it is removed permanently. However, if it was originally configured in named.conf <#
std-iscman-named.conf>, then that original configuration remains in place; when the server is restarted or reconfigured, the zone is recreated. To re‐
move it permanently, it must also be removed from named.conf <#std-iscman-named.conf>.
See also rndc addzone and rndc modzone.
dnssec (-status | -step | -rollover -key id [-alg algorithm] [-when time] | -checkds [-key id [-alg algorithm]] [-when time] published | withdrawn)) zone
[class [view]]
This command allows you to interact with the "dnssec-policy" of a given zone.
rndc dnssec -status show the DNSSEC signing state for the specified zone.
rndc dnssec -step sends a signal to an instance of named <#std-iscman-named> for a zone configured with dnssec-policy in manual mode, telling it to
continue with the operations that had previously been blocked but logged. This gives the human operator a chance to review the log messages, under‐
stand what will happen next and then, using rndc dnssec -step, to inform named <#std-iscman-named> to proceed to the next stage.
rndc dnssec -rollover allows you to schedule key rollover for a specific key (overriding the original key lifetime).
rndc dnssec -checkds informs named <#std-iscman-named> that the DS for a specified zone's key-signing key has been confirmed to be published in, or
withdrawn from, the parent zone. This is required in order to complete a KSK rollover. The -key id and -alg algorithm arguments can be used to spec‐
ify a particular KSK, if necessary; if there is only one key acting as a KSK for the zone, these arguments can be omitted. The time of publication or
withdrawal for the DS is set to the current time by default, but can be overridden to a specific time with the argument -when time, where time is ex‐
pressed in YYYYMMDDHHMMSS notation.
dnstap (-reopen | -roll [number])
This command closes and re-opens DNSTAP output files.
rndc dnstap -reopen allows the output file to be renamed externally, so that named <#std-iscman-named> can truncate and re-open it.
rndc dnstap -roll causes the output file to be rolled automatically, similar to log files. The most recent output file has ".0" appended to its name;
the previous most recent output file is moved to ".1", and so on. If number is specified, then the number of backup log files is limited to that num‐
ber.
dumpdb [-all | -cache | -zones | -adb | -bad | -expired | -fail] [view ...]
This command dumps 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.
(See the dump-file option in the BIND 9 Administrator Reference Manual.)
fetchlimit [view]
This command dumps a list of servers that are currently being rate-limited as a result of fetches-per-server settings, and a list of domain names that
are currently being rate-limited as a result of fetches-per-zone settings.
flush This command flushes the server's cache.
flushname name [view]
This command flushes the given name from the view's DNS cache and, if applicable, from the view's nameserver address database, bad server cache, and
SERVFAIL cache.
flushtree name [view]
This command flushes the given name, and all of its subdomains, from the view's DNS cache, address database, bad server cache, and SERVFAIL cache.
freeze [zone [class [view]]]
This command suspends 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, and causes changes in the journal file to be synced into the master file. All dynamic update attempts are refused
while the zone is frozen.
See also rndc thaw.
halt [-p]
This command stops the server immediately. Recent changes made through dynamic update or IXFR are not saved to the master files, but are rolled for‐
ward from the journal files when the server is restarted. If -p is specified, named <#std-iscman-named>'s process ID is returned. This allows an ex‐
ternal process to determine when named <#std-iscman-named> has completed halting.
See also rndc stop.
skr -import file zone [class [view]]
This command allows you to import a SKR file for the specified zone, to support offline KSK signing.
loadkeys [zone [class [view]]]
This command fetches all DNSSEC keys for the given zone from the key directory. If they are within their publication period, they are merged 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 zone be configured with a dnssec-policy, and also requires the zone to be configured to allow dynamic DNS. (See "Dy‐
namic Update Policies" in the Administrator Reference Manual for more details.)
managed-keys (status | refresh | sync | destroy) [class [view]]
This command inspects and controls the "managed-keys" database which handles RFC 5011 <https://datatracker.ietf.org/doc/html/rfc5011.html> DNSSEC
trust anchor maintenance. If a view is specified, these commands are applied to that view; otherwise, they are applied to all views.
• When run with the status keyword, this prints the current status of the managed-keys database.
• When run with the refresh keyword, this forces an immediate refresh query to be sent for all the managed keys, updating the managed-keys database if
any new keys are found, without waiting the normal refresh interval.
• When run with the sync keyword, this forces an immediate dump of the managed-keys database to disk (in the file managed-keys.bind or (view‐
name.mkeys). This synchronizes the database with its journal file, so that the database's current contents can be inspected visually.
• When run with the destroy keyword, the managed-keys database is shut down and deleted, and all key maintenance is terminated. This command should
be used only with extreme caution.
Existing keys that are already trusted are not deleted from memory; DNSSEC validation can continue after this command is used. However, key mainte‐
nance operations cease until named <#std-iscman-named> is restarted or reconfigured, and all existing key maintenance states are deleted.
Running rndc reconfig or restarting named <#std-iscman-named> immediately after this command causes key maintenance to be reinitialized from
scratch, just as if the server were being started for the first time. This is primarily intended for testing, but it may also be used, for example,
to jumpstart the acquisition of new keys in the event of a trust anchor rollover, or as a brute-force repair for key maintenance problems.
memprof [(on | off | dump)]
This command controls memory profiling. To have any effect, named <#std-iscman-named> must be built with jemalloc, the library have profiling support
enabled and run with the prof:true allocator configuration. (either via MALLOC_CONF or /etc/malloc.conf)
The prof_active:false option is recommended to ensure the profiling overhead does not affect named <#std-iscman-named> when not needed.
The on and off options will start and stop the jemalloc memory profiling respectively. When run with the dump option, named <#std-iscman-named> will
dump the profile to the working directory. The name will be chosen automatically by jemalloc.
modzone zone [class [view]] configuration
This command modifies the configuration of a zone while the server is running. This command requires the allow-new-zones option to be set to yes. As
with addzone, the configuration string specified on the command line is the zone configuration text that would ordinarily be placed in named.conf <#
std-iscman-named.conf>.
If the zone was originally added via rndc addzone, the configuration changes are recorded permanently and are still in effect after the server is
restarted or reconfigured. However, if it was originally configured in named.conf <#std-iscman-named.conf>, then that original configuration remains
in place; when the server is restarted or reconfigured, the zone reverts to its original configuration. To make the changes permanent, it must also be
modified in named.conf <#std-iscman-named.conf>.
See also rndc addzone and rndc delzone.
notify zone [class [view]]
This command resends NOTIFY messages for the zone.
notrace
This command sets the server's debugging level to 0.
See also rndc trace.
nta [(-class class | -dump | -force | -remove | -lifetime duration)] domain [view]
This command sets a DNSSEC negative trust anchor (NTA) for domain, with a lifetime of duration. The default lifetime is configured in named.conf <#
std-iscman-named.conf> via the nta-lifetime option, and defaults to one hour. The lifetime cannot exceed one week.
A negative trust anchor selectively disables DNSSEC validation for zones that are known to be failing because of misconfiguration rather than an at‐
tack. When data to be validated is at or below an active NTA (and above any other configured trust anchors), named <#std-iscman-named> aborts the
DNSSEC validation process and treats the data as insecure rather than bogus. This continues until the NTA's lifetime has elapsed.
NTAs persist across restarts of the named <#std-iscman-named> server. The NTAs for a view are saved in a file called name.nta, where name is the name
of the view; if it contains characters that are incompatible with use as a file name, a cryptographic hash is generated from the name of the view.
An existing NTA can be removed by using the -remove option.
An NTA's lifetime can be specified with the -lifetime option. TTL-style suffixes can be used to specify the lifetime in seconds, minutes, or hours.
If the specified NTA already exists, its lifetime is updated to the new value. Setting lifetime to zero is equivalent to -remove.
If -dump is used, any other arguments are ignored and a list of existing NTAs is printed. Note that this may include NTAs that are expired but have
not yet been cleaned up.
Normally, named <#std-iscman-named> periodically tests to see whether data below an NTA can now be validated (see the nta-recheck option in the Admin‐
istrator Reference Manual for details). If data can be validated, then the NTA is regarded as no longer necessary and is allowed to expire early. The
-force parameter overrides this behavior and forces an NTA to persist for its entire lifetime, regardless of whether data could be validated if the
NTA were not present.
The view class can be specified with -class. The default is class IN, which is the only class for which DNSSEC is currently supported.
All of these options can be shortened, i.e., to -l, -r, -d, -f, and -c.
Unrecognized options are treated as errors. To refer to a domain or view name that begins with a hyphen, use a double-hyphen (--) on the command line
to indicate the end of options.
querylog [(on | off)]
This command enables or disables 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 <#std-iscman-named
.conf>, or by specifying querylog yes; in the options section of named.conf <#std-iscman-named.conf>.
reconfig
This command reloads the configuration file and loads new zones, but does not reload existing zone files even if they have changed. This is faster
than a full rndc reload when there is a large number of zones, because it avoids the need to examine the modification times of the zone files.
recursing
This command dumps the list of queries named <#std-iscman-named> is currently recursing on, and the list of domains to which iterative queries are
currently being sent.
The first list includes all unique clients that are waiting for recursion to complete, including the query that is awaiting a response and the time‐
stamp (seconds since the Unix epoch) of when named started processing this client query.
The second list comprises of domains for which there are active (or recently active) fetches in progress. It reports the number of active fetches for
each domain and the number of queries that have been passed (allowed) or dropped (spilled) as a result of the fetches-per-zone limit. (Note: these
counters are not cumulative over time; whenever the number of active fetches for a domain drops to zero, the counter for that domain is deleted, and
the next time a fetch is sent to that domain, it is recreated with the counters set to zero).
refresh zone [class [view]]
This command schedules zone maintenance for the given zone.
reload This command reloads the configuration file and zones.
zone [class [view]]
If a zone is specified, this command reloads only the given zone. If no zone is specified, the reloading happens asynchronously.
reset-stats <counter-name ...>
This command resets the requested statistics counters.
At least one counter name must be provided. Currently the following counters are supported: recursive-high-water, tcp-high-water.
responselog [on | off]
This command enables or disables response logging. For backward compatibility, this command can also be used without an argument to toggle response
logging on and off.
Unlike query logging, response logging cannot be enabled by explicitly directing the responses category to a channel in the logging section of
named.conf <#std-iscman-named.conf>, but it can still be enabled by specifying responselog yes; in the options section of named.conf <#
std-iscman-named.conf>.
retransfer [-force] zone [class [view]]
This command retransfers the given secondary zone from the primary server.
If the zone is configured to use inline-signing, the signed version of the zone is discarded; after the retransfer of the unsigned version is com‐
plete, the signed version is regenerated with new signatures. With the optional -force argument provided if there is an ongoing zone transfer it will
be aborted before a new zone transfer is scheduled.
scan This command scans the list of available network interfaces for changes, without performing a full rndc reconfig or waiting for the interface-interval
timer.
secroots [-] [view ...]
This command dumps the security roots (i.e., trust anchors configured via trust-anchors, or the managed-keys or trusted-keys statements [both depre‐
cated], or dnssec-validation auto) and negative trust anchors for the specified views. If no view is specified, all views are dumped. Security roots
indicate whether they are configured as trusted keys, managed keys, or initializing managed keys (managed keys that have not yet been updated by a
successful key refresh query).
If the first argument is -, then the output is returned via the rndc response channel and printed to the standard output. Otherwise, it is written to
the secroots dump file, which defaults to named.secroots, but can be overridden via the secroots-file option in named.conf <#std-iscman-named.conf>.
See also rndc managed-keys.
serve-stale (on | off | reset | status) [class [view]]
This command enables, disables, resets, or reports the current status of the serving of stale answers as configured in named.conf <#std-iscman-named
.conf>.
If serving of stale answers is disabled by rndc-serve-stale off, then it remains disabled even if named <#std-iscman-named> is reloaded or reconfig‐
ured. rndc serve-stale reset restores the setting as configured in named.conf <#std-iscman-named.conf>.
rndc serve-stale status reports whether caching and serving of stale answers is currently enabled or disabled. It also reports the values of stale-an‐
swer-ttl and max-stale-ttl.
showzone zone [class [view]]
If the server is configured with allow-new-zones set to yes, then this command prints the configuration of a running zone.
See also rndc addzone, rndc modzone. and rndc delzone.
sign zone [class [view]]
This command fetches 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, they are merged 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 zone be configured with a dnssec-policy, and also requires the zone to be configured to allow dynamic DNS. (See "Dy‐
namic Update Policies" in the Administrator Reference Manual for more details.)
See also rndc loadkeys.
signing [(-list | -clear keyid/algorithm | -clear all | -nsec3param (parameters | none) | -serial value) zone [class [view]]
This command lists, edits, or removes the DNSSEC signing-state records for the specified zone. The status of ongoing DNSSEC operations, such as sign‐
ing 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 is retained.
rndc signing -nsec3param sets the NSEC3 parameters for a zone. This is the only supported mechanism for using NSEC3 with inline-signing zones. Para‐
meters 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 the opt-out bit in
the NSEC3 chain should be set. 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 hexadecimal, a hyphen (-) if no salt is to be used, or the keyword auto, which causes named <#std-iscman-named> to gener‐
ate a random 64-bit salt.
The only recommended configuration is rndc signing -nsec3param 1 0 0 - zone, i.e. no salt, no additional iterations, no opt-out.
Warning:
Do not use extra iterations, salt, or opt-out unless all their implications are fully understood. A higher number of iterations causes interoper‐
ability problems and opens servers to CPU-exhausting DoS attacks.
rndc signing -nsec3param none removes an existing NSEC3 chain and replaces it with NSEC.
rndc signing -serial value sets the serial number of the zone to value. If the value would cause the serial number to go backwards, it is rejected.
The primary use of this parameter is to set the serial number on inline signed zones.
stats This command writes server statistics to the statistics file. (See the statistics-file option in the BIND 9 Administrator Reference Manual.)
status This command displays the 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 no explicit root zone configured.
stop -p
This command stops 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 <#std-iscman-named>'s process ID is returned. This allows an external process to determine when named <#
std-iscman-named> has completed stopping.
See also rndc halt.
sync -clean [zone [class [view]]]
This command syncs 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.
tcp-timeouts [initial idle keepalive advertised]
When called without arguments, this command displays the current values of the tcp-initial-timeout, tcp-idle-timeout, tcp-keepalive-timeout, and
tcp-advertised-timeout options. When called with arguments, these values are updated. This allows an administrator to make rapid adjustments when un‐
der a denial-of-service (DoS) attack. See the descriptions of these options in the BIND 9 Administrator Reference Manual for details of their use.
thaw [zone [class [view]]]
This command enables 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 are no longer refused. If the
zone has changed and the ixfr-from-differences option is in use, the journal file is updated to reflect changes in the zone. Otherwise, if the zone
has changed, any existing journal file is removed. If no zone is specified, the reloading happens asynchronously.
See also rndc freeze.
trace [level]
If no level is specified, this command increments the server's debugging level by one.
level If specified, this command sets the server's debugging level to the provided value.
See also rndc notrace.
validation (on | off | status) [view ...]
This command enables, disables, or checks the current status of DNSSEC validation. By default, validation is enabled.
The cache is flushed when validation is turned on or off to avoid using data that might differ between states.
zonestatus zone [class [view]]
This command displays the current status of the given zone, including the master file name and any include files from which it was loaded, when it was
most recently loaded, the current serial number, the number of nodes, whether the zone supports dynamic updates, whether the zone is DNSSEC signed,
whether it uses automatic DNSSEC key management or inline signing, and the scheduled refresh or expiry times for the zone.
See also rndc showzone.
rndc commands that specify zone names, such as reload retransfer, or zonestatus, can be ambiguous when applied to zones of type redirect. Redirect zones are
This command enables 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 are no longer refused. If the
zone has changed and the ixfr-from-differences option is in use, the journal file is updated to reflect changes in the zone. Otherwise, if the zone
has changed, any existing journal file is removed. If no zone is specified, the reloading happens asynchronously.
See also rndc freeze.
trace [level]
If no level is specified, this command increments the server's debugging level by one.
level If specified, this command sets the server's debugging level to the provided value.
See also rndc notrace.
validation (on | off | status) [view ...]
This command enables, disables, or checks the current status of DNSSEC validation. By default, validation is enabled.
The cache is flushed when validation is turned on or off to avoid using data that might differ between states.
zonestatus zone [class [view]]
This command displays the current status of the given zone, including the master file name and any include files from which it was loaded, when it was
most recently loaded, the current serial number, the number of nodes, whether the zone supports dynamic updates, whether the zone is DNSSEC signed,
whether it uses automatic DNSSEC key management or inline signing, and the scheduled refresh or expiry times for the zone.
See also rndc showzone.
rndc commands that specify zone names, such as reload retransfer, or zonestatus, can be ambiguous when applied to zones of type redirect. Redirect zones are
always called ., and can be confused with zones of type hint or with secondary copies of the root zone. To specify a redirect zone, use the special zone name
-redirect, without a trailing period. (With a trailing period, this would specify a zone called "-redirect".)
LIMITATIONS
There is currently no way to provide the shared secret for a server_key without using the configuration file.
Several error messages could be clearer.
SEE ALSO
rndc.conf(5) <#std-iscman-rndc.conf>, rndc-confgen(8) <#std-iscman-rndc-confgen>, named(8) <#std-iscman-named>, named.conf(5) <#std-iscman-named.conf>, BIND
9 Administrator Reference Manual.
Author
Internet Systems Consortium
Copyright
2025, Internet Systems Consortium
9.20.17 2025-12-17 RNDC(8)
Die Kommunikation zwischen der UserInterface rndc und dem DNS-Daemon erfolgt nur noch über eine digital signierten Zugangskanal, der auf einem entsprechenden symmetrischen Schlüssel basiert. Dieses zugehörige Schlüsselmaterial muss direkt in einer entsprechenden Konfigurationsdateien hinterlegt werden und so dem Client rndc und dem Server bind bekannt gegeben werden.
Name Server Control Utility rndc Key Generations Tool rndc-confgen
Das zuvor genannte Schlüsselmaterial wird mit Hilfe des rndc key generation toolrndc-confgen aus dem Paket bind erzeugt. Die Optionen dieses User Interface finden am einfachsten in der zugehörigen manpage.
RNDC-CONFGEN(8) BIND 9 RNDC-CONFGEN(8)
NAME
rndc-confgen - rndc key generation tool
SYNOPSIS
rndc-confgen [-a] [-A algorithm] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-s address] [-t chrootdir] [-u user]
DESCRIPTION
rndc-confgen generates configuration files for rndc <#std-iscman-rndc>. It can be used as a convenient alternative to writing the rndc.conf <#std-iscman-rndc
.conf> file and the corresponding controls and key statements in named.conf <#std-iscman-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 <#std-iscman-rndc.conf> file and a controls statement altogether.
OPTIONS
-a This option sets automatic rndc <#std-iscman-rndc> configuration, which creates a file /etc/rndc.key that is read by both rndc <#std-iscman-rndc> and
named <#std-iscman-named> on startup. The rndc.key file defines a default command channel and authentication key allowing rndc <#std-iscman-rndc> to
communicate with named <#std-iscman-named> on the local host with no further configuration.
If a more elaborate configuration than that generated by rndc-confgen -a is required, for example if rndc is to be used remotely, run rndc-confgen
without the -a option and set up rndc.conf <#std-iscman-rndc.conf> and named.conf <#std-iscman-named.conf> as directed.
-A algorithm
This option specifies the algorithm to use for the TSIG key. Available choices are: hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, and
hmac-sha512. The default is hmac-sha256.
-b keysize
This option specifies the size of the authentication key in bits. The size must be between 1 and 512 bits; the default is the hash size.
-c keyfile
This option is used with the -a option to specify an alternate location for rndc.key.
-h This option prints a short summary of the options and arguments to rndc-confgen.
-k keyname
This option specifies the key name of the rndc <#std-iscman-rndc> authentication key. This must be a valid domain name. The default is rndc-key.
-p port
This option specifies the command channel port where named <#std-iscman-named> listens for connections from rndc <#std-iscman-rndc>. The default is
953.
-q This option prevets printing the written path in automatic configuration mode.
-s address
This option specifies the IP address where named <#std-iscman-named> listens for command-channel connections from rndc <#std-iscman-rndc>. The default
is the loopback address 127.0.0.1.
This option is used with the -a option to specify an alternate location for rndc.key.
-h This option prints a short summary of the options and arguments to rndc-confgen.
-k keyname
This option specifies the key name of the rndc <#std-iscman-rndc> authentication key. This must be a valid domain name. The default is rndc-key.
-p port
This option specifies the command channel port where named <#std-iscman-named> listens for connections from rndc <#std-iscman-rndc>. The default is
953.
-q This option prevets printing the written path in automatic configuration mode.
-s address
This option specifies the IP address where named <#std-iscman-named> listens for command-channel connections from rndc <#std-iscman-rndc>. The default
is the loopback address 127.0.0.1.
-t chrootdir
This option is used with the -a option to specify a directory where named <#std-iscman-named> runs chrooted. An additional copy of the rndc.key is
written relative to this directory, so that it is found by the chrooted named <#std-iscman-named>.
-u user
This option is used with the -a option to set the owner of the generated rndc.key file. If -t is also specified, only the file in the chroot area has
its owner changed.
EXAMPLES
To allow rndc <#std-iscman-rndc> to be used with no manual configuration, run:
rndc-confgen -a
To print a sample rndc.conf <#std-iscman-rndc.conf> file and the corresponding controls and key statements to be manually inserted into named.conf <#
std-iscman-named.conf>, run:
rndc-confgen
SEE ALSO
rndc(8) <#std-iscman-rndc>, rndc.conf(5) <#std-iscman-rndc.conf>, named(8) <#std-iscman-named>, BIND 9 Administrator Reference Manual.
Author
Internet Systems Consortium
Copyright
2025, Internet Systems Consortium
9.20.17 2025-12-17 RNDC-CONFGEN(8)
Name Server Konfigurationsdatei Syntax Prüftool named-checkconf
Zum Überprüfen der Konfiguration /etc/named.conf die wir später noch erstellen werden, befindet sich in dem ArchLinux-Paket das Hilfsprogramm named-checkconf. Die manpage des Programms liefert eine entsprechende Hilfe und zeigt auch die entsprechenden Optionen auf, mit deren Hilfe umfangreiche Tests durchgeführt werden können.
NAMED-CHECKCONF(1) BIND 9 NAMED-CHECKCONF(1)
NAME
named-checkconf - named configuration file syntax checking tool
SYNOPSIS
named-checkconf [-achjklvz] [-p [-x ]] [-t directory] {filename}
DESCRIPTION
named-checkconf checks the syntax, but not the semantics, of a named <#std-iscman-named> configuration file. The file, along with all files included by it,
is parsed and checked for syntax errors. If no file is specified, /etc/named.conf is read by default.
Note: files that named <#std-iscman-named> reads in separate parser contexts, such as rndc.conf or rndc.key, are not automatically read by named-checkconf.
Configuration errors in these files may cause named <#std-iscman-named> to fail to run, even if named-checkconf was successful. However, named-checkconf can
be run on these files explicitly.
OPTIONS
-a Don't check the dnssec-policy's DNSSEC key algorithms against those supported by the crypto provider. This is useful when checking a named.conf in‐
tended to be run on another machine with possibly a different set of supported DNSSEC key algorithms.
-h This option prints the usage summary and exits.
-j When loading a zonefile, this option instructs named <#std-iscman-named> to read the journal if it exists.
-k Check the dnssec-policy's DNSSEC keys against the key files in the key-directory. This is useful when checking a named.conf to ensure a DNSSEC policy
matches the existing keys.
-l This option lists all the configured zones. Each line of output contains the zone name, class (e.g. IN), view, and type (e.g. primary or secondary).
-c This option specifies that only the "core" configuration should be checked. This suppresses the loading of plugin modules, and causes all parameters
to plugin statements to be ignored.
-i This option ignores warnings on deprecated options.
-p This option prints out the named.conf <#std-iscman-named.conf> and included files in canonical form if no errors were detected. See also the -x op‐
tion.
-t directory
This option instructs named <#std-iscman-named> to chroot to directory, so that include directives in the configuration file are processed as if run
by a similarly chrooted named <#std-iscman-named>.
-v This option prints the version of the named-checkconf program and exits.
-x When printing the configuration files in canonical form, this option obscures shared secrets by replacing them with strings of question marks (?).
This allows the contents of named.conf <#std-iscman-named.conf> and related files to be shared - for example, when submitting bug reports - without
compromising private data. This option cannot be used without -p.
-h This option prints the usage summary and exits.
-j When loading a zonefile, this option instructs named <#std-iscman-named> to read the journal if it exists.
-k Check the dnssec-policy's DNSSEC keys against the key files in the key-directory. This is useful when checking a named.conf to ensure a DNSSEC policy
matches the existing keys.
-l This option lists all the configured zones. Each line of output contains the zone name, class (e.g. IN), view, and type (e.g. primary or secondary).
-c This option specifies that only the "core" configuration should be checked. This suppresses the loading of plugin modules, and causes all parameters
to plugin statements to be ignored.
-i This option ignores warnings on deprecated options.
-p This option prints out the named.conf <#std-iscman-named.conf> and included files in canonical form if no errors were detected. See also the -x op‐
tion.
-t directory
This option instructs named <#std-iscman-named> to chroot to directory, so that include directives in the configuration file are processed as if run
by a similarly chrooted named <#std-iscman-named>.
-v This option prints the version of the named-checkconf program and exits.
-x When printing the configuration files in canonical form, this option obscures shared secrets by replacing them with strings of question marks (?).
This allows the contents of named.conf <#std-iscman-named.conf> and related files to be shared - for example, when submitting bug reports - without
compromising private data. This option cannot be used without -p.
-z This option performs a test load of all zones of type primary found in named.conf <#std-iscman-named.conf>.
filename
This indicates the name of the configuration file to be checked. If not specified, it defaults to /etc/named.conf.
RETURN VALUES
named-checkconf returns an exit status of 1 if errors were detected and 0 otherwise.
SEE ALSO
named(8) <#std-iscman-named>, named-checkzone(8) <#std-iscman-named-checkzone>, BIND 9 Administrator Reference Manual.
Author
Internet Systems Consortium
Copyright
2025, Internet Systems Consortium
9.20.17 2025-12-17 NAMED-CHECKCONF(1)
DNSSEC Tool zum Generieren der Schlüssel dnssec-keygen
Wollen wir später DNSSEC zum Einsatz bringen, benötigen wir entsprechendes Schlüsselmaterial. Zur Generierung dieser Schlüssel verwenden wir das Programm dnssec-keygen. Die manpage des Programms liefert eine entsprechende Hilfe und zeigt auch die entsprechenden Optionen auf, die bei der Erstellung des Schlüsselmaterials verwendet werden kann.
DNSSEC-KEYGEN(1) BIND 9 DNSSEC-KEYGEN(1)
NAME
dnssec-keygen - DNSSEC key generation tool
SYNOPSIS
dnssec-keygen [-3] [-A date/offset] [-a algorithm] [-b keysize] [-C] [-c class] [-D date/offset] [-d bits] [-D sync date/offset] [-E engine] [-f flag] [-F]
[-G] [-h] [-I date/offset] [-i interval] [-K directory] [-k policy] [-L ttl] [-l file] [-n nametype] [-M tag_min:tag_max] [-P date/offset] [-P sync date/off‐
set] [-p protocol] [-q] [-R date/offset] [-S key] [-s strength] [-T rrtype] [-t type] [-V] [-v level] {name}
DESCRIPTION
dnssec-keygen generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 <https://datatracker.ietf.org/doc/html/rfc2535.html> and RFC 4034 <https://
datatracker.ietf.org/doc/html/rfc4034.html>.
The name of the key is specified on the command line. For DNSSEC keys, this must match the name of the zone for which the key is being generated.
OPTIONS
-3 This option uses an NSEC3-capable algorithm to generate a DNSSEC key. If this option is used with an algorithm that has both NSEC and NSEC3 versions,
then the NSEC3 version is selected; for example, dnssec-keygen -3 -a RSASHA1 specifies the NSEC3RSASHA1 (deprecated) algorithm.
-a algorithm
This option selects the cryptographic algorithm. For DNSSEC keys, the value of algorithm must be one of RSASHA1 (deprecated), NSEC3RSASHA1 (depre‐
cated), RSASHA256, RSASHA512, ECDSAP256SHA256, ECDSAP384SHA384, ED25519, or ED448.
These values are case-insensitive. In some cases, abbreviations are supported, such as ECDSA256 for ECDSAP256SHA256 and ECDSA384 for ECDSAP384SHA384.
If RSASHA1 (deprecated) is specified along with the -3 option, NSEC3RSASHA1 (deprecated) is used instead.
This parameter must be specified except when using the -S option, which copies the algorithm from the predecessor key.
In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen <#
std-iscman-tsig-keygen> to generate TSIG keys.
-b keysize
This option specifies the number of bits in the key. The choice of key size depends on the algorithm used: RSA keys must be between 1024 and 4096
bits; Diffie-Hellman keys must be between 128 and 4096 bits. Elliptic curve algorithms do not need this parameter.
If the key size is not specified, some algorithms have pre-defined defaults. For example, RSA keys for use as DNSSEC zone-signing keys have a default
size of 1024 bits; RSA keys for use as key-signing keys (KSKs, generated with -f KSK) default to 2048 bits.
-C This option enables compatibility mode, which generates an old-style key, without any timing metadata. By default, dnssec-keygen includes the key's
creation date in the metadata stored with the private key; other dates may be set there as well, including publication date, activation date, etc.
Keys that include this data may be incompatible with older versions of BIND; the -C option suppresses them.
-c class
This option indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used.
-d bits
This option specifies the key size in bits. For the algorithms RSASHA1, NSEC3RSASA1, RSASHA256, and RSASHA512 the key size must be between 1024 and
4096 bits; DH size is between 128 and 4096 bits. This option is ignored for algorithms ECDSAP256SHA256, ECDSAP384SHA384, ED25519, and ED448.
-E engine
This option specifies the cryptographic hardware to use, when applicable.
When BIND 9 is built with OpenSSL, this needs to be set to the OpenSSL engine identifier that drives the cryptographic accelerator or hardware service
module (usually pkcs11).
-f flag
This option sets the specified flag in the flag field of the KEY/DNSKEY record. The only recognized flags are ZSK (Zone-Signing Key), KSK (Key-Sign‐
ing Key) and REVOKE.
Note that ZSK is not a physical flag in the DNSKEY record, it is merely used to explicitly tell that you want to create a ZSK. Setting -f in conjunc‐
tion with -k will result in generating keys that only match the given role set with this option.
-F This options turns on FIPS (US Federal Information Processing Standards) mode if the underlying crytographic library supports running in FIPS mode.
-G This option generates a key, but does not publish it or sign with it. This option is incompatible with -P and -A.
-h This option prints a short summary of the options and arguments to dnssec-keygen.
-K directory
This option sets the directory in which the key files are to be written.
-k policy
This option creates keys for a specific dnssec-policy. If a policy uses multiple keys, dnssec-keygen generates multiple keys. This also creates a
".state" file to keep track of the key state.
This option creates keys according to the dnssec-policy configuration, hence it cannot be used at the same time as many of the other options that
dnssec-keygen provides.
-L ttl This option sets the default TTL to use for this key when it is converted into a DNSKEY RR. This is the TTL used when the key is imported into a zone,
unless there was already a DNSKEY RRset in place, in which case the existing TTL takes precedence. If this value is not set and there is no existing
DNSKEY RRset, the TTL defaults to the SOA TTL. Setting the default TTL to 0 or none is the same as leaving it unset.
-l file
This option provides a configuration file that contains a dnssec-policy statement (matching the policy set with -k).
-M tag_min:tag_max
This option sets the range of acceptable key tag values that dnssec-keygen will produce. If the key tag of the new key or the key tag of the revoked
version of the new key is outside this range, the new key will be rejected and another new key will be generated. This is designed to be used when
generating keys in a multi-signer scenario, where each operator is given a range of key tags to prevent collisions among different operators. The
valid values for tag_min and tag_max are [0..65535]. The default allows all key tag values to be produced. This option is ignored when -k policy is
specified.
-n nametype
This option specifies the owner type of the key. The value of nametype must either be ZONE (for a DNSSEC zone key (KEY/DNSKEY)), HOST or ENTITY (for a
key associated with a host (KEY)), USER (for a key associated with a user (KEY)), or OTHER (DNSKEY). These values are case-insensitive. The default is
ZONE for DNSKEY generation.
-p protocol
This option sets the protocol value for the generated key, for use with -T KEY. The protocol is a number between 0 and 255. The default is 3 (DNSSEC).
Other possible values for this argument are listed in RFC 2535 <https://datatracker.ietf.org/doc/html/rfc2535.html> and its successors.
-q This option sets quiet mode, which suppresses unnecessary output, including progress indication. Without this option, when dnssec-keygen is run inter‐
actively to generate an RSA or DSA key pair, it prints a string of symbols to stderr indicating the progress of the key generation. A . indicates that
a random number has been found which passed an initial sieve test; + means a number has passed a single round of the Miller-Rabin primality test; and
a space ( ) means that the number has passed all the tests and is a satisfactory key.
-S key This option creates a new key which is an explicit successor to an existing key. The name, algorithm, size, and type of the key are set to match the
existing key. The activation date of the new key is set to the inactivation date of the existing one. The publication date is set to the activation
date minus the prepublication interval, which defaults to 30 days.
-s strength
This option specifies the strength value of the key. The strength is a number between 0 and 15, and currently has no defined purpose in DNSSEC.
-T rrtype
This option specifies the resource record type to use for the key. rrtype must be either DNSKEY or KEY. The default is DNSKEY when using a DNSSEC al‐
gorithm, but it can be overridden to KEY for use with SIG(0).
-t type
This option indicates the type of the key for use with -T KEY. type must be one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default is AUTHCONF.
AUTH refers to the ability to authenticate data, and CONF to the ability to encrypt data.
-V This option prints version information.
-v level
This option sets the debugging level.
TIMING OPTIONS
Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS (which is the format used inside key files), or 'Day Mon DD HH:MM:SS YYYY' (as printed by
dnssec-settime -p), or UNIX epoch time (as printed by dnssec-settime -up), or the literal now.
The argument can be followed by + or - and an offset from the given time. The literal now can be omitted before an offset. The offset can be followed by one
of the suffixes y, mo, w, d, h, or mi, so that it is computed in years (defined as 365 24-hour days, ignoring leap years), months (defined as 30 24-hour
days), weeks, days, hours, or minutes, respectively. Without a suffix, the offset is computed in seconds.
To unset a date, use none, never, or unset.
-P date/offset
This option sets the date on which a key is to be published to the zone. After that date, the key is included in the zone but is not used to sign it.
If not set, and if the -G option has not been used, the default is the current date.
sync date/offset
This option sets the date on which CDS and CDNSKEY records that match this key are to be published to the zone.
-A date/offset
This option sets the date on which the key is to be activated. After that date, the key is included in the zone and used to sign it. If not set, and
if the -G option has not been used, the default is the current date. If set, and -P is not set, the publication date is set to the activation date mi‐
nus the prepublication interval.
-R date/offset
This option sets the date on which the key is to be revoked. After that date, the key is flagged as revoked. It is included in the zone and is used to
sign it.
-I date/offset
This option sets the date on which the key is to be retired. After that date, the key is still included in the zone, but it is not used to sign it.
-D date/offset
This option sets the date on which the key is to be deleted. After that date, the key is no longer included in the zone. (However, it may remain in
the key repository.)
sync date/offset
This option sets the date on which the CDS and CDNSKEY records that match this key are to be deleted.
-i interval
This option sets the prepublication interval for a key. If set, then the publication and activation dates must be separated by at least this much
time. If the activation date is specified but the publication date is not, the publication date defaults to this much time before the activation date;
conversely, if the publication date is specified but not the activation date, activation is set to this much time after publication.
If the key is being created as an explicit successor to another key, then the default prepublication interval is 30 days; otherwise it is zero.
As with date offsets, if the argument is followed by one of the suffixes y, mo, w, d, h, or mi, the interval is measured in years, months, weeks,
days, hours, or minutes, respectively. Without a suffix, the interval is measured in seconds.
GENERATED KEYS
When dnssec-keygen completes successfully, it prints a string of the form Knnnn.+aaa+iiiii to the standard output. This is an identification string for the
key it has generated.
• nnnn is the key name.
• aaa is the numeric representation of the algorithm.
• iiiii is the key identifier (or footprint).
dnssec-keygen creates two files, with names based on the printed string. Knnnn.+aaa+iiiii.key contains the public key, and Knnnn.+aaa+iiiii.private contains
days, hours, or minutes, respectively. Without a suffix, the interval is measured in seconds.
GENERATED KEYS
When dnssec-keygen completes successfully, it prints a string of the form Knnnn.+aaa+iiiii to the standard output. This is an identification string for the
key it has generated.
• nnnn is the key name.
• aaa is the numeric representation of the algorithm.
• iiiii is the key identifier (or footprint).
dnssec-keygen creates two files, with names based on the printed string. Knnnn.+aaa+iiiii.key contains the public key, and Knnnn.+aaa+iiiii.private contains
the private key.
The .key file contains a DNSKEY or KEY record. When a zone is being signed by named <#std-iscman-named> or dnssec-signzone -S <#cmdoption-dnssec-signzone-S>,
DNSKEY records are included automatically. In other cases, the .key file can be inserted into a zone file manually or with an $INCLUDE statement.
The .private file contains algorithm-specific fields. For obvious security reasons, this file does not have general read permission.
EXAMPLE
To generate an ECDSAP256SHA256 zone-signing key for the zone example.com, issue the command:
dnssec-keygen -a ECDSAP256SHA256 example.com
The command prints a string of the form:
Kexample.com.+013+26160
In this example, dnssec-keygen creates the files Kexample.com.+013+26160.key and Kexample.com.+013+26160.private.
To generate a matching key-signing key, issue the command:
dnssec-keygen -a ECDSAP256SHA256 -f KSK example.com
SEE ALSO
dnssec-signzone(8) <#std-iscman-dnssec-signzone>, BIND 9 Administrator Reference Manual, RFC 2539 <https://datatracker.ietf.org/doc/html/rfc2539.html>, RFC
2845 <https://datatracker.ietf.org/doc/html/rfc2845.html>, RFC 4034 <https://datatracker.ietf.org/doc/html/rfc4034.html>.
Author
Internet Systems Consortium
Copyright
2025, Internet Systems Consortium
9.20.17 2025-12-17 DNSSEC-KEYGEN(1)
nsupdate - Tool für den dynamischen Update von Zonen-Dateien
Das Programm nsupdate wird verwendet, um Dynamic DNS Update-Anfragen, wie in RFC 2136 definiert, an einen Namenserver zu senden. Dadurch können Ressourceneinträge zu einer Zone hinzugefügt oder daraus entfernt werden, ohne die Zonendatei manuell zu bearbeiten. Die manpage des Programms liefert eine entsprechende Hilfe und zeigt auch die entsprechenden Optionen auf, die bei der Verwaltung dynamischer Zonen zum Tragen kommen.
NSUPDATE(1) BIND 9 NSUPDATE(1)
NAME
nsupdate - dynamic DNS update utility
SYNOPSIS
nsupdate [-d] [-D] [-i] [-L level] [ [-g] | [-o] | [-l] | [-y [hmac:]keyname:secret] | [-k keyfile] ] [ [-S] [-K tlskeyfile] [-E tlscertfile] [-A tlscafile]
[-H tlshostname] [-O] ] [-t timeout] [-u udptimeout] [-r udpretries] [-v] [-T] [-P] [-V] [ [-4] | [-6] ] [filename]
DESCRIPTION
nsupdate is used to submit Dynamic DNS Update requests, as defined in RFC 2136 <https://datatracker.ietf.org/doc/html/rfc2136.html>, to a name server. This
allows resource records to be added or removed from a zone without manually editing the zone file. A single update request can contain requests to add or re‐
move more than one resource record.
Zones that are under dynamic control via nsupdate or a DHCP server should not be edited by hand. Manual edits could conflict with dynamic updates and cause
data to be lost.
The resource records that are dynamically added or removed with nsupdate must be in the same zone. Requests are sent to the zone's primary server, which is
identified by the MNAME field of the zone's SOA record.
Transaction signatures can be used to authenticate the Dynamic DNS updates. These use the TSIG resource record type described in RFC 2845 <https://
datatracker.ietf.org/doc/html/rfc2845.html>, the SIG(0) record described in RFC 2535 <https://datatracker.ietf.org/doc/html/rfc2535.html> and RFC 2931
<https://datatracker.ietf.org/doc/html/rfc2931.html>, or GSS-TSIG as described in RFC 3645 <https://datatracker.ietf.org/doc/html/rfc3645.html>.
TSIG relies on a shared secret that should only be known to nsupdate and the name server. For instance, suitable key and server statements are added to
/etc/named.conf so that the name server can associate the appropriate secret key and algorithm with the IP address of the client application that is using
TSIG authentication. ddns-confgen <#std-iscman-ddns-confgen> can generate suitable configuration fragments. nsupdate uses the -y or -k options to provide the
TSIG shared secret; these options are mutually exclusive.
SIG(0) uses public key cryptography. To use a SIG(0) key, the public key must be stored in a KEY record in a zone served by the name server.
GSS-TSIG uses Kerberos credentials. Standard GSS-TSIG mode is switched on with the -g flag. A non-standards-compliant variant of GSS-TSIG used by Windows
2000 can be switched on with the -o flag.
OPTIONS
-4 This option sets use of IPv4 only.
-6 This option sets use of IPv6 only.
-A tlscafile
This option specifies the file of the certificate authorities (CA) certificates (in PEM format) in order to verify the remote server TLS certificate
when using DNS-over-TLS (DoT), to achieve Strict or Mutual TLS. When used, it will override the certificates from the global certificates store, which
are otherwise used by default when -S is enabled. This option can not be used in conjuction with -O, and it implies -S.
-C Overrides the default resolv.conf file. This is only intended for testing.
-d This option sets debug mode, which provides tracing information about the update requests that are made and the replies received from the name server.
-D This option sets extra debug mode.
-E tlscertfile
This option sets the certificate(s) file for authentication for the DNS-over-TLS (DoT) transport to the remote server. The certificate chain file is
expected to be in PEM format. This option implies -S, and can only be used with -K.
-g This option enables standard GSS-TSIG mode.
-H tlshostname
This option makes nsupdate use the provided hostname during remote server TLS certificate verification. Otherwise, the DNS server name is used. This
option implies -S.
-i This option forces interactive mode, even when standard input is not a terminal.
-k keyfile
This option indicates the file containing the TSIG authentication key. Keyfiles may be in two formats: a single file containing a named.conf <#
std-iscman-named.conf>-format key statement, which may be generated automatically by ddns-confgen <#std-iscman-ddns-confgen>; or a pair of files whose
names are of the format K{name}.+157.+{random}.key and K{name}.+157.+{random}.private, which can be generated by dnssec-keygen <#
std-iscman-dnssec-keygen>. The -k option can also be used to specify a SIG(0) key used to authenticate Dynamic DNS update requests. In this case, the
key specified is not an HMAC-MD5 key.
-K tlskeyfile
This option sets the key file for authenticated encryption for the DNS-over-TLS (DoT) transport with the remote server. The private key file is ex‐
pected to be in PEM format. This option implies -S, and can only be used with -E.
-l This option sets local-host only mode, which sets the server address to localhost (disabling the server so that the server address cannot be overrid‐
den). Connections to the local server use a TSIG key found in /var/run/session.key, which is automatically generated by named <#std-iscman-named> if
any local primary zone has set update-policy to local. The location of this key file can be overridden with the -k option.
-L level
This option sets the logging debug level. If zero, logging is disabled.
-o This option is deprecated. Previously, it enabled a non-standards-compliant variant of GSS-TSIG that was used by Windows 2000. Since that OS is now
long past its end of life, this option is now treated as a synonym for -g.
-O This option enables Opportunistic TLS. When used, the remote peer's TLS certificate will not be verified. This option should be used for debugging
purposes only, and it is not recommended to use it in production. This option can not be used in conjuction with -A, and it implies -S.
-p port
This option sets the port to use for connections to a name server. The default is 53.
-P This option prints the list of private BIND-specific resource record types whose format is understood by nsupdate. See also the -T option.
-r udpretries
This option sets the number of UDP retries. The default is 3. If zero, only one update request is made.
-S This option indicates whether to use DNS-over-TLS (DoT) when querying name servers specified by server servername port syntax in the input file, and
the primary server discovered through a SOA request. When the -K and -E options are used, then the specified TLS client certificate and private key
pair are used for authentication (Mutual TLS). This option implies -v.
-t timeout
This option sets the maximum time an update request can take before it is aborted. The default is 300 seconds. If zero, the timeout is disabled for
TCP mode. For UDP mode, the option -u takes precedence over this option, unless the option -u is set to zero, in which case the interval is computed
from the -t timeout interval and the number of UDP retries. For UDP mode, the timeout can not be disabled, and will be rounded up to 1 second in case
if both -t and -u are set to zero.
-T This option prints the list of IANA standard resource record types whose format is understood by nsupdate. nsupdate exits after the lists are printed.
The -T option can be combined with the -P option.
Other types can be entered using TYPEXXXXX where XXXXX is the decimal value of the type with no leading zeros. The rdata, if present, is parsed using
the UNKNOWN rdata format, (<backslash> <hash> <space> <length> <space> <hexstring>).
-u udptimeout
This option sets the UDP retry interval. The default is 3 seconds. If zero, the interval is computed from the timeout interval and number of UDP re‐
tries.
-v This option specifies that TCP should be used even for small update requests. By default, nsupdate uses UDP to send update requests to the name server
unless they are too large to fit in a UDP request, in which case TCP is used. TCP may be preferable when a batch of update requests is made.
-V This option prints the version number and exits.
-y [hmac:]keyname:secret
This option sets the literal TSIG authentication key. keyname is the name of the key, and secret is the base64 encoded shared secret. hmac is the name
of the key algorithm; valid choices are hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, or hmac-sha512. If hmac is not specified, the de‐
fault is hmac-md5, or if MD5 was disabled, hmac-sha256.
NOTE: Use of the -y option is discouraged because the shared secret is supplied as a command-line argument in clear text. This may be visible in the
output from ps1 or in a history file maintained by the user's shell.
INPUT FORMAT
nsupdate reads input from filename or standard input. Each command is supplied on exactly one line of input. Some commands are for administrative purposes;
others are either update instructions or prerequisite checks on the contents of the zone. These checks set conditions that some name or set of resource
records (RRset) either exists or is absent from the zone. These conditions must be met if the entire update request is to succeed. Updates are rejected if
the tests for the prerequisite conditions fail.
Every update request consists of zero or more prerequisites and zero or more updates. This allows a suitably authenticated update request to proceed if some
specified resource records are either present or missing from the zone. A blank input line (or the send command) causes the accumulated commands to be sent
as one Dynamic DNS update request to the name server.
The command formats and their meanings are as follows:
server servername port
This command sends all dynamic update requests to the name server servername. When no server statement is provided, nsupdate sends updates to the
primary server of the correct zone. The MNAME field of that zone's SOA record identify the primary server for that zone. port is the port number on
servername where the dynamic update requests are sent. If no port number is specified, the default DNS port number of 53 is used.
Note:
This command has no effect when GSS-TSIG is in use.
local address port
This command sends all dynamic update requests using the local address. When no local statement is provided, nsupdate sends updates using an address
and port chosen by the system. port can also be used to force requests to come from a specific port. If no port number is specified, the system as‐
signs one.
zone zonename
This command specifies that all updates are to be made to the zone zonename. If no zone statement is provided, nsupdate attempts to determine the
correct zone to update based on the rest of the input.
class classname
This command specifies the default class. If no class is specified, the default class is IN.
ttl seconds
This command specifies the default time-to-live, in seconds, for records to be added. The value none clears the default TTL.
key hmac:keyname secret
This command specifies that all updates are to be TSIG-signed using the keyname-secret pair. If hmac is specified, it sets the signing algorithm in
use. The default is hmac-md5; if MD5 was disabled, the default is hmac-sha256. The key command overrides any key specified on the command line via -y
or -k.
gsstsig
This command uses GSS-TSIG to sign the updates. This is equivalent to specifying -g on the command line.
oldgsstsig
This command is deprecated and will be removed in a future release. Previously, it caused nsupdate to use the Windows 2000 version of GSS-TSIG to
sign updates. It is now treated as a synonym for gsstsig.
realm [realm_name]
When using GSS-TSIG, this command specifies the use of realm_name rather than the default realm in krb5.conf. If no realm is specified, the saved
realm is cleared.
check-names [boolean]
This command turns on or off check-names processing on records to be added. Check-names has no effect on prerequisites or records to be deleted. By
default check-names processing is on. If check-names processing fails, the record is not added to the UPDATE message.
check-svbc [boolean]
This command turns on or off check-svcb processing on records to be added. Check-svcb has no effect on prerequisites or records to be deleted. By
default check-svcb processing is on. If check-svcb processing fails, the record is not added to the UPDATE message.
lease time [keytime]
Set the EDNS Update Lease (UL) option to value to time and optionally also set the key lease time to keytime in seconds. If time is none the lease
times are cleared.
prereq nxdomain domain-name
This command requires that no resource record of any type exist with the name domain-name.
prereq yxdomain domain-name
This command requires that domain-name exist (as at least one resource record, of any type).
prereq nxrrset domain-name class type
This command requires that no resource record exist of the specified type, class, and domain-name. If class is omitted, IN (Internet) is assumed.
prereq yxrrset domain-name class type
This command requires that a resource record of the specified type, class and domain-name exist. If class is omitted, IN (internet) is assumed.
prereq yxrrset domain-name class type data
With this command, the data from each set of prerequisites of this form sharing a common type, class, and domain-name are combined to form a set of
RRs. This set of RRs must exactly match the set of RRs existing in the zone at the given type, class, and domain-name. The data are written in the
standard text representation of the resource record's RDATA.
update delete domain-name ttl class type data
This command deletes any resource records named domain-name. If type and data are provided, only matching resource records are removed. The Internet
class is assumed if class is not supplied. The ttl is ignored, and is only allowed for compatibility.
update add domain-name ttl class type data
This command adds a new resource record with the specified ttl, class, and data.
show This command displays the current message, containing all of the prerequisites and updates specified since the last send.
send This command sends the current message. This is equivalent to entering a blank line.
answer This command displays the answer.
debug This command turns on debugging.
version
This command prints the version number.
help This command prints a list of commands.
Lines beginning with a semicolon (;) are comments and are ignored.
EXAMPLES
The examples below show how nsupdate can be used to insert and delete resource records from the example.com zone. Notice that the input in each example con‐
tains a trailing blank line, so that a group of commands is sent as one dynamic update request to the primary name server for example.com.
# nsupdate
> update delete oldhost.example.com A
> update add newhost.example.com 86400 A 172.16.1.1
> send
Any A records for oldhost.example.com are deleted, and an A record for newhost.example.com with IP address 172.16.1.1 is added. The newly added record has a
TTL of 1 day (86400 seconds).
# nsupdate
> prereq nxdomain nickname.example.com
> update add nickname.example.com 86400 CNAME somehost.example.com
> send
The prerequisite condition tells the name server to verify that there are no resource records of any type for nickname.example.com. If there are, the update
request fails. If this name does not exist, a CNAME for it is added. This ensures that when the CNAME is added, it cannot conflict with the long-standing
rule in RFC 1034 <https://datatracker.ietf.org/doc/html/rfc1034.html> that a name must not exist as any other record type if it exists as a CNAME. (The rule
has been updated for DNSSEC in RFC 2535 <https://datatracker.ietf.org/doc/html/rfc2535.html> to allow CNAMEs to have RRSIG, DNSKEY, and NSEC records.)
FILES
/etc/resolv.conf
Used to identify the default name server
/var/run/session.key
Sets the default TSIG key for use in local-only mode
K{name}.+157.+{random}.key
Base-64 encoding of the HMAC-MD5 key created by dnssec-keygen <#std-iscman-dnssec-keygen>.
K{name}.+157.+{random}.private
Base-64 encoding of the HMAC-MD5 key created by dnssec-keygen <#std-iscman-dnssec-keygen>.
SEE ALSO
RFC 2136 <https://datatracker.ietf.org/doc/html/rfc2136.html>, RFC 3007 <https://datatracker.ietf.org/doc/html/rfc3007.html>, RFC 2104 <https://datatracker
.ietf.org/doc/html/rfc2104.html>, RFC 2845 <https://datatracker.ietf.org/doc/html/rfc2845.html>, RFC 1034 <https://datatracker.ietf.org/doc/html/rfc1034
.html>, RFC 2535 <https://datatracker.ietf.org/doc/html/rfc2535.html>, RFC 2931 <https://datatracker.ietf.org/doc/html/rfc2931.html>, named(8) <#
std-iscman-named>, dnssec-keygen(8) <#std-iscman-dnssec-keygen>, tsig-keygen(8) <#std-iscman-tsig-keygen>.
BUGS
The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library for its cryptographic operations, and may
change in future releases.
Author
Internet Systems Consortium
Copyright
2025, Internet Systems Consortium
9.20.17 2025-12-17 NSUPDATE(1)
ddns-confgen - Hilfsprogramm zur DDNS Schlüssel Generierung
ddns-confgen ist ein Hilfs-/Dienstprogramm, das Schlüssel für die Verwendung in der TSIG-Signatur generiert. Die resultierenden Schlüssel können beispielsweise verwendet werden, um dynamische DNS-Updates für eine Zone zu sichern, oder für den rndc-Befehlskanal. Die manpage des Programms liefert eine entsprechende Hilfe und zeigt auch die entsprechenden Optionen auf, die bei der Generierung des DDNS-Schlüsselmaterials verwendet werden können.
DDNS-CONFGEN(8) BIND 9 DDNS-CONFGEN(8)
NAME
ddns-confgen - ddns key generation tool
SYNOPSIS
ddns-confgen [-a algorithm] [-h] [-k keyname] [-q] [-s name] [-z zone]
DESCRIPTION
ddns-confgen is an utility that generates keys for use in TSIG signing. The resulting keys can be used, for example, to secure dynamic DNS updates to a
zone, or for the rndc <#std-iscman-rndc> command channel.
The key name can specified using -k parameter and defaults to ddns-key. The generated key is accompanied by configuration text and instructions that can be
used with nsupdate <#std-iscman-nsupdate> and named <#std-iscman-named> when setting up dynamic DNS, including an example update-policy statement. (This us‐
age is similar to the rndc-confgen <#std-iscman-rndc-confgen> command for setting up command-channel security.)
Note that named <#std-iscman-named> itself can configure a local DDNS key for use with nsupdate -l <#cmdoption-nsupdate-l>; it does this when a zone is con‐
figured with update-policy local;. ddns-confgen is only needed when a more elaborate configuration is required: for instance, if nsupdate <#
std-iscman-nsupdate> is to be used from a remote system.
OPTIONS
-a algorithm
This option specifies the algorithm to use for the TSIG key. Available choices are: hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, and
hmac-sha512. The default is hmac-sha256. Options are case-insensitive, and the "hmac-" prefix may be omitted.
-h This option prints a short summary of options and arguments.
-k keyname
This option specifies the key name of the DDNS authentication key. The default is ddns-key when neither the -s nor -z option is specified; otherwise,
the default is ddns-key as a separate label followed by the argument of the option, e.g., ddns-key.example.com. The key name must have the format of
a valid domain name, consisting of letters, digits, hyphens, and periods.
-q This option enables quiet mode, which prints only the key, with no explanatory text or usage examples. This is essentially identical to tsig-keygen <#
std-iscman-tsig-keygen>.
-s name
This option generates a configuration example to allow dynamic updates of a single hostname. The example named.conf <#std-iscman-named.conf> text
shows how to set an update policy for the specified name using the "name" nametype. The default key name is ddns-key.name. Note that the "self" name‐
type cannot be used, since the name to be updated may differ from the key name. This option cannot be used with the -z option.
-z zone
This option generates a configuration example to allow dynamic updates of a zone. The example named.conf <#std-iscman-named.conf> text shows how to
set an update policy for the specified zone using the "zonesub" nametype, allowing updates to all subdomain names within that zone. This option can‐
not be used with the -s option.
SEE ALSO
nsupdate(1) <#std-iscman-nsupdate>, named.conf(5) <#std-iscman-named.conf>, named(8) <#std-iscman-named>, BIND 9 Administrator Reference Manual.
Author
Internet Systems Consortium
Copyright
2025, Internet Systems Consortium
9.20.17 2025-12-17 DDNS-CONFGEN(8)
Schlüsselmaterial mit rndc-confgen für rndc erzeugen
Mit Hilfe des Befehls rndc-confgen aus dem ArchLinux-Paket bind kann sowohl dieser symmetrische 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.
In folgendem Beispiel, welches wir lediglich zum Anzeigen der später benötigten Konfigurationsoptionen benutzen, nutzen wir folgende Optionen beim Aufruf des Hilfsprogramms rndc-confgen
-A algorithm (Diese Option gibt den Algorithmus an, der für den TSIG-Schlüssel verwendet werden soll.) = hmac-sha512
-b keysize (Diese Option gibt die Größe des Authentifizierungsschlüssels in Bits an.) = 512
-k keyname (Diese Option gibt den Schlüsselnamen des rndc-Authentifizierungsschlüssels an.) = rndc-key
# rndc-confgen -A hmac-sha512 -b 512 -c /etc/rndc.key -k rndc-key -u named
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-sha512;
secret "7xt2MC8jnLUbO/GcBeW7uuKhzYi8LkDLNuVHEyEa8Eo2RPYyHEtDxF5ubrYFJsCJlVEzFjJ0WgbeFoR8iO/5Zw==";
};
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-sha512;
# secret "7xt2MC8jnLUbO/GcBeW7UUKhzYi8LkDLNuVHEyEa8Eo2RPYyHEtDxF5ubrYFJsCJlVEzFjJ0WEgB13rR8iO/5Zw==";
# };
#
# 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ässiger ist es jedoch diesen Schlüssel in eine eigene Konfigurationsdatei zu hinterlegen und diese Datei dann entsprechend zu inkludieren! Wir werden diesen Konfigurationsvorschlag also so nicht 1:1 umsetzen, sondern die ganze Sache besser angehen und realisieren!
Wir erstellen also nun unseren eigenen Schlüssel und schreiben diesen in eine eigene Datei, hierzu benutzen wir folgende Optionen beim Aufruf von rndc-confgen:
-A algorithm (Diese Option gibt den Algorithmus an, der für den TSIG-Schlüssel verwendet werden soll.) = hmac-sha512
-b keysize (Diese Option gibt die Größe des Authentifizierungsschlüssels in Bits an.) = 512
-a (Diese Option legt die automatische rndc-Konfiguration fest, die eine Datei /etc/rndc.key erstellt, die sowohl von rndc als auch von named beim Start gelesen wird.)
-c keyfile (Diese Option wird zusammen mit der Option -a verwendet, um einen alternativen Speicherort für rndc.key anzugeben.) = /etc/rndc.key
-k keyname (Diese Option gibt den Schlüsselnamen des rndc-Authentifizierungsschlüssels an.) = homelab-key
-u user (Diese Option wird zusammen mit der Option -a verwendet, um den Eigentümer der generierten rndc.key-Datei festzulegen.) = named
Wichtig:
Der Name unseres eigenen symmetrischen Schlüssels, den wir nachfolgend generieren werden, darf nicht rndc-key lauten, da ansonsten beim Verwendung in der Konfigurationsdatei /etc/rndc.conf und bei Verwendung des Schlüsselnamens rndc-key in der Konfigurationsdatei folgender Warnhinweis erscheinen würde:
WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)
Aus diesem Grund verwenden wir, wie oben vermerkt den Schlüsselnamen homelab.key!
# rndc-confgen -A hmac-sha512 -b 512 -a -c /etc/rndc.key -k homelab-key -u named
wrote key file "/etc/rndc.key"
Ob unsere Schlüsseldatei wunschgemäß angelegt und mit dem gewünschten Informationen versorgt wurde, wurde können wir mit einem Blick in die Datei /etc/rndc.key werfen.
# ll /etc/rndc.key
-rw------- 1 named root 147 Dec 28 17:53 /etc/rndc.key
Damit nun nur noch der Nutzer mit root-Rechten die Datei verändern kann, aber der User named diese weiterhin lesen kann, werden wir nun noch die Datei- und Nutzerrechte noch etwas anpassen und somit die Sicherheit ein klein wenig erhöhen, nicht daß uns da noch jemand kommt mit dem Hinweis, wir würden hier nur eine Frickel-/Bastellösung bauen!
# chown root:named /etc/rndc.key
# chmod 640 /etc/rndc.key
Als Ergebnis haben wir nun:
# ll /etc/rndc.key
-rw-r----- 1 root named 147 Dec 28 17:53 /etc/rndc.key
Root-Nameserver
Damit unser Nameserver ordnungsgemäß DNS-Anfragen „top-down“ durchführen kann, muß dieser natürlich Kenntnis von den 13 Root Nameservern haben. Bei der Installation des ArchLinux Pakets bind keine Default-Konfigurationsdatei mit diesen Informationen mitgeliefert wurde, werden wir uns nun die betreffenden Informationen besorgen und in der Datei /var/named/named.root ablegen.
─────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────
│ File: /var/named/named.root
─────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │
2 │ ; <<>> DiG 9.20.17 <<>> +bufsize=1200 +norec NS . @a.root-servers.net
3 │ ;; global options: +cmd
4 │ ;; Got answer:
5 │ ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52818
6 │ ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
7 │
8 │ ;; OPT PSEUDOSECTION:
9 │ ; EDNS: version: 0, flags:; udp: 4096
10 │ ;; QUESTION SECTION:
11 │ ;. IN NS
12 │
13 │ ;; ANSWER SECTION:
14 │ . 518400 IN NS l.root-servers.net.
15 │ . 518400 IN NS j.root-servers.net.
16 │ . 518400 IN NS f.root-servers.net.
17 │ . 518400 IN NS h.root-servers.net.
18 │ . 518400 IN NS d.root-servers.net.
19 │ . 518400 IN NS b.root-servers.net.
20 │ . 518400 IN NS k.root-servers.net.
21 │ . 518400 IN NS i.root-servers.net.
22 │ . 518400 IN NS m.root-servers.net.
23 │ . 518400 IN NS e.root-servers.net.
24 │ . 518400 IN NS g.root-servers.net.
25 │ . 518400 IN NS c.root-servers.net.
26 │ . 518400 IN NS a.root-servers.net.
27 │
28 │ ;; ADDITIONAL SECTION:
29 │ l.root-servers.net. 518400 IN A 199.7.83.42
30 │ l.root-servers.net. 518400 IN AAAA 2001:500:9f::42
31 │ j.root-servers.net. 518400 IN A 192.58.128.30
32 │ j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30
33 │ f.root-servers.net. 518400 IN A 192.5.5.241
34 │ f.root-servers.net. 518400 IN AAAA 2001:500:2f::f
35 │ h.root-servers.net. 518400 IN A 198.97.190.53
36 │ h.root-servers.net. 518400 IN AAAA 2001:500:1::53
37 │ d.root-servers.net. 518400 IN A 199.7.91.13
38 │ d.root-servers.net. 518400 IN AAAA 2001:500:2d::d
39 │ b.root-servers.net. 518400 IN A 170.247.170.2
40 │ b.root-servers.net. 518400 IN AAAA 2801:1b8:10::b
41 │ k.root-servers.net. 518400 IN A 193.0.14.129
42 │ k.root-servers.net. 518400 IN AAAA 2001:7fd::1
43 │ i.root-servers.net. 518400 IN A 192.36.148.17
44 │ i.root-servers.net. 518400 IN AAAA 2001:7fe::53
45 │ m.root-servers.net. 518400 IN A 202.12.27.33
46 │ m.root-servers.net. 518400 IN AAAA 2001:dc3::35
47 │ e.root-servers.net. 518400 IN A 192.203.230.10
48 │ e.root-servers.net. 518400 IN AAAA 2001:500:a8::e
49 │ g.root-servers.net. 518400 IN A 192.112.36.4
50 │ g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d
51 │ c.root-servers.net. 518400 IN A 192.33.4.12
52 │ c.root-servers.net. 518400 IN AAAA 2001:500:2::c
53 │ a.root-servers.net. 518400 IN A 198.41.0.4
54 │ a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30
55 │
56 │ ;; Query time: 13 msec
57 │ ;; SERVER: 2001:503:ba3e::2:30#53(a.root-servers.net) (UDP)
58 │ ;; WHEN: Mon Jan 12 17:08:01 CET 2026
59 │ ;; MSG SIZE rcvd: 811
─────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────
Zonen und Views
Damit unser Nameserver nun für die unterschiedlichen Zonen, die wir zu Beginn dieses WIKI-Artikels im Abschnitt Herausforderung / Aufgabenstellung ausgemacht haben, müssen wir nun noch die erforderlichen Zonen-Dateien erstellen und unserem BIND bekannt geben.
extern (Internet), Domainspezifisch:
nausch.org mit jeweils öffentlichen IP-Adressen IPv4 und IPv6 (GUA)
und später ggf. für weitere weitere Domains
intern:
EDMZ mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
IDMZ mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
INTRA mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
ACHTUNG:
Da wir später DNSSEC einführen und verwenden wollen, müssen wir unbedingt auf folgendes achten: Jedes Zone-File darf nur einmal existieren, auch wenn ein und die selbe Information in mehreren views verwendet werden soll!
Wir müssen also für die Zonen EDMZ und IDMZ, welche ja in beiden views verwendet werden sollen, separate Dateien anlegen. Diesen Dateien stellen wir dann zur Unterscheidung einfach ein e. für die externe view voran und i. für die interne view! Wir werden später sowieso die Zonendateien mit Hilfe von Ansible verwalten, so daß dieser vermeintliche Mehraufwand nicht weiter ins Gewicht fallen wird!
Wir werden also nun für diese unterschiedlichen Zonen jeweils zwei zugehörige Zonen-Dateien anlegen, eine für die forward- und eine für die reverse-Auflösung:
Damit alle unsere eigenen Zonen-Dateien aufgeräumt in einem eigenen (Unter-)Verzeichnis liegen, legen wir uns nun noch ein entsprechendes Verzeichnis an.
# mkdir /var/named/zones
Hier passen wir noch die Berechtigung des gerade angelegten Verzeichnisses an.
# chmod 770 /var/named/zones
Zu guter Letzt korrigieren wir noch die User- und Gruppenberechtigungen unseres neuen Unterverzeichnisses für die Zonen-Dateien.
# chown root:named /var/named/zones
Zone-Files
Was nun noch fehlt sind die einzelnen Zonen-Dateien, welche nun wir anlegen und mit Leben füllen wollen.
zones/i.intra.nausch.org.db
Als erstes legen wir das Zonenfile für die forward-Auflösung unserer Subdomain/Zone intra.nausch.organ.
# vim /var/named/zones/i.intra.nausch.org.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
pml010070 IN A 10.0.10.70
IN AAAA fd00::7:10:0:10:70
nitro-pc IN CNAME pml010070
vml010110 IN A 10.0.10.110
IN AAAA fd00::7:10:0:10:110
fwc IN CNAME vml010110
Zum Validieren unseres Zone File benutzen wir das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone intra.nausch.org/IN: loaded serial 2025122801
OK
Dieses exemplarische Zone-File wollen wir uns nun noch etwas genauer ansehen.
Die $ORIGIN-Direktive: $ORIGIN definiert den Domain-Namen. Immer wen eine $ORIGIN-Zeile in einer Zonendatei vermerkt wird, handelt es sich hierbei um eine Abkürzung, die BIND wissen lässt, dass alle nicht abgeschlossenen Hostnamen-Verweise, die auf diese Zeile folgen, vermutlich auf das Argument enden, das auf $ORIGIN folgt. Diese Zeile ist optional, da wir nachfolgend die @-Zeichen verwenden werden und sei hier nur der Vollständigkeit halber erwähnt.
Die $TTL-Anweisung:
MIT $TTL legen wird die Standard-TTL2) für nachfolgende Datensätze fest, welche keine eigene separaten definierten TTLs haben.
Sowohl $ORIGIN als auch $TTL können in derselben Zone mehrfach definiert werden. Jedes Mal, wenn wir diese neu definieren, ändern man damit ihre Werte für alle Zeilen unterhalb der neuen Werte in derselben Zonendatei.
Der SOA-Record:
@ IN SOA ns1 hostmaster.nausch.org. (
2024110202 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
Das @-Zeichen ist ein Platzhalter, der sogenannte Origin, den BIND9 für die in der /etc/named.conf genannte Zone (intra.nausch.org) einsetzt. Wird in der Zonendatei der Zonenname ohne jegliche Extension isoliert genannt, dann darf dieser durch das Zeichen „@“ ersetzt werden.
Die Datenklasse-IN:
Die Datenklasse IN steht für „Internet“. Die Datensatzklasse ist optional und könnte auch weggelassen werden - BIND geht dann davon aus, dass der angegebene Datensatz zur Klasse IN gehört. Es wir aber grundsätzlich empfohlen diese anzugeben und nicht wegzulassen, damit nicht bei etwaigen Änderungen plötzlich z.B. nach einer Aktualisierung des BIND-Paketes alle Zonen-Dateien beschädigt und somit unbrauchbar sein könnten!
SOA ist der hier verwendete Record-Typ.
ns1 Dies ist der FQDN des primären Nameservers für die Domain selbst. Da in diesem Fall der abschliessende . fehlt, zeigt dies dem BIND an, dass der FQDN noch aus dem genannten Namen mit dem Wert der $ORIGIN-Direktive b.z.w. dem verwendeten Verweis auf das @-Zeichen erweitert werden muss um den tatsächlichen FQDN zu erhalten!
Das nächste Argument hostmaster.nausch.org. ist kein FQDN, obwohl dies auf den ersten Blick so scheinen mag. Da es sich beim @-Zeichen in einer Zonen-Datei um ein reserviertes handelt, ist dieser vermeintliche FQDN, nichts anderes als eine eMail-Adresse, in diesem Fall also hostmaster@nausch.org.
Weiter geht es mit den Angaben zu serial, refresh, retry, expire und negative caching TTL für die Zone innerhalb der runden Klammern. Die Kommentare hier sind optional und werden vom BIND nicht weiter beachtet, erleichtern aber dem Admin später doch ein wenig das Leben. Aus diesem Grund geben wir diese hier entsprechend an.
serial – Dies ist eine einfache Seriennummer für die Zonendatei, die bei jeder Änderung des Zoneninhalts erhöht werden muss. Wird die Seriennummer der Zonendatei nicht aktualisiert, werden Ihre Änderungen an der Zone bei einem rndc reloadnicht übernommen, sondern die zuvor zwischengespeicherten Einträge aus der Zone verwendet! Die Verwendung der Seriennummerformates YYYMMDDnn ist empfohlen, da ein Administrator es hier wesentlich leichter hat, wenn er ermitteln wollte wie lange die letzte Änderung schon her ist bzw. ob am betreffenden Tag schon mehrmals das Zone-File angepasst worden ist.
refresh - Nach Ablauf dieser definierten Zeit sollten sekundäre Nameserver den primären Nameserver nach diesem SOA-Eintrag abfragen, um Änderungen der Seriennummer zu erkennen. Sofern die Seriennummer erhöht wurde, müssen alle zwischengespeicherten Datensätze ungültig gemacht und erneut vom primären Nameserver abgerufen werden.
retry - Sofern der primäre Nameserver nicht auf eine SOA-Anfrage reagiert, sollte ein sekundärer Nameserver so lange warten, bevor er erneut versucht, den primären Nameserver abzufragen.
expire - Reagierte der primäre Nameserver innerhalb dieses Zeitraums nicht auf die SOA-Anfrage eines sekundären Nameservers, sollte der sekundäre Nameserver die DNS-Auflösung für die Domain vollständig einstellen und keine Anfragen mehr beatworten.
negative caching TTL – Diese steuert, wie lange andere Server „No-Such-Domain“-Antworten (NXDOMAIN) von diesem Server zwischenspeichern. Weitere Einzelheiten hierzu findet man in RFC 2308.
Der NS-Record(s):
In einem oder mehreren Einträgen wird hier definiert, wer der oder die autoritative Nameserver für unsere Zone ist bzw. sind. Die Hostnamen können entweder als FQDN mit einem abschliessenden . versehen werden oder auch nur mit ihrem Hostnamen definiert werden, der dann mit Hilfe des @-Zeichens bzw. der $ORIGIN-Direktive verfollständigt wird. Zu beachten ist, dass hier keinesfalls eine IP-Adresse sondern ausschliesslich Hostnamen verwendet werden dürfen!
Der MX-Record:
Hier wird festgelegt welche® Mailserver für die Zone zuständig sind. Mit Hilfe des MX-Records wissen alle Clients und User, die eMails an eine beliebige Adresse der Subdomain intra.nausch.org senden möchten, über welches Mailrelay sie ihre SMTP-Verbindung herzustellen haben.
Der A-Record :
A-Records sind der Teil einer Zonendatei, der tatsächlich das tut, was die meisten Menschen mit DNS verbinden. Sie übersetzen einen Hostnamen in eine reine IPv4-Adresse. Bei Bedarf können auch einem Namen mehrere IPv4-Adressen zugewiesen werden.
Der AAAA-Record*:
Der „Quad-A“-Record und keinesfalls der „Ahhh“-Record ist das Äquivalent für die IPv6-Adresszuweisung, was eben der A-Record bei IPv4 entspricht.
Der CNAME-Record:
Der letzte Datensatztyp, auf welchen wir hier in diesem Beispiel noch kurz eingehen wollen, ist der CNAME was für Canonical Name steht. Dies ist ein Alias, mit dem man BIND anweisen kann, Anfragen für den CNAME jeweils immer mit dem im Zielargument angegebenen A- oder AAAA-Record aufzulösen.
zones/i.intra.nausch.org.in-addr.db
Als nächstes legen wir das Zone-File für die IPv4-Reverseauflösung für unsere Subdomain/Zone intra.nausch.organ.
# vim /var/named/zones/i.intra.nausch.org.in-addr.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
70 IN PTR pml000070.intra.nausch.org.
IN PTR nitro-pc.intra.nausch.org.
110 IN PTR vml000110.intra.nausch.org.
IN PTR fwc.intra.nausch.org.
Auch hier validieren wir unseres Zone File mit Hilfe des Programms named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone intra.nausch.org.in-addr.db/IN: loaded serial 2025122801
OK
zones/i.intra.nausch.org.ip6.db
Was nun noch fehlt ist die Zonen-Datei für die IPv6-Reverseauflösung unserer Subdomain/Zone intra.nausch.org, die wir nun auch noch anlegen.
Zur Erinnerung schauen wir uns kurz nochmals an, wie der Reverse-Eintrag für die Adresse fd00::7:10:0:10:70 auszusehen hat: 0.7.0.0.0.1.0.0.0.0.0.0.0.1.0.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f
Damit wir uns nicht nun bei der Adresse jedes mal einen Wolf tippen und die Tasten 0 und . auf unserer Tastatur überbeanspruchen müssen, verwenden wir hier die $ORIGIN-Direktive $ORIGIN 0.1.0.0.0.0.0.0.0.1.0.0. Ferner lassen wir die letzten 4 Stellen der Adresse „unterminiert“, d.h. diese Adressangabe endet nicht mit einem Punkt . und diese wird somit mit den Angaben der $ORIGIN-Direktive ergänzt.
Aus 0.7.0.0 und der $ORIGIN-Direktive wird also in Verbindung mit der Zone-Definition (zone „7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa“)in der /etc/named.conf die vollständige Adresse: 0.7.0.0.0.1.0.0.0.0.0.0.0.1.0.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f
# vim /var/named/zones/i.intra.nausch.org.ip6.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
$ORIGIN 0.1.0.0.0.0.0.0.0.1.0.0
0.7.0.0 IN PTR pml000070.intra.nausch.org.
IN PTR nitro-pc.intra.nausch.org.
0.1.1.0 IN PTR vml000110.intra.nausch.org.
IN PTR fwc.intra.nausch.org.
Wie schon zuvor auch validieren wir hier unseres Zone File mit Hilfe des Programms named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone intra.nausch.org.ip6.db/IN: loaded serial 2025122801
OK
Somit haben wir alle drei benötigten Zonen-Dateien für die Zone intra.nausch.org fehlerfrei angelegt.
zones/[i|e].idmz.nausch.org.db
Kommen wir nun zur Subdomain/Zone idmz.nausch.org. Hier benötigen wir zwei identische Zonefiles, einmal für die view internal und einmal für die view external. Als erstes legen wir das Zone-File für die view internal zur forward-Auflösung für die Subdomain/Zone idmz.nausch.org an.
# vim /var/named/zones/i.idmz.nausch.org.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
vml000070 IN A 10.0.0.70
IN AAAA fd00::3:10:0:0:70
imap IN CNAME vml000070
mda IN CNAME vml000070
pop3 IN CNAME vml000070
vml000080 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
mta IN CNAME vml000080
vml000110 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
dns IN CNAME vml000110
vml000210 IN A 10.0.0.210
IN AAAA fd00::3:10:0:0:210
Für die view external benötigen wir nun die gleiche Datei nochmals, da wir ja später DNSSEC nutzen wollen - also kopieren wir kurzerhand die gerade angelegte Zonen-Datei einfach.
# cp -a i.idmz.nausch.org.db e.idmz.nausch.org.db
Wie soll es anderes sein, zum Validieren unseres Zone File benutzen wir auch hier das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone idmz.nausch.org/IN: loaded serial 2025122801
OK
zones/[i|e].idmz.nausch.org.in-addr.db
Als nächstes benötigen wir die beiden Zonendateien für die IPv4-Reverse-Auflösung der beiden views internal und external. Wir legen zunächst das Zone-File für die view internal zur IPv4-reverse-Auflösung für die Subdomain/Zone idmz.nausch.org an.
# vim /var/named/zones/i.idmz.nausch.org.in-addr.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
70 IN PTR vml000070.idmz.nausch.org.
IN PTR imap.idmz.nausch.org.
IN PTR mda.idmz.nausch.org.
IN PTR pop3.idmz.nausch.org.
80 IN PTR vml000080.idmz.nausch.org.
IN PTR mta.idmz.nausch.org.
IN PTR mx1.idmz.nausch.org.
110 IN PTR vml000110.idmz.nausch.org.
IN PTR dns.intra.nausch.org.
210 IN PTR vml000210.idmz.nausch.org.
Für die view external benötigen wir nun die gleiche Datei nochmals, da wir ja später DNSSEC nutzen wollen - also kopieren wir kurzerhand auch diese soeben angelegte Zonen-Datei einfach.
# cp -a i.idmz.nausch.org.in-addr.db e.idmz.nausch.org.in-addr.db
Wie soll es anderes sein, zum Validieren unseres Zone File benutzen wir auch hier das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone idmz.nausch.org/IN: loaded serial 2025122801
OK
zones/[i|e].idmz.nausch.org.ip6.db
Was nun noch fehlt sind die beiden die Zonen-Dateien für die IPv6-revers-Auflösung unserer Subdomain/Zone idmz.nausch.org vie die beiden views internal und external, welche wir nun auch noch anlegen.
Auch hier werden wir die Direktive $ORIGIN verwenden, wie wir dies auch schon bei der Zone intra.nausch.org gemacht hatten.
# vim /var/named/zones/i.idmz.nausch.org.ip6.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
$ORIGIN 0.0.0.0.0.0.0.0.0.1.0.0
0.7.0.0 IN PTR vml000070.idmz.nausch.org.
IN PTR imap.idmz.nausch.org.
IN PTR mda.idmz.nausch.org.
IN PTR pop3.idmz.nausch.org.
0.8.0.0 IN PTR vml000080.idmz.nausch.org.
IN PTR mta.idmz.nausch.org.
IN PTR mx1.idmz.nausch.org.
0.1.1.0 IN PTR vml000110.idmz.nausch.org.
IN PTR fwc.idmz.nausch.org.
IN PTR dns.idmz.nausch.org.
0.1.2.0 IN PTR vml000210.idmz.nausch.org.
IN PTR fwb.idmz.nausch.org.
Auch hier kopieren wir die Datei für unsere zweite view.
# cp -a /var/named/zones/i.idmz.nausch.org.ip6.db /var/named/zones/e.idmz.nausch.org.ip6.db
Wie schon zuvor auch validieren wir hier unseres Zone File mit Hilfe des Programms named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone idmz.nausch.org.ip6.db/IN: loaded serial 2025122801
OK
Somit haben wir auch hier alle sechs benötigten Zonen-Dateien für die Zone idmz.nausch.org für beide views fehlerfrei angelegt.
zones/[i|e]edmz.nausch.org.db
Machen wir nun weiter mit der nächsten Schutz-Zone und legen zunächst die Zonen-Datei für die forward-Auflösung für die Subdomain/Zone edmz.nausch.org für die view internal an.
# vim /var/named/zones/i.edmz.nausch.org.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
pnc172001 IN A 172.17.2.1
fwa IN CNAME pnc172001
vml000017 IN A 172.17.2.17
fwe IN CNAME vml000017
ptc172030 IN A 172.17.2.30
snom385 IN CNAME ptc172030
tel-buero IN CNAME ptc172030
ptc172031 IN A 172.17.2.31
snom360 IN CNAME ptc172031
tel-wohnzimmer IN CNAME ptc172031
ptc172032 IN A 172.17.2.32
snom320 IN CNAME ptc172032
tel-keller IN CNAME ptc172032
ptc172033 IN A 172.17.2.33
t24-tfe IN CNAME ptc172033
mobotix-t24 IN CNAME ptc172033
ptc172108 IN A 172.17.2.108
dect-basis IN CNAME ptc172108
elmeg-dect160 IN CNAME ptc172108
vml000210 IN A 172.17.2.210
IN AAAA fd00::172:17:2:210
fwb IN CNAME vml000210
Für die view external benötigen wir auch hier ein entsprechenden Pondon - wir kopieren also das gerade angelegte Zonenfile für die zweite view.
# cp -a /var/named/zones/i.edmz.nausch.org.db /var/named/zones/e.edmz.nausch.org.db
Wie soll es anderes sein, zum Validieren unseres Zone File benutzen wir auch hier das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone edmz.nausch.org/IN: loaded serial 2025122801
OK
zones/[i|e].edmz.nausch.org.in-addr.db
Kommen wir nun zu den beiden Zone-Files für die reverse-Auflösung für die Subdomain/Zone edmz.nausch.org. Zunächst legen wir die Datei für die view internal an.
# vim /var/named/zones/i.edmz.nausch.org.in-addr.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
1 IN PTR pnc172001.edmz.nausch.org.
IN PTR fwa.edmz.nausch.org.
17 IN PTR vml000017.edmz.nausch.org.
IN PTR fwe.edmz.nausch.org.
30 IN PTR ptc172030.edmz.nausch.org.
IN PTR snom385.edmz.nausch.org.
IN PTR tel-buero.edmz.nausch.org.
31 IN PTR ptc172031.edmz.nausch.org.
IN PTR snom360.edmz.nausch.org.
IN PTR tel-wohnzimmer.edmz.nausch.org.
32 IN PTR ptc172032.edmz.nausch.org.
IN PTR snom320.edmz.nausch.org.
IN PTR tel-keller.edmz.nausch.org.
33 IN PTR ptc172033.edmz.nausch.org.
IN PTR mobotix-t24.edmz.nausch.org.
IN PTR t24-tfe.edmz.nausch.org.
108 IN PTR ptc172108.edmz.nausch.org.
IN PTR elmeg-dect160.edmz.nausch.org.
IN PTR dect-basis.edmz.nausch.org.
210 IN PTR vml000210.edmz.nausch.org.
IN PTR fwb.edmz.nausch.org.
Nun kopieren wir diese Datrei für die andere view entsprechend.
# cp -a /var/named/zones/i.edmz.nausch.org.db /var/named/zones/e.edmz.nausch.org.db
Wie soll es anderes sein, zum Validieren unseres Zone File benutzen wir auch hier das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone edmz.nausch.org/IN: loaded serial 2025122801
OK
zones/[i|e]edmz.nausch.org.ip6.db
Zu guter Letzt legen wir auch hier noch für die IPv6-reverse-Auflösung unserer Subdomain/Zone edmz.nausch.org die beiden betreffenden Zone-Files an.
# vim /var/named/zones/i.edmz.nausch.org.ip6.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
0.1.2.0.2.0.0.0.7.1.0.0.2.7.1.0 IN PTR vml000210.edmz.nausch.org.
IN PTR fwb.edmz.nausch.org.
Auch hier kopieren wir die Datei noch für die view external entsprechend.
# cp -a /var/named/zones/i.edmz.nausch.org.in-addr.db /var/named/zones/e.edmz.nausch.org.in-addr.db
Wie schon zuvor auch validieren wir hier unseres Zone File mit Hilfe des Programms named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
zone edmz.nausch.org/IN: loaded serial 2025122801
OK
Somit haben wir auch hier alle sechs benötigten Zonen-Dateien für die Zone edmz.nausch.org für die beiden views internal und external fehlerfrei angelegt.
zones/e.nausch.org.db
Nachdem wir nun aus Sicht der Domäne nausch.org alle internen Zonen-Dateien angelegt haben, machen wir uns nun zum Schluss daran, auch die externe Sicht, also die externen Zonen-Files anzulegen. Fangen wir mit der Zonen-Datei für die forward-Auflösung für die Domain nausch.organ und zwar für die view external, bei der die öffentlichen IPv4 und IPv6-GUA aufgelöst werden sollen.
# vim /var/named/zones/e.nausch.org.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1.idmz hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1.idmz
IN MX 10 mx1.idmz
ns1.idmz IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1.idmz IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
nausch.org IN A 217.92.13.131
IN AAAA 2003:a:e0d:7603:10::90
imap IN A 217.92.13.131
IN AAAA 2003:a:e0d:7603:10::70
mda IN CNAME imap
pop3 IN CNAME imap
mx1 IN A 217.92.13.131
IN AAAA 2003:a:e0d:7603:10::80
mta IN CNAME mx1
Wie soll es anderes sein, zum Validieren unseres Zone File benutzen wir auch hier das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
Bei der Eingangs betrachteten Herausforderung und Aufgabenstellung hatten wir definiert, daß Anfragen aus den beiden Schutzzonen intra und idmz, welche die offiziellen Domain nausch.org betreffen als Antwort die „internen“ ULA aus der Zone IDMZ beinhalten sollen nicht aber die offiziellen GUA-Adressen!
Somit benötigen wir hierzu eine separate Zonen-Datei, der wir den Namen i.nausch.org geben um diese vom Rest einfach unterscheiden zu können.
Wir legen uns also nun eine Pseudo-Sub-Domain Zone-File mit dem Namen i.nausch.org an.
# vim /var/named/zones/i.nausch.org.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1.idmz.nausch.org. hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1.idmz
IN MX 10 mx1.idmz
ns1.idmz IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1.idmz IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
imap IN A 10.0.0.70
IN AAAA fd00::3:10:0:0:70
mda IN CNAME imap
pop3 IN CNAME imap
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
mta IN CNAME mx1
Auch hier prüfen wir das Zone-File ob sich syntaktische Fehler eingeschlichen haben.
Nun legen wir die Zonen-Datei für die reverse-Auflösung für die Domain nausch.org an.
# vim /var/named/zones/e.nausch.org.in-addr.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
@ IN PTR imap.nausch.org.
IN PTR mda.nausch.org.
IN PTR pop3.nausch.org.
IN PTR mta.nausch.org.
IN PTR mx1.nausch.org.
Wie soll es anderes sein, zum Validieren unseres Zone File benutzen wir auch hier das Programm named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
Abschließend zu guter Letzt benötigen wir auch hier für die IPv6-Reverseauflösung unserer Domain nausch.org ein zugehörige Zone-File, welches wir zum Schluß auch noch anlegen.
# vim /var/named/zones/e.nausch.org.ip6.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (
2025122801 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.0.110
IN AAAA fd00::3:10:0:0:110
mx1 IN A 10.0.0.80
IN AAAA fd00::3:10:0:0:80
$ORIGIN 0.0.0.0.0.0.0.0.0.1.0.0
0.7.0.0 IN PTR vml000070.nausch.org.
IN PTR imap.nausch.org.
IN PTR mda.nausch.org.
IN PTR pop3.nausch.org.
0.8.0.0 IN PTR vml000080.nausch.org.
IN PTR mx1.nausch.org.
0.1.1.0 IN PTR vml000110.nausch.org.
IN PTR fwc.idmz.nausch.org.
0.1.2.0 IN PTR vml000210.nausch.org.
IN PTR fwb.idmz.nausch.org.
Wie schon zuvor auch validieren wir hier unseres Zone File mit Hilfe des Programms named-checkzone und prüfen so, ob sich syntaktische Fehler eingeschlichen haben.
-rw-r--r-- 1 named named 2170 Dec 28 19:46 /var/named/zones/e.edmz.nausch.org.db
-rw-r--r-- 1 named named 2433 Dec 28 19:48 /var/named/zones/e.edmz.nausch.org.in-addr.db
-rw-r--r-- 1 named named 920 Dec 28 19:51 /var/named/zones/e.edmz.nausch.org.ip6.db
-rw-r--r-- 1 named named 1672 Dec 28 19:36 /var/named/zones/e.idmz.nausch.org.db
-rw-r--r-- 1 named named 1604 Dec 28 19:41 /var/named/zones/e.idmz.nausch.org.in-addr.db
-rw-r--r-- 1 named named 1647 Dec 28 19:43 /var/named/zones/e.idmz.nausch.org.ip6.db
-rw-r--r-- 1 named named 1462 Dec 28 19:57 /var/named/zones/e.nausch.org.db
-rw-r--r-- 1 named named 1218 Dec 28 20:02 /var/named/zones/e.nausch.org.in-addr.db
-rw-r--r-- 1 named named 1618 Dec 28 20:04 /var/named/zones/e.nausch.org.ip6.db
-rw-r--r-- 1 named named 2170 Dec 28 19:46 /var/named/zones/i.edmz.nausch.org.db
-rw-r--r-- 1 named named 2433 Dec 28 19:48 /var/named/zones/i.edmz.nausch.org.in-addr.db
-rw-r--r-- 1 named named 920 Dec 28 19:51 /var/named/zones/i.edmz.nausch.org.ip6.db
-rw-r--r-- 1 named named 1672 Dec 28 19:36 /var/named/zones/i.idmz.nausch.org.db
-rw-r--r-- 1 named named 1604 Dec 28 19:41 /var/named/zones/i.idmz.nausch.org.in-addr.db
-rw-r--r-- 1 named named 1647 Dec 28 19:43 /var/named/zones/i.idmz.nausch.org.ip6.db
-rw-r--r-- 1 named named 1154 Dec 28 19:25 /var/named/zones/i.intra.nausch.org.db
-rw-r--r-- 1 named named 1082 Dec 28 19:28 /var/named/zones/i.intra.nausch.org.in-addr.db
-rw-r--r-- 1 named named 1102 Dec 28 19:30 /var/named/zones/i.intra.nausch.org.ip6.db
-rw-r--r-- 1 named named 1328 Dec 28 19:59 /var/named/zones/i.nausch.org.db
named.conf
Damit unsere anfragenden Clients die von uns gewünschte und legitimierte Antwort bekommen werden wir nun in unser BIND8-Konfigurationsdatei verschiedene Zonen und Views anlegen.
// ****************************** named.conf ******************************// ISC Bind Konfigurationsdatei // Konfig-Beschreibung: https://dokuwiki.nausch.org/doku.php/linux:bind// ********** Variablendefinition für die unterschiedlichen ACLs **********
acl edmz {
172.17.2.0/24;2003:a:e0d:7600::/64;};
acl idmz {
10.0.0.0/24;
fd00::3:10:0:0:110/128;2003:a:e0d:7603::/64;};
acl intra {
10.0.10.0/24;
fd00::7:10:0:10:110/128;2003:a:e0d:7607::/64;};
acl primary {
10.0.0.110/32;
fd00::3:10:0:0:110/128;2003:a:e0d:7607:10::110/128;};
acl interfaces {
127.0.0.1;::1;
10.0.0.110/32;
fd00::3:10:0:0:110/128;2003:a:e0d:7603:10::110/128;
10.0.10.110/32;
fd00::7:10:0:10:110/128;2003:a:e0d:7607:10:0:10:110/128;};
acl local {
127.0.0.1;::1;};// *********************** rndc Schlüsseldefinition ***********************
include "/etc/rndc.key";// *********************** rndc Control-Definition ************************
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1;} keys {"homelab-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/keys";// Das Verzeichnis, in dem die Dateien gespeichert werden, welche // die verwalteten DNSSEC-Schlüssel verfolgen.
managed-keys-directory "/var/named/dynamic";// Dies gibt das Verzeichnis an, in dem die Konfigurationsparameter für// Zonen gespeichert werden, die über rndc addzone hinzugefügt wurden.// Standardmäßig ist dies das Arbeitsverzeichnis.
new-zones-directory "/var/named/zones";// 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";// Hiermit werden Speicherstatistiken in die Datei geschrieben, die beim// Beenden durch memstatistics-file angegeben wird. Die Standardeinstell-// ung ist "no", es sei denn, -m record wird in der Befehlszeile angege-// ben. In diesem Fall lautet die Einstellung "yes".
memstatistics yes;// Der Pfadname der Datei, in die der Server beim Beenden die // Speicherverbrauchsstatistik schreibt.
memstatistics-file "/var/named/data/named_mem_stats.txt";// Hiermit wird der Algorithmus festgelegt, der beim Generieren des Ser-// ver-Cookies verwendet werden soll. Die Optionen sind "aes", "sha1" // oder "sha256". Der Standardwert ist "aes", sofern dies von der krypto-// grafischen Bibliothek unterstützt wird, andernfalls "sha256".// cookie-algorithm aes;// 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";// Dies ist der für den TSIG-Sitzungsschlüssel zu verwendende Algorithmus.// Gültige Werte sind hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, // hmac-sha512 und hmac-md5. Wenn nichts angegeben wird, ist der // Standardwert hmac-sha256.
session-keyalg hmac-sha512;// Hiermit wird die maximale RSA-Exponentengröße in Bits festgelegt, die// bei der Validierung akzeptiert wird. Gültige Werte sind 35 bis 4096// Bits. Der Standardwert Null wird ebenfalls akzeptiert und entspricht// 4096.
max-rsa-exponent-size 4096;// 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-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 {::1;
127.0.0.1;};// Definiert welche Hosts gewöhnliche DNS-Fragen stellen dürfen.
allow-query {
edmz;
idmz;
intra;
localhost;};// Definiert welche lokalen Adressen gewöhnliche DNS-Anfragen// annehmen können.
allow-query-on {
interfaces;};// Definiert welche Hosts Antworten aus dem Cache erhalten dürfen.
allow-query-cache {
edmz;
idmz;
intra;
localhost;};// Definiert welche lokalen Adressen Antworten aus dem Cache senden können.
allow-query-cache-on {
interfaces;};// Legt fest, welche Hosts rekursive Abfragen über diesen Server i// durchführen dürfen.
allow-recursion {
edmz;
idmz;
intra;
localhost;};// Legt fest, welche lokalen Adressen rekursive Abfragen akzeptieren können.
allow-recursion-on {
interfaces;};// Gibt an, welche Hosts Zonentransfers vom Server empfangen dürfen.
allow-transfer {
interfaces;};// Ist die dynamische Aktualisierung für eine Zone mit der Option // "allow-update" aktiviert, darf KEINENFALLS die Zonendatei manuell // bearbeitet werden!
allow-update {
none;};// Wenn ja,dann können Zonen zur Laufzeit über rndc addzone hinzugefügt// werden. Die Standardeinstellung ist "no". Die Konfigurationsparame-// ter neu hinzugefügter Zonen werden gespeichert, sodass sie nach einem// Neustart des Servers erhalten bleiben. Die Konfigurationsinformationen// werden in einer Datei namens "viewname.nzf" gespeichert (oder, wenn // "named" mit liblmdb kompiliert wurde, in einer LMDB-Datenbankdatei // namens "viewname.nzd"). "viewname" ist der Name der Ansicht, es sei// denn, der Name der Ansicht enthält Zeichen, die nicht mit der Verwen-// dung als Dateiname kompatibel sind. In diesem Fall wird stattdessen// ein kryptografischer Hash des Ansichtsnamens verwendet. Konfigurati-// onen für Zonen, die zur Laufzeit hinzugefügt werden, werden entweder// in einer New-Zone-Datei (NZF) oder einer New-Zone-Datenbank (NZD) // gespeichert, je nachdem, ob named zum Zeitpunkt der Kompilierung mit// liblmdb verknüpft wurde. Weitere Informationen zu rndc addzone finden// Sie unter rndc – Name-Server-Steuerungsprogramm.
allow-new-zones no;// 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{ interfaces;};
listen-on-v6 port 53{ interfaces;};// 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 *;// Die Abfrageprotokollierung bietet ein vollständiges Protokoll aller// eingehenden Abfragen und aller Abfragefehler. Dies bietet einen besseren// Einblick in die Serveraktivität, allerdings mit einem erheblichen // Leistungsabfall bei stark ausgelasteten Servern. Die Option "querylog"// gibt an, ob die Abfrageprotokollierung beim ersten Start von named// aktiv sein soll.
querylog no;// 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 2048;// 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.// Dieser Wert ist immer auf 0 gesetzt. Weitere Informationen finden sich// im Sicherheitshinweis zu CVE-2021-25219.
lame-ttl 0;// 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.
hostname none;
server-id none;// BIND 9-Zugriffskontrolllisten werden verwendet, um den Zugriff auf ver-// schiedene Serverfunktionen entsprechend der IP-Adresse des Anfragenden // zu beschränken. BIND 9.10 kann Daten aus MaxMind GeoIP-Datenbanken ver-// wenden, um Beschränkungen basierend auf dem (vermuteten) geografischen// Standort dieser Adresse zu erreichen.
geoip-directory none;};// Die BIND 9-Statistiken können auch über das HTTP-Protokoll von // einem laufenden BIND 9-Server abgerufen werden. BIND 9 verfügt // über einen winzigen integrierten Webserver, der die Statistik-// daten im XML- oder JSON-Format bereitstellt.
statistics-channels {
inet 127.0.0.1 port 8080 allow {
127.0.0.1;};};// ******************** 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!//// 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!
view "intern" IN {// Ist der Anfragende Client aus dem Intranet (Zone intra)?
match-clients {
local;
intra;
idmz;};// View: intern - Zone: localhost
zone "localhost" IN {
type master;
file "localhost.zone";};// View: intern - Zone: localhost IPv4 (reverse)
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";};// View: intern - Zone: localhost IPv6 (reverse)
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"{
type master;
file "localhost.ip6.zone";};// View: intern - Zone: root server
zone "." IN {
type hint;
file "named.root";};// View: intern - Zone: intra.nausch.org (forward)
zone "intra.nausch.org" IN {
type master;
file "zones/i.intra.nausch.org.db";};// View: intern - Zone: intra.nausch.org (reverse)
zone "10.0.10.in-addr.arpa" IN {
type master;
file "zones/i.intra.nausch.org.in-addr.db";};// View: intern - Zone: intra.nausch.org (IPv6 ULA reverse)
zone "7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
type master;
file "zones/i.intra.nausch.org.ip6.db";};// View: intern - Zone: idmz.nausch.org (forward)
zone "idmz.nausch.org" IN {
type master;
file "zones/i.idmz.nausch.org.db";};// View: intern - Zone: idmz.nausch.org (reverse)
zone "0.0.10.in-addr.arpa" IN {
type master;
file "zones/i.idmz.nausch.org.in-addr.db";};// View: intern - Zone: idmz.nausch.org (IPv6 ULA reverse)
zone "3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
type master;
file "zones/i.idmz.nausch.org.ip6.db";};// View: intern - Zone: edmz.nausch.org (forward)
zone "edmz.nausch.org" IN {
type master;
file "zones/i.edmz.nausch.org.db";};// View: intern - Zone: edmz.nausch.org (reverse)
zone "2.17.172.in-addr.arpa" IN {
type master;
file "zones/i.edmz.nausch.org.in-addr.db";};// View: intern - Zone: edmz.nausch.org (IPv6 ULA reverse)
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
type master;
file "zones/i.edmz.nausch.org.ip6.db";};// View: intern - Zone: nausch.org (forward)
zone "nausch.org" IN {
type master;
file "zones/i.nausch.org.db";};};// Ist der Anfragende Client aus der DMZ?
view "extern" IN {
match-clients {
edmz;};// View: extern - Zone: localhost
zone "localhost" IN {
type master;
file "localhost.zone";};// View: extern - Zone: localhost (reverse IPv4)
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";};// View: extern - Zone: localhost (reverse IPv6)
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"{
type master;
file "localhost.ip6.zone";};// View: extern - Zone: root server
zone "." IN {
type hint;
file "named.root";};// View: extern - Zone: idmz.nausch.org (forward)
zone "idmz.nausch.org" IN {
type master;
file "zones/e.idmz.nausch.org.db";};// View: extern - Zone: idmz.nausch.org (reverse)
zone "0.0.10.in-addr.arpa" IN {
type master;
file "zones/e.idmz.nausch.org.in-addr.db";};// View: extern - Zone: idmz.nausch.org (IPv6 ULA reverse)
zone "3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
type master;
file "zones/e.idmz.nausch.org.ip6.db";};// View: extern - Zone: edmz.nausch.org (forward)
zone "edmz.nausch.org" IN {
type master;
file "zones/e.edmz.nausch.org.db";};// View: extern - Zone: edmz.nausch.org (reverse)
zone "2.17.217.in-addr.arpa" IN {
type master;
file "zones/e.edmz.nausch.org.in-addr.db";};// View: extern - Zone: edmz.nausch.org (IPv6 ULA reverse)
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
type master;
file "zones/e.edmz.nausch.org.ip6.db";};// View: extern - Zone: nausch.org (forward)
zone "nausch.org" IN {
type master;
file "zones/e.nausch.org.db";};// View: extern - Zone: nausch.org (reverse)
zone "131.13.92.217.in-addr.arpa" IN {
type master;
file "zones/e.nausch.org.in-addr.db";};// View: extern - Zone: nausch.org (IPv6 GUA reverse)
zone "3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa" IN {
type master;
file "zones/e.nausch.org.ip6.db";};};// ******************* Definition der Logging-Parameter *******************
logging {// Definition der unterschiedlichen Kanäle
channel default_log {
file "/var/log/named/default" versions 4 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel auth_servers_log {
file "/var/log/named/auth_servers" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel dnssec_log {
file "/var/log/named/dnssec" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel zone_transfers_log {
file "/var/log/named/zone_transfers" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel ddns_log {
file "/var/log/named/ddns" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel client_security_log {
file "/var/log/named/client_security" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel rate_limiting_log {
file "/var/log/named/rate_limiting" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel rpz_log {
file "/var/log/named/rpz" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};
channel dnstap_log {
file "/var/log/named/dnstap" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};// Wenn man die Kategorie "queries" definiert hat und standardmässig keine // Abfrageprotokollierung wünscht, stellt man sicher, dass Sie die Option // "querylog no"“ vorhanden ist. So kann man anschliessend die Abfrage-// protokollierung mit dem Befehl "rndc querylog" ein- und ausschalten.
channel queries_log {
file "/var/log/named/queries" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;};// Dieser Kanal ist dynamisch, sodass bei einer Erhöhung des Debug-Levels// mit Hilfe von rndc bei laufendem Server zusätzliche Informationen über// fehlgeschlagene Abfragen protokolliert werden.// Andere Debug-Informationen für andere Kategorien werden an den Kanal // default_debug (der ebenfalls dynamisch ist) gesendet, ohne jedoch die// reguläre Protokollierung zu beeinträchtigen.
channel query-errors_log {
file "/var/log/named/query-errors" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;};// Dies ist der Standard-Syslog-Kanal, der hier der Übersichtlichkeit // halber definiert wurde. Man muss ihn nicht verwenden, wenn man lieber// in eigenen Kanälen protokollieren möchte. Er sendet an die Daemon-// Einrichtung von syslog und sendet nur protokollierte Nachrichten mit// der Priorität "info" und höher. (Die Optionen zum Ausgeben von Zeit,// Kategorie und Severity sind nicht standardmäßig.)
channel default_syslog {
print-time yes;
print-category yes;
print-severity yes;
syslog daemon;
severity info;};// Dies ist der Standard-Debug-Ausgabekanal, welcher hier aus Gründen// der Übersichtlichkeit definiert wurde. Man kann natürlich das Ausgabe-// ziel auch neu definieren, wenn dies nicht zu den eigenen lokalen // Systemadministrationsplan für die Protokollierung passt. Es handelt// sich auch um einen speziellen Kanal, der nur dann eine Ausgabe erzeugt,// wenn der Debug-Level ungleich Null ist.
channel default_debug {
print-time yes;
print-category yes;
print-severity yes;
file "/var/log/named/named.run";
severity dynamic;};// Protokollieren von Routinevorgängen in Syslog und Standardprotokoll
category default{ default_syslog; default_debug; default_log;};
category config { default_syslog; default_debug; default_log;};
category dispatch { default_syslog; default_debug; default_log;};
category network { default_syslog; default_debug; default_log;};
category general { default_syslog; default_debug; default_log;};// Ab BIND 9.12 und neuer kann man die Zonenlastprotokollierung mit der// neuen Kategorie "zoneload logging" auf einen anderen Kanal umleiten.// Wenn dies als nützlich erachtet wird, muss man zunächst den neuen // Kanal definieren und bearbeitet dann die folgende Zeile, um die // Kategorie dorthin umzuleiten, anstatt sie an syslog und das Standard-// protokoll zu senden:
category zoneload { default_syslog; default_debug; default_log;};// Protokollnachrichten, die sich auf das beziehen, was wir während der// Rekursion von autoritativen Servern zurückerhalten haben (z.B. wenn// Lame-Server und deaktivierte DNS-Server andere Nachrichten verdecken,// kann man diese an ihren eigenen Kanal oder an null gesendet werden).// Manchmal sind diese Protokollnachrichten nützlich, um zu untersuchen,// warum einige Domains nicht oder nicht zuverlässig aufgelöst werden.
category resolver { auth_servers_log; default_debug;};
category cname { auth_servers_log; default_debug;};// category delegation-only { auth_servers_log; default_debug; };
category lame-servers { auth_servers_log; default_debug;};
category edns-disabled { auth_servers_log; default_debug;};// Protokollieren von Problemen mit DNSSEC:
category dnssec { dnssec_log; default_debug;};// Protokollieren aller Nachrichten, die sich auf die autoritative // Zonen Propagation (Ausbreitung) beziehen.
category notify { zone_transfers_log; default_debug;};
category xfer-in { zone_transfers_log; default_debug;};
category xfer-out { zone_transfers_log; default_debug;};// Protokollieren aller Nachrichten, die sich auf dynamische Aktualisie-// rungen von DNS-Zonendaten beziehen.
category update{ ddns_log; default_debug;};
category update-security { ddns_log; default_debug;};// Protokollieren aller Nachrichten, die sich auf den Client-Zugriff und// die Sicherheit beziehen. (Es gibt eine zusätzliche Kategorie "unmatched",// die standardmässig an null gesendet wird, aber hier hinzugefügt werden// kann, wenn man mehr als die einzeilige Zusammenfassung wünscht, die für// Fehler bei der Zuordnung zu einer Ansicht protokolliert wird).
category client{ client_security_log; default_debug;};
category security { client_security_log; default_debug;};// Protokollieren aller Nachrichten, die wahrscheinlich mit der Rate-Limiting// zusammenhängen. Dies umfasst RRL (Response Rate Limiting) – wird normaler-// weise auf autorisierenden Servern und Abrufen pro Server/Zone eingesetzt.// Hierbei ist zu beachten, dass dies nicht die Protokollierung von Änderun-// gen für Clients pro Abfrage umfasst (die im Cateory Resolver protokolliert// werden). Wichtig ist hier auch, dass gelegentlich andere Protokollnach-// richten von der Datenbankkategorie ausgegeben werden können, die sich // nicht auf das Rate-Limiting Verhalten von named beziehen.
category rate-limit { rate_limiting_log; default_debug;};
category spill { rate_limiting_log; default_debug;};
category database { rate_limiting_log; default_debug;};// Protokollieren von DNS-RPZ-Meldungen (Response Policy Zone), sofern DNS-// -RPZ nicht verwendet wird, kann man diese Kategorie und den zugehörigen// Kanal auskommentieren.
category rpz { rpz_log; default_debug;};// Protokollnachrichten zum DNS-Verkehrserfassungssystem "dnstap". (Wenn // man dnstap nicht verwenden will, muss man diese Kategorie und den zugehö-// rigen Kanal auskommentieren).
category dnstap { dnstap_log; default_debug;};// Sofern mane einen Server betreiben (z. B. einen der Internet-Root-Name-// server), der RFC 5011-Vertrauensanker-Updates bereitstellt, dann ist es // unter Umständen von Interesse, die Vertrauensanker-Telemetrieberichte zu // protokollieren, die der Server empfängt, um die Trust Anchor Propagierungs-// raten während eines Schlüsselwechsels zu analysieren. // Erachtet man dies als nützlich, konfiguriert man zunächst den neuen Kanal// und entfernt dann das Kommentarzeichen und die folgende Zeile, um die // Kategorie dorthin zu leiten, anstatt zu syslog und default log:
category trust-anchor-telemetry { default_syslog; default_debug; default_log;};// Wenn man die Kategorie "queries" definiert hat und standardmäßig keine Ab-// frageprotokollierung wünschen, muss man sicherstellen, dass Sie die Option // "querylog no"“ hinzufügt wurde. Anschliessend kann man da die Abfrageproto-// kollierung mit dem Befehl "rndc querylog" ein- und wieder ausschalten.
category queries { queries_log;};// Diese Protokollkategorie gibt nur Meldungen auf Debug-Ebene 1 oder höher // aus. Sie kann bei der Fehlerbehebung nützlich sein, wenn Abfragen zu einer // SERVFAIL-Antwort führen.
category query-errors { query-errors_log;};};
In oben gezeigtem Konfigurationsbeispiel wurden die entsprechenden Parametere in der Konfigurationsdatei /etc/named.conf jeweils entsprechend beschrieben!
Start des Daemon named
Überprüfen der bisherigen Konfiguration
Bevor wir unseren gerade konfigurierten ISC BIND Nameserver das erste mal starten werden, führen wir mit Hilfe des Programms named-checkconf noch ein paar einzelne Tests durch. Für eine reine Syntaktische Prüfung rufen wird das Programm ohne weitere optionale Parameter auf. Wie unter Unixoiden-Betriebssystem, bedeutet keine Rückmeldung hier alles in Ordung!
# named-checkconf
Mit der Option -l werden alle konfigurierten Zonen aufgelistet. Jede Ausgabezeile enthält den Zonennamen, die Klasse (z. B. IN), die Ansicht und den Typ (z. B. primär oder sekundär).
# named-checkconf -l
localhost IN intern master
0.0.127.in-addr.arpa IN intern master
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 intern master
. IN intern hint
intra.nausch.org IN intern master
10.0.10.in-addr.arpa IN intern master
7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN intern master
idmz.nausch.org IN intern master
0.0.10.in-addr.arpa IN intern master
3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN intern master
edmz.nausch.org IN intern master
2.17.172.in-addr.arpa IN intern master
0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN intern master
nausch.org IN intern master
localhost IN extern master
0.0.127.in-addr.arpa IN extern master
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 extern master
. IN extern hint
idmz.nausch.org IN extern master
0.0.10.in-addr.arpa IN extern master
3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN extern master
edmz.nausch.org IN extern master
2.17.217.in-addr.arpa IN extern master
0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN extern master
nausch.org IN extern master
131.13.92.217.in-addr.arpa IN extern master
3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa IN extern master
Mit der Option -z erfolgt eine Lade-Test aller Zonen vom Typ „primary“, die in Konfigurationsdatei /etc/named.conf gefunden wurden.
# named-checkconf -z
zone localhost/IN: loaded serial 42
zone 0.0.127.in-addr.arpa/IN: loaded serial 42
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 42
zone intra.nausch.org/IN: loaded serial 2025122801
zone 10.0.10.in-addr.arpa/IN: loaded serial 2025122801
zone 7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN: loaded serial 2025122801
zone idmz.nausch.org/IN: loaded serial 2025122801
zone 0.0.10.in-addr.arpa/IN: loaded serial 2025122801
zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN: loaded serial 2025122801
zone edmz.nausch.org/IN: loaded serial 2025122801
zone 2.17.172.in-addr.arpa/IN: loaded serial 2025122801
zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN: loaded serial 2025122801
zone nausch.org/IN: loaded serial 2025122801
zone localhost/IN: loaded serial 42
zone 0.0.127.in-addr.arpa/IN: loaded serial 42
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 42
zone idmz.nausch.org/IN: loaded serial 2025122801
zone 0.0.10.in-addr.arpa/IN: loaded serial 2025122801
zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN: loaded serial 2025122801
zone edmz.nausch.org/IN: loaded serial 2025122801
zone 2.17.217.in-addr.arpa/IN: loaded serial 2025122801
zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN: loaded serial 2025122801
zone nausch.org/IN: loaded serial 2025122801
zone 131.13.92.217.in-addr.arpa/IN: loaded serial 2025122801
zone 3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa/IN: loaded serial 2025122801
Start des named
Da die vorherigen Tests keinerlei Konfigurationsfehler aufzeigten und alle Zone-File richtig geladen werden können, spricht nun nichts mehr dagegen unseren DNS-Daemon named zu starten.
# systemctl start named.service
Im Journal wir der Start entsprechend dokumentiert.
Dec 28 20:26:33 vml000110 systemd[1]: Started Internet domain name server.
Dec 28 20:26:33 vml000110 named[2536]: starting BIND 9.20.17 (Stable Release) <id:00545e4>
Dec 28 20:26:33 vml000110 named[2536]: running on Linux x86_64 6.12.63-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 18 Dec 2025 14:48:15 +0000
Dec 28 20:26:33 vml000110 named[2536]: built with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/bind/src=/usr/src/debug/bind -flto=auto -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto'
Dec 28 20:26:33 vml000110 named[2536]: running as: named -f -u named
Dec 28 20:26:33 vml000110 named[2536]: compiled by GCC 15.2.1 20251112
Dec 28 20:26:33 vml000110 named[2536]: compiled with OpenSSL version: OpenSSL 3.6.0 1 Oct 2025
Dec 28 20:26:33 vml000110 named[2536]: linked to OpenSSL version: OpenSSL 3.6.0 1 Oct 2025
Dec 28 20:26:33 vml000110 named[2536]: compiled with libuv version: 1.51.0
Dec 28 20:26:33 vml000110 named[2536]: linked to libuv version: 1.51.0
Dec 28 20:26:33 vml000110 named[2536]: compiled with liburcu version: 0.15.5
Dec 28 20:26:33 vml000110 named[2536]: compiled with jemalloc version: 5.3.0
Dec 28 20:26:33 vml000110 named[2536]: compiled with libnghttp2 version: 1.68.0
Dec 28 20:26:33 vml000110 named[2536]: linked to libnghttp2 version: 1.68.0
Dec 28 20:26:33 vml000110 named[2536]: compiled with libxml2 version: 2.15.1
Dec 28 20:26:33 vml000110 named[2536]: linked to libxml2 version: 21501-GITv2.15.1
Dec 28 20:26:33 vml000110 named[2536]: compiled with json-c version: 0.18
Dec 28 20:26:33 vml000110 named[2536]: linked to json-c version: 0.18
Dec 28 20:26:33 vml000110 named[2536]: compiled with zlib version: 1.3.1
Dec 28 20:26:33 vml000110 named[2536]: linked to zlib version: 1.3.1
Dec 28 20:26:33 vml000110 named[2536]: linked to maxminddb version: 1.12.2
Dec 28 20:26:33 vml000110 named[2536]: ----------------------------------------------------
Dec 28 20:26:33 vml000110 named[2536]: BIND 9 is maintained by Internet Systems Consortium,
Dec 28 20:26:33 vml000110 named[2536]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Dec 28 20:26:33 vml000110 named[2536]: corporation. Support and training for BIND 9 are
Dec 28 20:26:33 vml000110 named[2536]: available at https://www.isc.org/support
Dec 28 20:26:33 vml000110 named[2536]: ----------------------------------------------------
Dec 28 20:26:33 vml000110 named[2536]: adjusted limit on open files from 1024 to 524288
Dec 28 20:26:33 vml000110 named[2536]: found 4 CPUs, using 4 worker threads
Dec 28 20:26:33 vml000110 named[2536]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
Dec 28 20:26:33 vml000110 named[2536]: DS algorithms: SHA-1 SHA-256 SHA-384
Dec 28 20:26:33 vml000110 named[2536]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
Dec 28 20:26:33 vml000110 named[2536]: TKEY mode 2 support (Diffie-Hellman): no
Dec 28 20:26:33 vml000110 named[2536]: TKEY mode 3 support (GSS-API): yes
Dec 28 20:26:33 vml000110 named[2536]: the initial working directory is '/'
Dec 28 20:26:33 vml000110 named[2536]: loading configuration from '/etc/named.conf'
Dec 28 20:26:33 vml000110 named[2536]: the working directory is now '/var/named'
Dec 28 20:26:33 vml000110 named[2536]: using default UDP/IPv4 port range: [32768, 60999]
Dec 28 20:26:33 vml000110 named[2536]: using default UDP/IPv6 port range: [32768, 60999]
Dec 28 20:26:33 vml000110 named[2536]: listening on IPv4 interface lo, 127.0.0.1#53
Dec 28 20:26:33 vml000110 named[2536]: listening on IPv4 interface eth0, 10.0.0.110#53
Dec 28 20:26:33 vml000110 named[2536]: listening on IPv4 interface eth1, 10.0.10.110#53
Dec 28 20:26:33 vml000110 named[2536]: listening on IPv6 interface lo, ::1#53
Dec 28 20:26:33 vml000110 named[2536]: listening on IPv6 interface eth0, 2003:a:e0d:7603:10::110#53
Dec 28 20:26:33 vml000110 named[2536]: listening on IPv6 interface eth1, 2003:a:e0d:7607:10:0:10:110#53
Dec 28 20:26:33 vml000110 named[2536]: generating session key for dynamic DNS
Dec 28 20:26:33 vml000110 named[2536]: using built-in root key for view intern
Dec 28 20:26:33 vml000110 named[2536]: set up managed keys zone for view intern, file '/var/named/dynamic/intern.mkeys'
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 10.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 16.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 17.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 18.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 19.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 20.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 21.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 22.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 23.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 24.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 25.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 26.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 27.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 28.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 29.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 30.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 31.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 168.192.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 64.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 65.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 66.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 67.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 68.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 69.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 70.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 71.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 72.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 73.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 74.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 75.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 76.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 77.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 78.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 79.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 80.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 81.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 82.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 83.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 84.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 85.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 86.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 87.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 88.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 89.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 90.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 91.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 92.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 93.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 94.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 95.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 96.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 97.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 98.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 99.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 100.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 101.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 102.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 103.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 104.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 105.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 106.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 107.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 108.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 109.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 110.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 111.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 112.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 113.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 114.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 115.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 116.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 117.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 118.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 119.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 120.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 121.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 122.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 123.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 124.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 125.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 126.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 127.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 0.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 127.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 254.169.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 2.0.192.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 100.51.198.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 113.0.203.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 255.255.255.255.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 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.0.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: D.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 8.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 9.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: A.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: B.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: 8.B.D.0.1.0.0.2.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: EMPTY.AS112.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: HOME.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view intern: RESOLVER.ARPA
Dec 28 20:26:33 vml000110 named[2536]: using built-in root key for view extern
Dec 28 20:26:33 vml000110 named[2536]: set up managed keys zone for view extern, file '/var/named/dynamic/extern.mkeys'
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 10.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 16.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 17.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 18.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 19.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 20.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 21.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 22.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 23.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 24.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 25.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 26.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 27.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 28.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 29.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 30.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 31.172.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 168.192.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 64.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 65.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 66.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 67.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 68.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 69.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 70.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 71.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 72.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 73.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 74.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 75.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 76.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 77.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 78.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 79.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 80.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 81.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 82.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 83.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 84.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 85.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 86.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 87.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 88.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 89.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 90.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 91.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 92.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 93.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 94.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 95.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 96.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 97.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 98.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 99.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 100.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 101.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 102.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 103.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 104.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 105.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 106.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 107.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 108.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 109.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 110.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 111.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 112.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 113.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 114.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 115.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 116.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 117.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 118.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 119.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 120.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 121.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 122.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 123.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 124.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 125.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 126.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 127.100.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 0.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 127.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 254.169.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 2.0.192.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 100.51.198.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 113.0.203.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 255.255.255.255.IN-ADDR.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 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.0.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: D.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 8.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 9.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: A.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: B.E.F.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: 8.B.D.0.1.0.0.2.IP6.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: EMPTY.AS112.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: HOME.ARPA
Dec 28 20:26:33 vml000110 named[2536]: automatic empty zone: view extern: RESOLVER.ARPA
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.967 general: notice: statistics channel listening on 127.0.0.1#8080
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.967 general: notice: command channel listening on 127.0.0.1#953
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.967 zoneload: info: managed-keys-zone/intern: loaded serial 147
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.967 zoneload: info: managed-keys-zone/extern: loaded serial 145
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.967 zoneload: info: zone 0.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 10.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone edmz.nausch.org/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.10.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: 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/intern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.127.in-addr.arpa/IN/intern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone idmz.nausch.org/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone localhost/IN/intern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone 2.17.172.in-addr.arpa/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone nausch.org/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.970 zoneload: info: zone intra.nausch.org/IN/intern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.127.in-addr.arpa/IN/extern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone nausch.org/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: 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/extern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone idmz.nausch.org/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone localhost/IN/extern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone 2.17.217.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone 131.13.92.217.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone 3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone edmz.nausch.org/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 general: notice: all zones loaded
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 general: notice: FIPS mode is disabled
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 general: notice: running
Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen.
# systemctl status named.service
● named.service - Internet domain name server
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled)
Active:active (running) since Sun 2025-12-28 20:26:33 CET; 1min 2s ago
Invocation: 9d9868c5dfe74ecabdcc8527a7d8713a
Main PID: 2536 (named)
Tasks: 14 (limit: 9501)
Memory: 54.4M (peak: 55.9M)
CPU: 123ms
CGroup: /system.slice/named.service
└─2536 /usr/bin/named -f -u named
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.973 zoneload: info: zone localhost/IN/extern: loaded serial 42
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone 2.17.217.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone 131.13.92.217.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone 3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 zoneload: info: zone edmz.nausch.org/IN/extern: loaded serial 2025122801
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 general: notice: all zones loaded
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 general: notice: FIPS mode is disabled
Dec 28 20:26:33 vml000110 named[2536]: 28-Dec-2025 20:26:33.977 general: notice: running
Alternativ dazu können wir auch einen Blick in die Prozess-Liste werfen um uns zu vergewissern ob der Daemon läuft.
total 12
-rw-r--r-- 1 named named 0 Nov 8 20:26 auth_servers
-rw-r--r-- 1 named named 0 Nov 8 20:26 client_security
-rw-r--r-- 1 named named 0 Nov 8 20:26 ddns
-rw-r--r-- 1 named named 3206 Nov 8 20:26 default
-rw-r--r-- 1 named named 258 Nov 8 20:26 dnssec
-rw-r--r-- 1 named named 0 Nov 8 20:26 dnstap
-rw-r--r-- 1 named named 3464 Nov 8 20:26 named.run
-rw-r--r-- 1 named named 0 Nov 8 20:26 queries
-rw-r--r-- 1 named named 0 Nov 8 20:26 query-errors
-rw-r--r-- 1 named named 0 Nov 8 20:26 rate_limiting
-rw-r--r-- 1 named named 0 Nov 8 20:26 rpz
-rw-r--r-- 1 named named 0 Nov 8 20:26 zone_transfers
In der Datei /var/log/named/default und /var/log/named/named.runfinden wir Informationen zu den geladenen Zonen-Dateien.
28-Dec-2025 20:26:33.967 general: notice: statistics channel listening on 127.0.0.1#8080
28-Dec-2025 20:26:33.967 general: notice: command channel listening on 127.0.0.1#953
28-Dec-2025 20:26:33.967 zoneload: info: managed-keys-zone/intern: loaded serial 147
28-Dec-2025 20:26:33.967 zoneload: info: managed-keys-zone/extern: loaded serial 145
28-Dec-2025 20:26:33.967 zoneload: info: zone 0.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 10.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone edmz.nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.10.in-addr.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: 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/intern: loaded serial 42
28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.127.in-addr.arpa/IN/intern: loaded serial 42
28-Dec-2025 20:26:33.970 zoneload: info: zone idmz.nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone localhost/IN/intern: loaded serial 42
28-Dec-2025 20:26:33.970 zoneload: info: zone 2.17.172.in-addr.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone intra.nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.127.in-addr.arpa/IN/extern: loaded serial 42
28-Dec-2025 20:26:33.973 zoneload: info: zone nausch.org/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: 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/extern: loaded serial 42
28-Dec-2025 20:26:33.973 zoneload: info: zone idmz.nausch.org/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone localhost/IN/extern: loaded serial 42
28-Dec-2025 20:26:33.977 zoneload: info: zone 2.17.217.in-addr.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 zoneload: info: zone 131.13.92.217.in-addr.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 zoneload: info: zone 3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 zoneload: info: zone edmz.nausch.org/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 general: notice: all zones loaded
28-Dec-2025 20:26:33.977 general: notice: FIPS mode is disabled
28-Dec-2025 20:26:33.977 general: notice: running
28-Dec-2025 20:26:33.967 general: notice: statistics channel listening on 127.0.0.1#8080
28-Dec-2025 20:26:33.967 general: notice: command channel listening on 127.0.0.1#953
28-Dec-2025 20:26:33.967 zoneload: info: managed-keys-zone/intern: loaded serial 147
28-Dec-2025 20:26:33.967 zoneload: info: managed-keys-zone/extern: loaded serial 145
28-Dec-2025 20:26:33.967 zoneload: info: zone 0.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 10.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone edmz.nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.10.in-addr.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: 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/intern: loaded serial 42
28-Dec-2025 20:26:33.970 zoneload: info: zone 0.0.127.in-addr.arpa/IN/intern: loaded serial 42
28-Dec-2025 20:26:33.970 zoneload: info: zone idmz.nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone localhost/IN/intern: loaded serial 42
28-Dec-2025 20:26:33.970 zoneload: info: zone 2.17.172.in-addr.arpa/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.970 zoneload: info: zone intra.nausch.org/IN/intern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.127.in-addr.arpa/IN/extern: loaded serial 42
28-Dec-2025 20:26:33.973 zoneload: info: zone nausch.org/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: 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/extern: loaded serial 42
28-Dec-2025 20:26:33.973 zoneload: info: zone idmz.nausch.org/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.973 zoneload: info: zone localhost/IN/extern: loaded serial 42
28-Dec-2025 20:26:33.977 zoneload: info: zone 2.17.217.in-addr.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 zoneload: info: zone 131.13.92.217.in-addr.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 zoneload: info: zone 3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 zoneload: info: zone edmz.nausch.org/IN/extern: loaded serial 2025122801
28-Dec-2025 20:26:33.977 general: notice: all zones loaded
28-Dec-2025 20:26:33.977 general: notice: FIPS mode is disabled
28-Dec-2025 20:26:33.977 general: notice: running
DNS Abfragen
Nun können wir auch die ersten DNS-Abfragen an unseren BIND9 richten. Rufen wir uns hierzu am besten nochmals die Eingangs angestellten Überlegungen in Erinnerung, die wir im Abschnitt Herausforderungen / Aufgabenstellung angestellt hatten:
In unserer SOHO/HomeLAB Umgebung haben wir ein folgende Zonen, für die wir eine Namensauflösung haben:
extern (Internet), Domainspezifisch:
nausch.org mit jeweils öffentlichen IP-Adressen (IPv4 und IPv6)
und ggf. weitere Domains
intern:
EDMZ mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
IDMZ mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
INTRA mit privaten Adressen aus dem IPv4- und IPv6-Bereichen
In unserer Umgebung wollen wir später dafür sorgen, dass je nachdem aus welcher Zone eine Anfrage kommt unterschiedliche Adressen genannt bekommen bzw. unter Umständen einzelne Netzbereich gar ausblenden. Werfen wir kurz einen Blick auf unsere Beispielumgebung:
Wie wir auf dem Schaubild sehen, sollen bestimmte Adressen, je nachdem von welcher Stelle aus diese abgefragt werden, keine Antwort liefern. So können aus dem Internet lediglich offizielle Adressen erfragt werden, nicht jedoch für Interne Adresse aus den beiden Zonen idmz und intra sowie
Anfragen aus der Zone edmz für Adressen aus der Zone intra sollen eben sowenig abfragbar sein. Nur Anfragen aus den beiden Sicherheitszonen idmz und intra sollen für alle Zonen entsprechende Antworten bekommen!
Ferner sollen Anfragen aus den beiden Schutzzonen intra und idmz, welche die offiziellen Domain nausch.org betreffen, als Antwort die „internen“ ULA aus der Zone IDMZ beinhalten, nicht aber die offiziellen GUA-Adressen!
Wir benötigen also einen primary DNS-Server, der als interner DNS-Server für ein privates Netzwerk mit den obigen Zonen agiert. Zusätzlich wollen wir auch noch definieren, wer bei einer Anfrage welche Adresse genannt bekommt. Hierzu werden wir views nutzen, die abhängig von der Stelle aus unserem Netzwerk von dem der Client eine Anfrage startet die passende IP-Adresse genannt bekommt. Ein Client von außen soll also zum Beispiel nach der Frage wie denn die AAAA Adresse von mx1.nausch.org lautet, als Antwort die Adresse 2003:a:e0d:7603:10:0:0:25 bekommen. Ein Client von Intern hingegen soll bei der gleichen Frage aber die Antwort fd00::3:10:0:0:25 bekommen. Realisieren werden wir das wie schon angeschnitten mit unterschiedlichen views für intern und extern.
lokale Abfrage nach einem AAAA-Adresse
Im ersten Beispiel fragen wir den named auf dem IDMZ-Host vml010110, also auf dem Host auf dem der named selbst läuft:
# dig @::1 AAAA imap.idmz.nausch.org
; <<>> DiG 9.20.17 <<>> @::1 AAAA imap.idmz.nausch.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40417
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0b05dab57c378407010000006951873afa0f20e982a33d6d (good)
;; QUESTION SECTION:
;imap.idmz.nausch.org. IN AAAA
;; ANSWER SECTION:
imap.idmz.nausch.org. 7200 IN CNAME vml000070.idmz.nausch.org.
vml000070.idmz.nausch.org. 7200 IN AAAA fd00::3:10:0:0:70
;; AUTHORITY SECTION:
idmz.nausch.org. 7200 IN NS ns1.idmz.nausch.org.
;; ADDITIONAL SECTION:
ns1.idmz.nausch.org. 7200 IN AAAA fd00::3:10:0:0:110
ns1.idmz.nausch.org. 7200 IN A 10.0.0.110
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Dec 28 20:38:34 CET 2025
;; MSG SIZE rcvd: 191
Im Response Header unserer DNS-Anfrage via dig sehen wir mehrere Flags, diese haben folgende Bedeutung:
qr (Query Response): Dieses Bit wird gesetzt, wenn das Paket eine Abfrageantwort ist.
aa (Authoritative Answer): Die Antwort ist autoritativ, d.h. sie stammt von einem der autoritativen Nameserver für die Domain. Sie stammt nicht von einem Resolver oder DNS-Cache. Dieses Flag sollte nur angezeigt werden, wenn wir einen autoritativen Nameserver direkt mit @nameserver abfragen.
rd (Recursion Desired): Die Abfrage wurde mit der Anforderung einer Rekursion gesendet; dies ist das Standardverhalten für dig und macht in den meisten Fällen keinen Unterschied. Wenn der Client (dig) eine Rekursion anfordert und von einem Server beantwortet wird, der diese nicht anbietet, wird kein ra-Flag angezeigt. Wir können das Senden von rd mit dem +norecurse-Flag überschreiben und kann so beim Debuggen bestimmter CNAME-Ketten helfen.
cd (Checking Disabled): Die DNSSEC-signierten Antworten werden nicht auf Gültigkeit überprüft.
ad (Authenticated Data): Eine Zone ist DNSSEC-signiert und alle RRs, die für die Abfrage relevant sind, wurden validiert.
tc (Truncated): Dies signalisiert dem Client, den Versuch über TCP zu wiederholen.
Interessiert uns nur das Ergebnis verwenden wir zusätzlich die Option +short
# dig @::1 AAAA imap.idmz.nausch.org +short
vml000070.idmz.nausch.org.
fd00::3:10:0:0:70
lokale Abfrage nach einem MX-Adresse
Grundsätzlich können wir alle Records mit Angabe des Typs via DNS anfragen. Mit Angabe des Typ MX können wir nachfragen, wer denn der zuständige Mailserver zur Annahme von eMails für einen Host oder eine Domain ist. Nachfolgend fragen wir nach, wer denn der zuständige Mailserver für die Subdomain idmz.nausch.org ist.
# dig @::1 MX idmz.nausch.org +short
10 mx1.idmz.nausch.org.
Damit nun ein Client eine eMail auch dort einkippen kann, benötigt er noch die zugehörige IP-Adresse zum Hostnamen mx1.idmz.nausch.org, den dieser nun in einer weiteren DNS-Anfrage ermitteln muß, je nachdem welchen Adresse er benötigt entweder die A bzw die AAAA:
# dig @::1 A mx1.idmz.nausch.org +short
10.0.0.80
bzw.
# dig AAAA mx1.idmz.nausch.org. +short
fd00::3:10:0:0:80
Abfragen aus dem Netz-Segment EDMZ - view "extern"
Gemäß unserer Vorüberlegungen zu den Zonen und Views überprüfen wir nun, ob ein Client aus der Schutzzone EDMZ nur die entsprechend in den Vorüberlegungen zu den Herausforderungen / Aufgabenstellung gewünschten Ergebnisse kommen:
Bei der Frage nach der IPv6-Adresse des Hosts imap.idmz.nausch.org wird uns dessen CNAME und die zugehörige ULA ausgegeben, nicht aber seine global gültige GUA.
IPv6-Reverseauflösung eines Hosts aus der Schutzzone IDMZ
Wir bekommen bei der Frage nach der IPv4- oder auch der IPv6-Adresse keine Antwort, da in der view diese Adressen exkludiert wurden!
Alle Abfragen wurden also gemäß unserer Vorüberlegungen richtig beantwortet. Unsere view extern paßt also soweit!
Abfragen aus dem Netz-Segment INTRA - view "intern"
Gemäß unserer Vorüberlegungen zu den Zonen und Views überprüfen wir nun, ob ein Client aus der Schutzzone EDMZ nur die entsprechend in den Vorüberlegungen zu den Herausforderungen / Aufgabenstellung gewünschten Ergebnisse kommen:
AAAA-Record eines EDMZ-Hosts aus dem Netzsegment EDMZ
# dig @10.0.0.110 +short AAAA fwb.edmz.nausch.org
vml000210.edmz.nausch.org.
fd00::172:17:2:210
Es wird der CNAME = vml000210.edmz.nausch.org und die zugehörige ULA-Adresse fd00::172:17:2:210 des Hosts vml000210.edmz.nausch.org präsentiert, nicht aber seine global gültige GUA.
A-Record eines Hosts aus dem Netzsegment EDMZ
# dig @10.0.0.110 +short A vml000210.edmz.nausch.org
172.17.2.210
Es wird nur die IPv4-Adresse 172.17.2.210 des Hosts vml000210.edmz.nausch.org ausgegeben.
Reverseauflösung eines Hosts aus der Schutzzone IDMZ
# dig @10.0.0.110 +short A nitro-pc.intra.nausch.org
pml010070.intra.nausch.org
10.0.10.70
Im Gegensatz zu der Abfrage aus der Schutzzone extern erhalten wir nunmehr ein Antwort auf die Frage nach der IPv4|6-Adresse aus dem Netzsegment internal.
IPv4|6-Auflösung eines Hosts aus dem Internet
# dig +short AAAA vml000210.edmz.nausch.org
2003:a:e0d:7600:1720:17:2:210
# dig +short A dokuwiki.nausch.org
217.92.13.131
Im Gegensatz zu der Abfrage aus der Schutzzone edmz erhalten wir nunmehr ein Antwort mit demn offiziellen IPv4 und IPv6-Adressen.
Alle Abfragen wurden also gemäß unserer Vorüberlegungen richtig beantwortet. Unser Nameserver antwortet also entsprechend unserer Vorgaben.
Pflege einer Zone
Im Laufe eines Betriebes kommt es gewöhnlich ab und an vor, dass sich Adressen ändern, bzw. Hosts dazukommen oder auch wieder abgebaut werden. Wir schauen uns nun den Fall an, dass ein neuer Client in unserem Netzwerk neu eingebracht werden soll:
Nodename: pnc010023
Alias: apc-usv
IPv4: 10.0.10.23
IPv6: fd00:0:0:7:10:0:10:23
Dazu erweitern wir unsere bereits bestehenden Zonendateien:
i.intra.nausch.org.db für die forward-Auflösungen für IPv4 und IPv6
i.intra.nausch.org.in-addr.db für die IPv4 reverse-Auflösung und
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (2025122802 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
pnc010023 IN A 10.0.10.23
IN AAAA fd00::7:10:0:10:23
apc-usv IN CNAME pnc010023
pml010070 IN A 10.0.10.70
IN AAAA fd00::7:10:0:10:70
nitro-pc IN CNAME pml010070
vml010110 IN A 10.0.10.110
IN AAAA fd00::7:10:0:10:110
fwc IN CNAME vml010110
# vim /var/named/zones/i.intra.nausch.org.in-addr.db
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (2025122802 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
23 IN PTR pnc010023.intra.nausch.org.
IN PTR apc-usv.intra.nausch.org
70 IN PTR pml000070.intra.nausch.org.
IN PTR nitro-pc.intra.nausch.org.
110 IN PTR vml000110.intra.nausch.org.
IN PTR fwc.intra.nausch.org.
$TTL 2H ; Defaultwert für die TTL
@ IN SOA ns1 hostmaster.nausch.org. (2025122802 ; serial - Seriennummer im Format YYYYMMDDnn
1h ; refresh (1 Stunde)
15m ; retry (15 Minuten)
2W ; expire (2 Wochen)
10m ) ; negative caching TTL (10 Minuten)
IN NS ns1
IN MX 10 mx1
ns1 IN A 10.0.10.110
mx1 IN A 10.0.10.110
$ORIGIN 0.1.0.0.0.0.0.0.0.1.0.0
3.2.0.0 IN PTR pnc010023.intra.nausch.org.
IN PTR apc-usv.intra.nausch.org.
0.7.0.0 IN PTR pml000070.intra.nausch.org.
IN PTR nitro-pc.intra.nausch.org.
0.1.1.0 IN PTR vml000110.intra.nausch.org.
IN PTR fwc.intra.nausch.org.
WICHTIG:
Bei Änderungen an den Zonen-Dateien ist es zwingend notwendig die Seriennummer (im Format YYYYMMDDnn anzupassen bzw. hochzuzählen, da sonst unser bind9 das Neuladen der veränderten Zonen-Dateien mit Hilfe von rndc reload wie im nachfolgenden Beispiel verweigern und dies im Journal entsprechend dokumentieren würde!
Dec 28 22:12:25 vml000110 named[2981]: 28-Dec-2025 22:12:20.250 zoneload: error: zone intra.nausch.org/IN/intern: zone serial (2025122801) unchanged. zone may fail to transfer to secondaries.
Klar man könnte den named auch neu starten und so das Laden aller Zonen-Dateien, unabhängig davon ob diese verändert wurden oder nicht, erzwingen. Nur würden dabei auch alle gecachten (externen) Ziele verworfen werden und in aller Regel ist das bei höher frequentierten bind alles andere als gewünscht!
Bevor wir jedoch unsere geänderten Zone-Files neu laden checken wir diese auf syntaktische Fehler!
dns_rdata_fromtext: /var/named/zones/i.intra.nausch.org.db:2: near '20251228022': out of range
zone intra.nausch.org/IN: loading from master file /var/named/zones/i.intra.nausch.org.db failed: out of range
zone intra.nausch.org/IN: not loaded due to errors.
Hoppala, da hat sich doch glett ein Fehler eingeschlichen. Statt 2025122802 hatten wir 20251228022 eingegeben, also eine Stelle zu viel. Wir korrigieren also die Seriennummer und prüfen erneut:
DNS-Anfragen auf Port 53, egal ob nun via TCP oder UDP übertragen, können grundsätzlich von einem Angreifer z.B. durch DNS-Spoofing oder Cache Poisoning manipuliert werden, da diese ungesichert übertragen werden. Ziel ist jeweils dabei, daß bei einer Abfrage eine falsche IP-Adresse übermittelt wird, um den Nutzer auf eine manipulierte Website zu leiten. Es wäre als möglich, daß bei der DNS-Anfrage für die Adresse der Hausbank, ein Angreifer die Adresse einer Phising-Seite uns unterjubelt. Jetzt könnte man einwenden: „Ja, warum verschlüsseln wir den Transportkanal nicht einfach?“ Nun, wir wüsten dann zwar, daß wir die DNS-Kommunikation zwar verschlüsselt haben, aber viel wichtiger wäre doch, daß wir uns sicher sein können, daß unsere Antwort entsprechend valide ist und hier bietet sich die DNSSEC-Unterstützung des ISC (Internet System Consortium) an.
DNSSEC wurde im RFC 9364 diskutiert und definiert. DNSSEC fügt eine Schicht digitaler Signaturen hinzu, die sicherstellt, dass die DNS-Antworten, die man erhält, authentisch sind und nicht manipuliert wurden. DNSSEC steht für Domain Name System Security Extensions mit dem das herkömmlichen Domain Name Systems (DNS) erweitert wurde.
Die Erweiterung DNSSEC wurde als Sicherheitsmechanismus eingeführt, um die Echtheit (Authentizität) und die Vollständigkeit (Integrität) der Daten von DNS-Antworten sicherzustellen, so daß diese nicht unerkannt manipuliert werden können.
Folgende Vorteile versprechen wir uns nun beim Einsatz von DNSSEC:
Sicherheit: Durch die Nutzung digitaler Signaturen schützt DNSSEC vor Manipulationen und stellt so die Authentizität der DNS-Antworten sicher.
Vertrauenswürdigkeit: DNSSEC kann das Vertrauen der Nutzer bei der Kommunikation im Internet erhöhen, da es hilft sicherzustellen, das die Adressen, die per DNS-Anfragen ermittelt wurden, echt sind.
Privatsphäre: DNSSEC hilft die Privatsphäre zu schützen indem es die Möglichkeit von Man-in-the-Middle-Angriffen verringert.
Doch wie läuft nun das Signieren und Validieren der DNS-Antworten ab? Wie wir schon eingangs festgehalten haben, hilft DNSSEC die Authentizität und Integrität von DNS-Antworten zu gewährleisten. Hierzu signiert der zuständige DNS-Server die Antworten die er verschickt mit einer digitalen Signatur, welche er dann mit den DNS-Antwortdaten verschickt.
Dem ganzen Signaturprozess liegen folgende Dinge zu Grunde:
Schlüsselerstellung: Zunächst werden zwei Schlüsselpaare benötigt, die erzeugt werden müssen und zwar den ZSK (Zone Signing Key) und den KSK (Key Signing Key). Der längere KSK Schlüssel hat dabei i.D.R. eine lange Lebensdauer, der kürzere ZSK hingegen eine kürzere Lifetime. Der ZSK, welcher durch den KSK signiert wurde, wird für das Signieren der DNS-Einträge verwendet. Der KSK hat eine höhere Sicherheitsstufe und wird ausschließlich verwendet um den ZSK zu signieren. Dies stellt sicher, das selbst bei einer Kompromittierung des ZSK der KSK sicher bleibt, vorausgesetzt dieser wird sicher außerhalb des direkt zugänglichen Systems gespeichert!
Alternativ zu den beiden Schlüssel (ZSK und KSK) kann auch ein sogenannter Combined Signing Key (CSK) zur Anwendung kommen. Bind bringt seit Version 9.16 eine eingebaute policydefault mit und verwendet einen einzelnen ECDSAP256SHA-Schlüssel (kombinierter Signaturschlüssel (CSK), der sowohl die Aufgaben eines KSK als auch eines ZSK erfüllt, auch bekannt als Single Type Signing Scheme.
Signatur: Bevor der DNS-Server seine Antwort verschickt signiert er diese Daten mit dem privaten Schlüssel des ZSK. In der Antwort an den anfragenden Client befinden sich dann die Antwortdaten zusammen mit der erzeugten Signatur und auch dem public key des ZSK.
Validierung auf Clientseite: Der empfangende DNS-Resolver, meist ist dies der DNS-Server des Internetanbieters oder ein spezialisierter DNSSEC-Resolver wie unbound nutzt dann den public key des ZSK für die Überprüfung der Authentizität und Integrität der Antwort. Sofern diese Prüfung erfolgreich abgeschlossen wurde, kann der Resolver und somit auch der Nutzer sicher sein, daß die Antwort echt ist und nicht manipuliert wurde. Die Installation und Konfiguration von unbound werden wir uns noch in einem eigenen Artikel hier noch im Detail ansehen.
Schlüsselverzeichnis anlegen
Für die Ablage und Bevorratung des automatisch generierten KSK und ZSK Schlüsselmaterials legen wir uns nun noch ein entsprechendes (Unter-)Verzeichnis an.
# mkdir /var/named/keys
Hier passen wir noch die Berechtigung des gerade angelegten Verzeichnisses an.
# chmod 770 /var/named/keys
Zu guter Letzt korrigieren wir noch die User- und Gruppenberechtigungen unseres neuen Unterverzeichnisses für die Zonen-Dateien.
// Das Verzeichnis, in dem sich die öffentlichen und privaten
// DNSSEC-Schlüsseldateien befinden sollen.
key-directory "/var/named";
Diesen passen wir nun an und hinterlegen hier das neu angelegte Unterverzeichnis /var/named/keys für die Schlüssel.
# vim /etc/named.conf
// Das Verzeichnis, in dem sich die öffentlichen und privaten
// DNSSEC-Schlüsseldateien befinden sollen.
key-directory "/var/named/keys";
Mit BIND 9.16 wurde eine neue Methode zur Aufrechterhaltung von DNSSEC bei den Zonen eingeführt. Zusätzlich zu den Konfigurationsoptionen inline-signing und auto-dnssec gibt es jetzt dnssec-policy.
Wichtig: auto-dnssec wurde seit der Entwicklungsversion 9.19.16 und seit der Version 9.20.0 entfernt! auto-dnssec wurde somit durch dnssec-policy ersetzt!
Mit Hilfe der dnssec-policy können wir nun eine Schlüssel- und Signaturrichtlinie (KASP) angeben und so auf einfache Art und Weise alle KASP-bezogenen Konfigurationen zusammenfassen. Die Aktivierung von DNSSEC für unsere Zonen ist somit intuitiver als bei früheren BIND-Versionen! Dank der dnssec-policy brauchen wir nicht mehr manuell wie in früheren Versionen für jede Zone zwei Schlüsselpaare generieren und zwar den ZSK (Zone Signing Key) und den KSK (Key Signing Key). Alternativ zu den beiden Schlüssel (ZSK und KSK) kann auch ein sogenannter Combined Signing Key (CSK) zur Anwendung kommen, der dann zur Weitergabe als DS-Record und zum Signieren der DNS-Antworten herangezogen wird. Bind bringt seit Version 9.16 eine eingebaute policy default mit und verwendet einen einzelnen ECDSAP256SHA-Schlüssel (kombinierter Signaturschlüssel (CSK), der sowohl die Aufgaben eines KSK als auch eines ZSK erfüllt, auch bekannt als Single Type Signing Scheme.
Sofern der CSK der jeweils übergeordneten Domain zur Verfügung gestellt wird, können damit nunmehr alle Schlüssel der eigenen Zone signiert und genutzt werden. Alle weiteren Daten aus der Zone werden ebenso mit diesem CSK signiert. Sofern unser named vollständig für alle Zonen DNSsec enabled wird, wird dieser auch nur noch entsprechend signierte Antworten liefern.
Die policy default ist hier eine integrierte Richtlinie (policy). Dadurch wird wie beschrieben jeweils ein einzelner ECDSAP256SHA-Schlüssel und zugehörige Signaturen für die betreffende Zonen eingeführt; dabei wird zur NSEC zur Denial-of-Existence-Funktion verwendet. NSEC ist in RFC 5155 definiert worden. Mit den Domain Name System Security (DNSSEC)-Erweiterungen wurde der NSEC-Ressourceneintrag (RR) für die authentifizierte Denial-of-Existence-Funktion eingeführt. Wollen wir NSEC3, welches ebenso wie NSEC im RFC 5155 definiert wurde, zur Denial-of-Existence-Funktion zur Konfiguration von nicht existierenden DNS-Einträgen verwendend, legen wir uns eine eigene policy an. Weitere Informationen rund um Proof of Non-Existence mit Hilfe von NSEC und NSEC3 finden sich in der entsprechenden Original-Dokumentation.
Wir erweitern also wie in der ISC Dokumentation beschrieben unsere Konfigurationsdatei /etc/named.conf und legen uns dort eine eigne separate policy an.
# vim /etc/named.conf
Bis jetzt sah die Definition der Domain intra.nausch.org in unserem Konfigurationsbeispiel wie folgt aus.
// View: intern - Zone: intra.nausch.org (forward)
zone "intra.nausch.org" IN {
type master;
file "zones/intra.nausch.org.db";
};
Diese Definitionen bei den einzelnen Zone-Definitions erweitern wir nun noch durch die Option dnssec-policy "ownway", deren Policy wir zuvor angelegt hatten.
Beispiel:
# vim /etc/named.conf
// View: intern - Zone: intra.nausch.org (forward)
zone "intra.nausch.org" IN {
type master;
file "zones/intra.nausch.org.db";
dnssec-policy "ownway"
};
Mit Hilfe unserer eigenen policy ownway wird nun nur ein einzelner ECDSAP256SHA-Schlüssel und zugehörige Signaturen für die betreffende Zone intra.nausch.org eingeführt; dabei wird zur NSEC3 zur Denial-of-Existence-Funktion verwendet. NSEC3 ist in RFC 5155 definiert worden. Mit den Domain Name System Security (DNSSEC)-Erweiterungen wurde der NSEC3-Ressourceneintrag (RR) für die authentifizierte Denial-of-Existence-Funktion eingeführt.
Die nachfolgenden Zeilen fügen wir zwischen der Definition der statistic-channels und der view-Definitionen ein:
# vim /etc/named.conf
// ************** Definition einer eigenen policy für DNSSEC **************
dnssec-policy "ownway" {
keys {
// Combined Signing Key CSK lifetime und Key Algorithmus
// Definition des standardmäßigen Speicherorts der automatisch generierten
// Schlüsseldateien. Ferner kann die lifetime angegeben sowie der zu ver-
// wendendeten Algorithus angegeben werden.
csk key-directory lifetime unlimited algorithm ecdsa256;
};
// Gibt an, ob BIND 9 eine separate signierte Version einer Zone verwaltet.
// Die Verwendung von Inline-Signing wird durch die dnssec-policy für die
// Zone bestimmt. Wenn Inline-Signing in Zone explizit auf yes oder no
// gesetzt wird, überschreibt dies jeden Wert von dnssec-policy.
inline-signing yes;
// Proof of Non-Existence mit Hilfe von NSEC3
// Alles nach nsec3param ist optional. Werden diese nicht explizit defi-
// niert, verwendet BIND 9 Standardwerte. Will man jedoch sicherstellen
// dass die Parameter mit entsprechend vorgegebenen bzw. vorhandenen
// NSEC3-Parametern übereinstimmen, sind diese explizit festzulegen.
// Zu beachten ist, dass man kein bestimmtes Salt defionieren kann. sofern
// ein vorhandene Salt jedoch dieselbe Länge wie salt-length hat, ent-
// spricht es der Richtlinie und es erfolgt kein erneutes Salting.
nsec3param iterations 0 optout no salt-length 0;
// Schlüssel-Timing-Informationen
// Zu beachten ist, dass dnssec-policy zwar Schlüssel-Timing-Informationen
// festlegt, aber eine eigene state-machine verwendet, um zu bestimmen,
// welche Aktionen ausgeführt werden sollen.
dnskey-ttl PT1H;
publish-safety PT1H;
retire-safety PT1H;
purge-keys P90D;
// Signature-Timing-Informationen
signatures-refresh P5D;
signatures-validity P14D;
signatures-validity-dnskey P14D;
// Zonen Parameter
max-zone-ttl P1D;
zone-propagation-delay PT5M;
parent-ds-ttl P1D;
parent-propagation-delay PT1H;
};
Bevor wir unseren gerade konfigurierten Änderungen durch einen Neustart des named aktivieren führen wir mit Hilfe des Programms named-checkconf noch einen Check auf Syntaxfehler durch und lassen uns mit der Option -l werden alle konfigurierten Zonen aufgelisten. Jede Ausgabezeile enthält den Zonennamen, die Klasse (z. B. IN), die Ansicht und den Typ (z. B. primär oder sekundär). Mit der Option -z erfolgt eine Lade-Test aller Zonen vom Typ „primary“, die in Konfigurationsdatei /etc/named.conf gefunden wurden.
localhost IN intern master
0.0.127.in-addr.arpa IN intern master
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 intern master
. IN intern hint
intra.nausch.org IN intern master
10.0.10.in-addr.arpa IN intern master
7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN intern master
idmz.nausch.org IN intern master
0.0.10.in-addr.arpa IN intern master
3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN intern master
edmz.nausch.org IN intern master
2.17.172.in-addr.arpa IN intern master
0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN intern master
nausch.org IN intern master
localhost IN extern master
0.0.127.in-addr.arpa IN extern master
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 extern master
. IN extern hint
idmz.nausch.org IN extern master
0.0.10.in-addr.arpa IN extern master
3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN extern master
edmz.nausch.org IN extern master
2.17.217.in-addr.arpa IN extern master
0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa IN extern master
nausch.org IN extern master
131.13.92.217.in-addr.arpa IN extern master
3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa IN extern master
Aktivierung des Änderungen
Nun aktivieren wir unsere Konfigurationsänderungen rund um DNSSEC und den Combined Signing Keys CSK durch einen Neustart des named.
# systemctl restart named.service
Im Journal wird der erfolgreiche Neustart entsprechend protokolliert.
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.079 network: info: no longer listening on 127.0.0.1#53
Dec 29 17:56:42 vml000110 systemd[1]: Stopping Internet domain name server...
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.079 network: info: no longer listening on 10.0.0.110#53
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 network: info: no longer listening on 10.0.10.110#53
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 network: info: no longer listening on ::1#53
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 network: info: no longer listening on 2003:a:e0d:7603:10::110#53
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 network: info: no longer listening on 2003:a:e0d:7607:10:0:10:110#53
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 general: notice: stopping command channel on 127.0.0.1#953
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 general: notice: stopping statistics channel on 127.0.0.1#8080
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.083 general: info: shutting down
Dec 29 17:56:42 vml000110 named[603]: 29-Dec-2025 17:56:42.106 general: notice: exiting
Dec 29 17:56:42 vml000110 systemd[1]: named.service: Deactivated successfully.
Dec 29 17:56:42 vml000110 systemd[1]: Stopped Internet domain name server.
Dec 29 17:56:42 vml000110 systemd[1]: named.service: Consumed 297ms CPU time over 5h 2min 54.223s wall clock time, 81.9M memory peak.
Dec 29 17:56:42 vml000110 systemd[1]: Started Internet domain name server.
Dec 29 17:56:42 vml000110 named[4176]: starting BIND 9.20.17 (Stable Release) <id:00545e4>
Dec 29 17:56:42 vml000110 named[4176]: running on Linux x86_64 6.12.63-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 18 Dec 2025 14:48:15 +0000
Dec 29 17:56:42 vml000110 named[4176]: built with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/bind/src=/usr/src/debug/bind -flto=auto -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto'
Dec 29 17:56:42 vml000110 named[4176]: running as: named -f -u named
Dec 29 17:56:42 vml000110 named[4176]: compiled by GCC 15.2.1 20251112
Dec 29 17:56:42 vml000110 named[4176]: compiled with OpenSSL version: OpenSSL 3.6.0 1 Oct 2025
Dec 29 17:56:42 vml000110 named[4176]: linked to OpenSSL version: OpenSSL 3.6.0 1 Oct 2025
Dec 29 17:56:42 vml000110 named[4176]: compiled with libuv version: 1.51.0
Dec 29 17:56:42 vml000110 named[4176]: linked to libuv version: 1.51.0
Dec 29 17:56:42 vml000110 named[4176]: compiled with liburcu version: 0.15.5
Dec 29 17:56:42 vml000110 named[4176]: compiled with jemalloc version: 5.3.0
Dec 29 17:56:42 vml000110 named[4176]: compiled with libnghttp2 version: 1.68.0
Dec 29 17:56:42 vml000110 named[4176]: linked to libnghttp2 version: 1.68.0
Dec 29 17:56:42 vml000110 named[4176]: compiled with libxml2 version: 2.15.1
Dec 29 17:56:42 vml000110 named[4176]: linked to libxml2 version: 21501-GITv2.15.1
Dec 29 17:56:42 vml000110 named[4176]: compiled with json-c version: 0.18
Dec 29 17:56:42 vml000110 named[4176]: linked to json-c version: 0.18
Dec 29 17:56:42 vml000110 named[4176]: compiled with zlib version: 1.3.1
Dec 29 17:56:42 vml000110 named[4176]: linked to zlib version: 1.3.1
Dec 29 17:56:42 vml000110 named[4176]: linked to maxminddb version: 1.12.2
Dec 29 17:56:42 vml000110 named[4176]: ----------------------------------------------------
Dec 29 17:56:42 vml000110 named[4176]: BIND 9 is maintained by Internet Systems Consortium,
Dec 29 17:56:42 vml000110 named[4176]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Dec 29 17:56:42 vml000110 named[4176]: corporation. Support and training for BIND 9 are
Dec 29 17:56:42 vml000110 named[4176]: available at https://www.isc.org/support
Dec 29 17:56:42 vml000110 named[4176]: ----------------------------------------------------
Dec 29 17:56:42 vml000110 named[4176]: adjusted limit on open files from 1024 to 524288
Dec 29 17:56:42 vml000110 named[4176]: found 4 CPUs, using 4 worker threads
Dec 29 17:56:42 vml000110 named[4176]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
Dec 29 17:56:42 vml000110 named[4176]: DS algorithms: SHA-1 SHA-256 SHA-384
Dec 29 17:56:42 vml000110 named[4176]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
Dec 29 17:56:42 vml000110 named[4176]: TKEY mode 2 support (Diffie-Hellman): no
Dec 29 17:56:42 vml000110 named[4176]: TKEY mode 3 support (GSS-API): yes
Dec 29 17:56:42 vml000110 named[4176]: the initial working directory is '/'
Dec 29 17:56:42 vml000110 named[4176]: loading configuration from '/etc/named.conf'
Dec 29 17:56:42 vml000110 named[4176]: the working directory is now '/var/named'
Dec 29 17:56:42 vml000110 named[4176]: using default UDP/IPv4 port range: [32768, 60999]
Dec 29 17:56:42 vml000110 named[4176]: using default UDP/IPv6 port range: [32768, 60999]
Dec 29 17:56:42 vml000110 named[4176]: listening on IPv4 interface lo, 127.0.0.1#53
Dec 29 17:56:42 vml000110 named[4176]: listening on IPv4 interface eth0, 10.0.0.110#53
Dec 29 17:56:42 vml000110 named[4176]: listening on IPv4 interface eth1, 10.0.10.110#53
Dec 29 17:56:42 vml000110 named[4176]: listening on IPv6 interface lo, ::1#53
Dec 29 17:56:42 vml000110 named[4176]: listening on IPv6 interface eth0, 2003:a:e0d:7603:10::110#53
Dec 29 17:56:42 vml000110 named[4176]: listening on IPv6 interface eth1, 2003:a:e0d:7607:10:0:10:110#53
Dec 29 17:56:42 vml000110 named[4176]: generating session key for dynamic DNS
Dec 29 17:56:42 vml000110 named[4176]: using built-in root key for view intern
Dec 29 17:56:42 vml000110 named[4176]: set up managed keys zone for view intern, file '/var/named/dynamic/intern.mkeys'
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 10.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 16.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 17.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 18.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 19.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 20.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 21.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 22.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 23.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 24.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 25.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 26.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 27.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 28.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 29.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 30.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 31.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 168.192.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 64.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 65.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 66.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 67.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 68.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 69.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 70.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 71.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 72.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 73.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 74.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 75.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 76.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 77.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 78.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 79.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 80.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 81.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 82.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 83.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 84.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 85.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 86.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 87.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 88.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 89.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 90.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 91.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 92.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 93.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 94.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 95.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 96.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 97.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 98.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 99.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 100.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 101.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 102.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 103.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 104.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 105.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 106.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 107.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 108.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 109.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 110.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 111.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 112.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 113.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 114.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 115.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 116.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 117.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 118.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 119.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 120.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 121.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 122.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 123.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 124.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 125.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 126.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 127.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 0.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 127.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 254.169.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 2.0.192.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 100.51.198.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 113.0.203.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 255.255.255.255.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 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.0.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: D.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 8.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 9.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: A.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: B.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: 8.B.D.0.1.0.0.2.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: EMPTY.AS112.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: HOME.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view intern: RESOLVER.ARPA
Dec 29 17:56:42 vml000110 named[4176]: using built-in root key for view extern
Dec 29 17:56:42 vml000110 named[4176]: set up managed keys zone for view extern, file '/var/named/dynamic/extern.mkeys'
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 10.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 16.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 17.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 18.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 19.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 20.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 21.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 22.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 23.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 24.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 25.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 26.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 27.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 28.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 29.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 30.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 31.172.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 168.192.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 64.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 65.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 66.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 67.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 68.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 69.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 70.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 71.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 72.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 73.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 74.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 75.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 76.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 77.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 78.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 79.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 80.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 81.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 82.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 83.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 84.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 85.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 86.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 87.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 88.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 89.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 90.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 91.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 92.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 93.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 94.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 95.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 96.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 97.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 98.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 99.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 100.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 101.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 102.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 103.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 104.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 105.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 106.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 107.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 108.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 109.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 110.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 111.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 112.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 113.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 114.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 115.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 116.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 117.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 118.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 119.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 120.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 121.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 122.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 123.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 124.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 125.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 126.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 127.100.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 0.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 127.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 254.169.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 2.0.192.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 100.51.198.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 113.0.203.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 255.255.255.255.IN-ADDR.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 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.0.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: D.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 8.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 9.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: A.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: B.E.F.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: 8.B.D.0.1.0.0.2.IP6.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: EMPTY.AS112.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: HOME.ARPA
Dec 29 17:56:42 vml000110 named[4176]: automatic empty zone: view extern: RESOLVER.ARPA
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.283 general: notice: statistics channel listening on 127.0.0.1#8080
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.283 general: notice: command channel listening on 127.0.0.1#953
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.286 zoneload: info: managed-keys-zone/intern: loaded serial 151
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.286 zoneload: info: managed-keys-zone/extern: loaded serial 149
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.286 zoneload: info: zone 0.0.10.in-addr.arpa/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.286 zoneload: info: zone 10.0.10.in-addr.arpa/IN/intern: loaded serial 2025122802
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: zone nausch.org/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: zone edmz.nausch.org/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: zone 0.0.127.in-addr.arpa/IN/intern: loaded serial 42
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: zone 2.17.172.in-addr.arpa/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: 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/intern: loaded serial 42
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: zone intra.nausch.org/IN/intern (unsigned): loaded serial 2025122802
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.289 zoneload: info: 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/extern: loaded serial 42
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone 0.0.10.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone edmz.nausch.org/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone idmz.nausch.org/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone localhost/IN/extern: loaded serial 42
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone 7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/intern: loaded serial 2025122802
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone intra.nausch.org/IN/intern (signed): loaded serial 2025122802
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone localhost/IN/intern: loaded serial 42
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone 0.0.127.in-addr.arpa/IN/extern: loaded serial 42
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.293 zoneload: info: zone idmz.nausch.org/IN/intern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.296 zoneload: info: zone 2.17.217.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.296 zoneload: info: zone 131.13.92.217.in-addr.arpa/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.296 zoneload: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.296 zoneload: info: zone 3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.296 zoneload: info: zone nausch.org/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.296 zoneload: info: zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/IN/extern: loaded serial 2025122801
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.299 general: notice: all zones loaded
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.299 general: notice: FIPS mode is disabled
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.299 general: notice: running
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.336 general: info: zone intra.nausch.org/IN/intern (signed): receive_secure_serial: unchanged
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.339 general: info: CDS (SHA-256) for key intra.nausch.org/ECDSAP256SHA256/38203 is now published
Dec 29 17:56:42 vml000110 named[4176]: 29-Dec-2025 17:56:42.339 general: info: CDNSKEY for key intra.nausch.org/ECDSAP256SHA256/38203 is now published
Die, beim ersten Neustart nach Änderung der Konfiguration für die DNSSEC-Unterstützung, auflaufenden error … could not get zone keys for secure dynamic update-Meldungen können erst einmal ignoriert werden, da dies lediglich ein Hinweis ist, dass noch keine Schlüssel existieren und sich der Nameserver um die Schlüsselerstellung selbst noch vornehmen muss.
Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.140 general: error: zone omni128.de/IN/intern (signed): could not get zone keys for secure dynamic update
Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.144 general: info: zone omni128.de/IN/intern (signed): receive_secure_serial: unchanged
Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.144 general: error: zone nausch.org/IN/intern (signed): could not get zone keys for secure dynamic update
Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.150 general: info: zone nausch.org/IN/intern (signed): receive_secure_serial: unchanged
Jan 23 15:17:54 vml000110 named[31230]: 23-Jan-2026 15:17:54.150 general: error: zone edmz.nausch.org/IN/intern (signed): could not get zone keys for secure dynamic update
Achtung:
Bei einem Neustart des Daemon werden alle gecachten DNS-Informationen verworfen!
Besser ist es die geänderte Konfiguration - in dem gezeigtem Beispiel zur Aktivierung der DNSSEC-Konfigurationsoptionen - mit Hilfe eines rndc reconfig die gänderte Konfigurations neu einlesen und somit die Zonen-Dateien signieren zu lassen:
# rndc reconfig
In unserem Schlüsselverzeichnis /var/named/keys/ wurden nun automatisiert die beiden Schlüsseldateien und eine State-Dateioabgelegt.
total 160
-rw-r----- 1 root named 165 Nov 9 2024 ddns-key.intra.nausch.org.key
-rw-r--r-- 1 named named 461 Nov 9 2024 K0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+24065.key
-rw------- 1 named named 215 Nov 9 2024 K0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+24065.private
-rw-r--r-- 1 named named 682 Nov 9 2024 K0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+24065.state
-rw-r--r-- 1 named named 419 Nov 9 2024 K0.0.10.in-addr.arpa.+013+25511.key
-rw------- 1 named named 215 Nov 9 2024 K0.0.10.in-addr.arpa.+013+25511.private
-rw-r--r-- 1 named named 661 Nov 9 2024 K0.0.10.in-addr.arpa.+013+25511.state
-rw-r--r-- 1 named named 421 Nov 4 2024 K10.0.10.in-addr.arpa.+013+55683.key
-rw------- 1 named named 215 Nov 4 2024 K10.0.10.in-addr.arpa.+013+55683.private
-rw-r--r-- 1 named named 662 Nov 4 2024 K10.0.10.in-addr.arpa.+013+55683.state
-rw-r--r-- 1 named named 433 Nov 9 2024 K131.13.92.217.in-addr.arpa.+013+47324.key
-rw------- 1 named named 215 Nov 9 2024 K131.13.92.217.in-addr.arpa.+013+47324.private
-rw-r--r-- 1 named named 668 Nov 9 2024 K131.13.92.217.in-addr.arpa.+013+47324.state
-rw-r--r-- 1 named named 422 Nov 9 2024 K2.17.172.in-addr.arpa.+013+08531.key
-rw------- 1 named named 215 Nov 9 2024 K2.17.172.in-addr.arpa.+013+08531.private
-rw-r--r-- 1 named named 662 Nov 9 2024 K2.17.172.in-addr.arpa.+013+08531.state
-rw-r--r-- 1 named named 421 Nov 9 2024 K2.17.217.in-addr.arpa.+013+00761.key
-rw------- 1 named named 215 Nov 9 2024 K2.17.217.in-addr.arpa.+013+00761.private
-rw-r--r-- 1 named named 661 Nov 9 2024 K2.17.217.in-addr.arpa.+013+00761.state
-rw-r--r-- 1 named named 461 Nov 9 2024 K3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+19466.key
-rw------- 1 named named 215 Nov 9 2024 K3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+19466.private
-rw-r--r-- 1 named named 682 Nov 9 2024 K3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+19466.state
-rw-r--r-- 1 named named 461 Nov 9 2024 K3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa.+013+26597.key
-rw------- 1 named named 215 Nov 9 2024 K3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa.+013+26597.private
-rw-r--r-- 1 named named 682 Nov 9 2024 K3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa.+013+26597.state
-rw-r--r-- 1 named named 461 Nov 4 2024 K7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+55862.key
-rw------- 1 named named 215 Nov 4 2024 K7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+55862.private
-rw-r--r-- 1 named named 682 Nov 4 2024 K7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa.+013+55862.state
-rw-r--r-- 1 named named 411 Nov 9 2024 Kedmz.nausch.org.+013+27348.key
-rw------- 1 named named 215 Nov 9 2024 Kedmz.nausch.org.+013+27348.private
-rw-r--r-- 1 named named 657 Nov 9 2024 Kedmz.nausch.org.+013+27348.state
-rw-r--r-- 1 named named 411 Nov 9 2024 Kidmz.nausch.org.+013+44290.key
-rw------- 1 named named 215 Nov 9 2024 Kidmz.nausch.org.+013+44290.private
-rw-r--r-- 1 named named 657 Nov 9 2024 Kidmz.nausch.org.+013+44290.state
-rw-r--r-- 1 named named 413 Nov 4 2024 Kintra.nausch.org.+013+38203.key
-rw------- 1 named named 215 Nov 4 2024 Kintra.nausch.org.+013+38203.private
-rw-r--r-- 1 named named 658 Nov 4 2024 Kintra.nausch.org.+013+38203.state
-rw-r--r-- 1 named named 401 Nov 9 2024 Knausch.org.+013+21179.key
-rw------- 1 named named 215 Nov 9 2024 Knausch.org.+013+21179.private
-rw-r--r-- 1 named named 652 Nov 9 2024 Knausch.org.+013+21179.state
Wollen wir wissen welche Datei in dem Key-Verzeichnis für welche Zone das Schlüsselmaterial bereitstellt, können wir dies wie folgt abrufen:
# grep key-signing /var/named/keys/*
/var/named/keys/Kintra.nausch.org.+013+38203.key:; This is a key-signing key, keyid 38203, for intra.nausch.org.
Immer wenn wir named neu konfigurieren, um eine dnssec-Richtlinie einzuführen, die den bereits vorhandenen Schlüsseln entspricht, werden deren Schlüsseldateien beibehalten, sodass diese weiterhin zur Verwaltung der DNSSEC-Signaturen der betreffenden Zone verwendet werden kann. Darüber hinaus erstellt named die zugehörigen dnssec-policy Statusdateien, die für jeden Schlüssel benötigt werden - in unserem Beispiel hier intra.nausch.org.+013+38203.key.state.
Diese Datei enthält alle Informationen, die zur Bestimmung der nächsten Aktion in Bezug auf die Schlüsselwartung erforderlich sind. Die ersten fünf Zeilen bestimmen die Rolle des Schlüssels: Dieser Schlüssel ist ein 256-Bit-ECDSA256-KSK für die Zone intra.nausch.org, für die keine Gültigkeitsdauer festgelegt ist. Als Nächstes gibt es eine Reihe von Zeitangaben darüber, wann dieser Schlüssel voraussichtlich veröffentlicht wird, wann er mit dem Signieren beginnen sollte und wann der CDS (und CDNSKEY) veröffentlicht werden sollte. Wir verfolgen auch, wann sich der Status der Zustandsmaschine für verschiedene Ressourceneinträge geändert hat und in welchem Status sie sich befinden ("hidden", "rumoured", "omnipresent" oder "unretentive").
# bat /var/named/keys/Kintra.nausch.org.+013+38203.state
; <<>> DiG 9.20.17 <<>> @::1 nitro-pc.intra.nausch.org +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59154
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 28fc548affd50c99010000006952b5229c21c8fc43d8bdb2 (good)
;; QUESTION SECTION:
;nitro-pc.intra.nausch.org. IN A
;; ANSWER SECTION:
nitro-pc.intra.nausch.org. 7200 IN CNAME pml010070.intra.nausch.org.
nitro-pc.intra.nausch.org. 7200 IN RRSIG CNAME 13 4 7200 (
20260112134922 20251229155642 38203 intra.nausch.org.
vzNR/h72McVXVnigFsNopnfngdM6gqKEIBSPXGvPjc8V
NaYem3jukD87Ku0/FLlCvhiOmkzK44gPYZzSxwPClA== )
pml010070.intra.nausch.org. 7200 IN A 10.0.10.70
pml010070.intra.nausch.org. 7200 IN RRSIG A 13 4 7200 (
20260112051215 20251229155642 38203 intra.nausch.org.
EPNJqwuxGoBVxS8LVklrjCLr1eTVJ7gf7AV+wl4WvyqN
3u6SApk9E15DXhHPQjS4Yeg9cf3autuepAQxQ62lMQ== )
;; AUTHORITY SECTION:
intra.nausch.org. 7200 IN NS ns1.intra.nausch.org.
intra.nausch.org. 7200 IN RRSIG NS 13 3 7200 (
20260112134922 20251229155642 38203 intra.nausch.org.
cjjYs8JpvBjYMLlwcV76AzNWiNO8jFbl4Jk8BUXcXY3g
9BZ5KZmgg4vctijChCNhauwl0qsguFGogBAzd4Gfxg== )
;; ADDITIONAL SECTION:
ns1.intra.nausch.org. 7200 IN A 10.0.10.110
ns1.intra.nausch.org. 7200 IN RRSIG A 13 4 7200 (
20260112051215 20251229155642 38203 intra.nausch.org.
ijRNSuzdjBLDPE6T0dVGlc3C1Uuh3QEXH4yaQQHbCoIB
/1fA4sfFcmRZN3ZrYItEBE32KMJOMmn7UB4edQYEtg== )
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Mon Dec 29 18:06:42 CET 2025
;; MSG SIZE rcvd: 604
Wichtig:
Das Ad-Flag ist bei unserem authoritativen DNS-Servern nicht gesetzt! Dieses Flag wird nur bei rekursiven Resolvern wie z.B. bei Verwendung des Unbound gesetzt, da nur durch diesen die Trust-Of-Chain abgefragt und aufgelöst werden kann! Der Einrichten eines lokalen DNS-Resolvers mit Unbound unter Arch Linux werden wir uns in einem gesonderten Kapitel widmen.
Wir erhalten hier eine ausführliche Ausgabe inklusive der Signaturinformationen bei der AUTHORITY SECTION und ADDITIONAL SECTION, da wir in unserer Konfigurationsdatei die Option minimal-responses auf no gesetzt haben.
// Das Verzeichnis, in dem sich die öffentlichen und privaten
// 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;
Setzen wir hingegen die Option minimal-responses auf yes wird uns „nur noch“ folgende Antwort übermittelt:
; <<>> DiG 9.20.17 <<>> @::1 nitro-pc.intra.nausch.org +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14618
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: cd2d89195349eb00010000006952b5f0ff61a253f4356d39 (good)
;; QUESTION SECTION:
;nitro-pc.intra.nausch.org. IN A
;; ANSWER SECTION:
nitro-pc.intra.nausch.org. 7200 IN CNAME pml010070.intra.nausch.org.
nitro-pc.intra.nausch.org. 7200 IN RRSIG CNAME 13 4 7200 (
20260112134922 20251229155642 38203 intra.nausch.org.
vzNR/h72McVXVnigFsNopnfngdM6gqKEIBSPXGvPjc8V
NaYem3jukD87Ku0/FLlCvhiOmkzK44gPYZzSxwPClA== )
pml010070.intra.nausch.org. 7200 IN A 10.0.10.70
pml010070.intra.nausch.org. 7200 IN RRSIG A 13 4 7200 (
20260112051215 20251229155642 38203 intra.nausch.org.
EPNJqwuxGoBVxS8LVklrjCLr1eTVJ7gf7AV+wl4WvyqN
3u6SApk9E15DXhHPQjS4Yeg9cf3autuepAQxQ62lMQ== )
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Mon Dec 29 18:10:08 CET 2025
;; MSG SIZE rcvd: 346
Das gleich würden wir auch bei gesetzter Option minimal-responses auf no bekommen, wenn wir bei der Abfrage mittels dig die Option +noauth verwenden würden.
Wie schon bei unserem ersten Konfigurationsbeispiel und der Pflege einer Zone (ohne DNSSEC) können wir auch bei einer DNSSEC signierten Zonen-Datei manuell diese Dateien bearbeiten und verändern.
WICHTIG:
Da die einzelnen Zonendateien mit Hilfe von DNSSEC signiert wurden, können diese nicht mehr so ohne weiteres im laufenden Betrieb bearbeitet werden! Der laufende dynamische named quittiert dies mit folgender Fehlermeldung:
Sollen die Zonendaten/Zonendateien eines dynamischen DNS-Servers im laufenden Betrieb editiert werden, führt dies beim nächsten Start des named zu der Fehlermeldung:
Nov 09 16:17:18 vml000110 named[1971]: 09-Nov-2024 16:17:18.148 journal rollforward failed: journal out of sync with zone
Die manuellen Änderungen an den Zonendaten/Zonendateien können so nicht übernommen werden!
Mithilfe des Befehls rndc freeze können wir den aktuellen Stand einfrieren und damit eine Aktualisierungen einer dynamischen Zone aussetzen. Wird keine Zone angegeben, werden alle Zonen eingefroren/ausgesetzt. Dadurch können bei Bedarf manuelle Änderungen an einer Zone vorgenommen werden, die normalerweise durch eine dynamische Aktualisierung aktualisiert wird und es werden Änderungen in der Journal-Datei mit der Master-Datei synchronisiert. Alle dynamischen Aktualisierungsversuche werden, während die Zone eingefroren ist, abgelehnt!
# rndc freeze intra.nausch.org
Im Journal wird dies entsprechend dokumentiert.
Dec 29 18:15:39 vml000110 named[4659]: 29-Dec-2025 18:15:39.896 general: info: received control channel command 'freeze intra.nausch.org'
Nun können wir wie gewohnt das betreffende Zone-File editieren.
# vim /var/named/zones/i.intra.nausch.org.db
Zum Auftauen thaw einer zuvor eingefrorenen Zone oder view verwenden wir den Befehl rndc thaw. Wenn keine Zone angegeben wird, werden alle eingefrorenen Zonen aktiviert. Dadurch wird der Server veranlaßt, die Zone von der Festplatte neu zu laden, und dynamische Aktualisierungen werden nach Abschluß des Ladevorgangs wieder aktiviert. Nach dem Auftauen einer Zone werden dynamische Aktualisierungen nicht mehr abgelehnt.
# rndc thaw intra.nausch.org
Der Auftauvorgang thaw wurde natürlich auch wieder im Journal festgehalten:
Dec 29 18:20:56 vml000110 named[4659]: 29-Dec-2025 18:20:56.341 general: info: received control channel command 'thaw intra.nausch.org'
Dec 29 18:20:56 vml000110 named[4659]: 29-Dec-2025 18:20:56.345 general: info: thawing zone 'intra.nausch.org/IN' intern: success
Pflege von DNSSEC signierten dynamischen Zonen mit Hilfe von nsupdate
Hintergründe
BIND9 stellt für die dynamischen DNS-Aktualisierung von dynamischen Zonen das Hilfsprogramm nsupdate zur Verfügung. In der Manpage von nsupdate finden sich viele hilfreiche Tips zum Umgang mit dem Hilfsprogramm.
nsupdate wird verwendet, um Dynamic DNS Update-Anfragen, wie in RFC 2136 definiert, an einen Namenserver zu senden. Dadurch können Ressourceneinträge zu einer Zone hinzugefügt oder daraus entfernt werden, ohne die Zonendatei manuell zu bearbeiten. Eine Singleupdate-Anfrage kann Anfragen zum Hinzufügen oder Entfernen von mehr als einem Ressourceneintrag enthalten.
Zonen, die über nsupdate oder einen DHCP-Server dynamisch gesteuert werden, sollten nicht mehr manuell bearbeitet werden. Manuelle Änderungen könnten mit dynamischen Aktualisierungen in Konflikt geraten und zu Datenverlust führen!
Die Ressourceneinträge, die mit nsupdate dynamisch hinzugefügt oder entfernt werden, müssen sich in derselben Zone befinden. Anfragen werden an den primären Server der Zone gesendet, der durch das MNAME-Feld des SOA-Eintrags der Zone identifiziert wird. Transaktionssignaturen können zur Authentifizierung der dynamischen DNS-Aktualisierungen verwendet werden. Diese verwenden den TSIG-Ressourceneintragstyp, der in RFC 2845 beschrieben wird, den SIG(0)-Eintrag, der in RFC 2535 und RFC 2931 beschrieben wird, oder GSS-TSIG, wie in RFC 3645 beschrieben.
TSIG basiert auf einem gemeinsamen Geheimnis, das nur nsupdate und dem Namensserver bekannt sein sollte. Beispielsweise werden geeignete Schlüssel- und Serveranweisungen zu /etc/named.conf hinzugefügt, damit der Namensserver den entsprechenden geheimen Schlüssel und Algorithmus mit der IP-Adresse der Client-Anwendung verknüpfen kann, die die TSIG-Authentifizierung verwendet. ddns-confgen kann geeignete Konfigurationsfragmente generieren. nsupdate verwendet die Optionen -y oder -k, um den gemeinsamen TSIG-Schlüssel bereitzustellen; diese Optionen schliessen sich gegenseitig aus. SIG(0) verwendet die Kryptografie mit öffentlichem Schlüssel. Um einen SIG(0)-Schlüssel zu verwenden, muss der öffentliche Schlüssel in einem KEY-Datensatz in einer Zone gespeichert werden, die vom Namensserver bedient wird. GSS-TSIG verwendet Kerberos-Anmeldeinformationen. Der Standard-GSS-TSIG-Modus wird mit der Option -g aktiviert.
Konfiguration
Für den Update der Zonen benötigen wir pro Zone ein Schlüsselpaar, mit Hilfe derer eine Sicherheitsstufe eingezogen und genutzt werden kann, so daß nicht unberechtigter Wiese Änderungen an den Zonenfiles vorgenommen werden können. Dieses Schlüsselmaterials legen wir in unserem bereits bestehenden Verzeichnis /var/named/keysab.
Zum Erstellen der Schlüssel verwenden wir das Hilfs-/Dienstprogramm ddns-confgen, mit dem Schlüssel für die Verwendung in der TSIG-Signatur generiert werden. Die resultierenden Schlüssel können beispielsweise verwendet werden, um dynamische DNS-Updates für eine Zone zu sichern, oder für den rndc-Befehlskanal. Die Manpage des Programms liefert eine entsprechende Hilfe und zeigt auch die entsprechenden Optionen auf, die bei der Generierung des DDNS-Schlüsselmaterials verwendet werden können.
In folgendem Beispiel, welches wir lediglich zum Anzeigen der später benötigten Konfigurationsoptionen benutzen, nutzen wir folgende Optionen beim Aufruf des Hilfsprogramms ddns-confgen
-a algorithm (Diese Option gibt den Algorithmus an, der für den TSIG-Schlüssel verwendet werden soll.) = hmac-sha512 oder kurz sha256
-z zone (Diese Option definiert die Zone für die das DDNS-Key-Paar gelten soll.) = intra.nausch.org.key
-k keyname (Diese Option gibt den Schlüsselnamen des rndc-Authentifizierungsschlüssels an.) = ddns-key.intra.nausch.org.key
# ddns-confgen -a sha512 -z intra.nausch.org -k ddns-key.intra.nausch.org.key
# To activate this key, place the following in named.conf, and
# in a separate keyfile on the system or systems from which nsupdate
# will be run:
key "ddns-key.intra.nausch.org.key" {
algorithm hmac-sha512;
secret "Jvz0G6qaeW7MG5NaofsIISjNeMD7Xse2Q1ca8JMp8ZkX9tBl1foS1+kMvx5kN8ZU7iKTJvl2o+6/2Ge2cvVt/w==";
};
# Then, in the "zone" definition statement for "intra.nausch.org",
# place an "update-policy" statement like this one, adjusted as
# needed for your preferred permissions:
update-policy {
grant ddns-key.intra.nausch.org.key zonesub ANY;
};
# After the keyfile has been placed, the following command will
# execute nsupdate using this key:
nsupdate -k <keyfile>
Wir erstellen uns also nun pro verwendeter Zone ein entsprechendes DDNS-Key-Paar. Hier das Beispiel für die Zone intra.nausch.org.
Wie ergänzen nun die Konfigurationsdatei unseres BIND9 damit dieser dieses Schlüsselmaterial kennt und wir mit Hilfe von nsupdate später in der Lage sind, Änderungen an unseren ausgewählten Zonen vornehmen zu können.
Zunächst includieren wir den bzw. die erstellten Schlüssel am Anfang der Konfigurationsdatei /etc/named.conf die ddns Schlüsseldefinition.
# vim /etc/named.conf
// *********************** ddns Schlüsseldefinition ***********************
include "/var/named/keys/ddns-key.intra.nausch.org.key";
Bei der Definition unserer Zone ergänzen wir dann noch die Zeile allow-update { key „ddns-key.intra.nausch.org.key“; };, so daß der Block nun folgenden Inhalt hat:
// View: intern - Zone: intra.nausch.org (forward)
zone "intra.nausch.org" IN {
type master;
file "zones/intra.nausch.org.db";
dnssec-policy "ownway"
allow-update { key "ddns-key.intra.nausch.org.key"; };
};
Zum Aktivieren unserer Änderungen führen wir einen reconfig unseres named aus.
# rndc reconfig
Änderungen via nsupdate
Nun sind wir in der Lage während der Laufzeit Änderungen an der Konfiguration unseres named vorzunehmen. Im ersten Beispiel fügen wir einen A-Record für den Host mit dem Hostnamen testhost in der Zone intra.nausch.org durch. Dieser Host ist über die Adresse 10.0.10.123 erreichbar.
> server 10.0.0.110
> zone intra.nausch.org
> update add testhost.intra.nausch.org 2400 A 10.0.10.123
> send
> quit
Im Journal wird dieser neue Eintrag wie folgt quittiert:
Nov 09 22:53:31 vml000110 named[4113]: 09-Nov-2024 22:53:31.163 general: info: zone intra.nausch.org/IN/intern (signed): serial 2024110913 (unsigned 2024110905)
Fragen wir nun unseren DNS nach der Adresse für unseren neuen Host mit Namen testhost erhalten wir auch sofort entsprechende Antwort:
# dig @::1 testhost.intra.nausch.org
; <<>> DiG 9.20.3 <<>> @::1 testhost.intra.nausch.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53306
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: cf46e16ac570dfe801000000672fda1407cdb4ab988b465c (good)
;; QUESTION SECTION:
;testhost.intra.nausch.org. IN A
;; ANSWER SECTION:
testhost.intra.nausch.org. 2400 IN A 10.0.10.123
;; AUTHORITY SECTION:
intra.nausch.org. 7200 IN NS ns1.intra.nausch.org.
;; ADDITIONAL SECTION:
ns1.intra.nausch.org. 7200 IN A 10.0.10.110
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sat Nov 09 22:54:28 CET 2024
;; MSG SIZE rcvd: 132
Achtung:
Im Moment sind diese Änderungen lediglich im Speicher zur Laufzeit unseres DNS verfügbar. Bei einem Neustart des Systems wäre diese Änderung nicht mehr existent, da diese noch nicht im Zone-File der Zone intra.nausch.org manifestiert wurde!
Dies zeigt sich auch, wenn wir einen Blick auf die Zonen-Dateien richten:
# ls -l /var/named/zones/i.intra.nausch.org.db*
-rw-r--r-- 1 named named 1503 Nov 9 16:43 ../zones/i.intra.nausch.org.db
-rw-r--r-- 1 named named 512 Nov 9 22:48 ../zones/i.intra.nausch.org.db.jbk
-rw-r--r-- 1 named named 767 Nov 9 22:53 ../zones/i.intra.nausch.org.db.jnl
-rw-r--r-- 1 named named 7133 Nov 9 16:05 ../zones/i.intra.nausch.org.db.signed
-rw-r--r-- 1 named named 17705 Nov 9 22:53 ../zones/i.intra.nausch.org.db.signed.jnl
Erst durch einen manuellen Synchronisationsaufruf werden die Informationen aus dem Speicher in das zugehörige Zonen-File übertragen!
# rndc sync
Diese sync wird natürlich im Journal wieder entsprechend dokumentiert:
Nov 09 22:57:52 vml000110 named[4113]: 09-Nov-2024 22:57:52.807 general: info: received control channel command 'sync'
Nov 09 22:57:52 vml000110 named[4113]: 09-Nov-2024 22:57:52.810 general: info: dumping all zones: success
Ein erneuter Blick in das Verzeichnis zeigt auch die betreffenden neuen mtime-Zeitstempel.
# ls -l /var/named/zones/i.intra.nausch.org.db*
-rw-r--r-- 1 named named 981 Nov 9 22:57 /var/named/zones/i.intra.nausch.org.db
-rw-r--r-- 1 named named 512 Nov 9 22:48 /var/named/zones/i.intra.nausch.org.db.jbk
-rw-r--r-- 1 named named 767 Nov 9 22:53 /var/named/zones/i.intra.nausch.org.db.jnl
-rw-r--r-- 1 named named 7892 Nov 9 22:57 /var/named/zones/i.intra.nausch.org.db.signed
-rw-r--r-- 1 named named 17705 Nov 9 22:53 /var/named/zones/i.intra.nausch.org.db.signed.jnl
In der Zonendatei - die natürlich jetzt nicht mehr so toll formatiert ist, wie wir diese ursprünglich angelegt hatten, - taucht der Eintrag für unseren neuen Host entsprechend auf:
# cat /var/named/zones/i.intra.nausch.org.db
$TTL 7200 ; 2 hours
intra.nausch.org. IN SOA ns1.intra.nausch.org. hostmaster.nausch.org. (
2024110905 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
600 ; minimum (10 minutes)
)
NS ns1.intra.nausch.org.
MX 10 mx1.intra.nausch.org.
apc-usv.intra.nausch.org. CNAME pnc010023.intra.nausch.org.
fwc.intra.nausch.org. CNAME vml010110.intra.nausch.org.
mx1.intra.nausch.org. A 10.0.10.110
nitro-pc.intra.nausch.org. CNAME pml010070.intra.nausch.org.
ns1.intra.nausch.org. A 10.0.10.110
pml010070.intra.nausch.org. A 10.0.10.70
AAAA fd00::7:10:0:10:70
pnc010023.intra.nausch.org. A 10.0.10.23
AAAA fd00::7:10:0:10:23
$TTL 2400 ; 40 minutes
testhost.intra.nausch.org. A 10.0.10.123
$TTL 7200 ; 2 hours
thinclient.intra.nausch.org. CNAME pml010070.intra.nausch.org.
usv.intra.nausch.org. CNAME pnc010023.intra.nausch.org.
vml010110.intra.nausch.org. A 10.0.10.110
AAAA fd00::7:10:0:10:110
Genau so wie wir den Eintrag für unseren Testhost hinzugefügt haben, werden wir diesen nun im nächsten Schritt wieder entfernen.
> server 10.0.0.110
> zone intra.nausch.org
> update delete testhost.intra.nausch.org
> send
> quit
Auch diese Aktion finden wir wieder im Journal:
Nov 09 23:55:33 vml000110 named[4113]: 09-Nov-2024 23:55:33.761 general: info: zone intra.nausch.org/IN/intern (signed): serial 2024110914 (unsigned 2024110906)
Fragen wir nun erneut nach dem A-Record unseres Testhost mit dem Namen testhost.intra.nausch.org erhalten wir nunmehr keine Antwort mehr:
# dig @::1 testhost.intra.nausch.org
; <<>> DiG 9.20.3 <<>> @::1 testhost.intra.nausch.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18176
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 30b511e3daddaf5c01000000672fe8fb3ead1fccafd0d496 (good)
;; QUESTION SECTION:
;testhost.intra.nausch.org. IN A
;; AUTHORITY SECTION:
intra.nausch.org. 600 IN SOA ns1.intra.nausch.org. hostmaster.nausch.org. 2024110914 3600 900 1209600 600
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sat Nov 09 23:58:03 CET 2024
;; MSG SIZE rcvd: 133
Auch diese Änderung wollen wir natürlich im Zone-File manifestiert sehen. Wir rufen also dazu den Befehl rndc sync auf.
# rndc sync
… was wieder im Journale ntsprechend dokumentiert wird:
Nov 09 23:59:45 vml000110 named[4113]: 09-Nov-2024 23:59:45.585 general: info: received control channel command 'sync'
Nov 09 23:59:45 vml000110 named[4113]: 09-Nov-2024 23:59:45.585 general: info: dumping all zones: success
Wie wir sehen, ist der Eintrag für den Testhost wieder entfernt worden!
# cat /var/named/zones/i.intra.nausch.org.db
$TTL 7200 ; 2 hours
intra.nausch.org. IN SOA ns1.intra.nausch.org. hostmaster.nausch.org. (
2024110906 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
600 ; minimum (10 minutes)
)
NS ns1.intra.nausch.org.
MX 10 mx1.intra.nausch.org.
apc-usv.intra.nausch.org. CNAME pnc010023.intra.nausch.org.
fwc.intra.nausch.org. CNAME vml010110.intra.nausch.org.
mx1.intra.nausch.org. A 10.0.10.110
nitro-pc.intra.nausch.org. CNAME pml010070.intra.nausch.org.
ns1.intra.nausch.org. A 10.0.10.110
pml010070.intra.nausch.org. A 10.0.10.70
AAAA fd00::7:10:0:10:70
pnc010023.intra.nausch.org. A 10.0.10.23
AAAA fd00::7:10:0:10:23
thinclient.intra.nausch.org. CNAME pml010070.intra.nausch.org.
usv.intra.nausch.org. CNAME pnc010023.intra.nausch.org.
vml010110.intra.nausch.org. A 10.0.10.110
AAAA fd00::7:10:0:10:110
In unserer, mit Hilfe und Unterstützung von Ansible orchestrierten, Produktionsumgebung werden wir die Zonen-Dateien aber weder manuell verwalten und beschreiben, noch mit Hilfe von nsupdate bearbeiten. Vielmehr werden wir mit den Daten aus dem Inventory automatisiert die Zonendateien verwalten und signieren lassen - dazu gleich mehr!
Webstatus mit Hilfe des eingebauten WEB-Servers und "ISC Bind 9 Configuration and Statistics"
Unser BIND9 bringt uns einen rudimentären Webserver. In der Konfigurationsdatei /etc/named.conf hatten wir bei der Basiskonfioguration diese Option bereits berücksichtigt.
// Die BIND 9-Statistiken können auch über das HTTP-Protokoll von
// einem laufenden BIND 9-Server abgerufen werden. BIND 9 verfügt
// über einen winzigen integrierten Webserver, der die Statistik-
// daten im XML- oder JSON-Format bereitstellt.
statistics-channels {
inet 127.0.0.1 port 8080 allow {
127.0.0.1;
};
};
Orchestrierung - Installation und Konfiguration des BIND9 inkl. der Zonen-Datei-Pflege mit Hilfe von Ansible
Aufgabenstellung
Natürlich wird man im Jahr 2026 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. Ansible zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten Ansible als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden, es also keine Bastel-/Frickellösung geben wird.
Betrachten wir kurz die grundlegende Infrastruktur, in der wir eine Lösung für den Netzdienst DNS mit Hilfe von Ansible bauen und verwalten wollen. In dem Beispiel werden wir in diesem Beispiel erst einmal einen ISC Bind aufsetzen der Anfragen lediglich auf den beiden localhost-Adressen 127.0.0.1 und ::1 beantworten soll. In einem [linux:unbound#orchestrierung_-_installation_und_konfiguration_des_unbound-resolvers_mit_hilfe_von_ansible|zweiten Schritt]] werden wir dann für die workload der Clients aus den einzelnen Zonen einen unbound-Resolver aufsetzen.
Da wir selbst keine eigenen DNS-Server, die für alle im Internet erreich- und abfragbar sind, wollen wir auch noch dafür sorgen, dass unser Ansible-Playbook nicht nur die internen Zonefiles aus dem Inventory generiert, sondern auch ein „spezielles“ Zonefile mit den offiziellen Adressen schreibt, welches wir dann in einem manuellen Schritt bei Bedarf beim ISP - in unserem Falle core-networks - hochladen und importieren können.
Wir werden uns nun nachfolgend die DNS-Server-Installation und -konfiguration genauer betrachten.
Lösung
Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:
Der Beispiel-Hosts aus der Gruppe|Zone edmz in diesem Inventory beschreibt den Switch der EDMZ.
Der Host vml000110 ist in diesem Beispiel unser Server, der die Verbindung zwischen der Zone intra und der Zone idmz herstellt. Auf diesem Konten läuft bereits ein Chrony Timeserver| wie auch eine Firewall auf Basis von firewalld der eine Zonendefinition intra besitzt, die die Regeln für diese Zone beinhalten. Sowohl Timeserver wie auch Firewall werden in diesem Beispiel hier nur erwähnt, da in dem Playbook bzw.genauer gesagt im Inventory darauf referenziert wird.
In der Zone idmz finden wir ferner noch die Beschreibung des Intranet-Switch und eine der Workstations.
Wir legen uns also nun die Hostdefinitionsdatei für unseren Switch in der Zonme edmz an.
Die für die Domain nausch.org relevanten Daten legen wir in der Inventrory-Datei inventories/production/host_vars/vml000110/bind_nausch_org ab. In dieser Datei ist ein Array definiert, welches die externen Hostnamen/vHosts beschreibt, für die jeweils ein eigener A und AAAA Record angelegt werden soll. Diese Parameter werden wir später auch bei der Definition der einzelnen virtuellen Maschinen heranziehen, also 1x Daten vorhalten für Apache-Webserver und auch für das Thema DNS. So brauchen wir nicht n-mal die gleichen Daten definieren!
$ vim inventories/production/host_vars/vml000110/bind_nausch_org
Unser Playbook zum Installieren und Konfigurieren des ISC Bind-Daemon ist wie immer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist.
---# Ansible Playbook zum Installieren und Konfigiurieren eines DNS-Servers auf Basis ISC-BIND.## Aufruf via:# $ ansible-playbook playbooks/bind.yml
- name: "Playbookname: bind.yml"# Name des Playbooks
hosts: vml000110 # Host bzw. Hostgruppen für die das Playbook gelten soll
roles:
- role: bind # ISC-BIND Daemon einrichten...
Rolle
Für die Konfiguration der ISC BIND-Daemon verwenden wir eine eigene Rolle bind, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die Mustervorlagecommon, welche wir bei der initialen Ansible-Einrichtung angelegt hatten.
Wie wir sehen ist die Rolle durchaus überschaubar, im Task main.yaml verweisen wir lediglich auf die eigentlichen Tasks install, grundkonfig, zonefiles, fetchzonefiles, konfig und firewalld
Für die Grundkonfiguration des ISC BIND-Daemon (rndc-Schlüsselanlage, Definition für die 13 Root-Server und Anlegen der Verzeichnisse) werden die nötigen Schritte in der Task-Gruppe mit dem tag grundkonfig definiert.
---
- name: "Checken ob es bereits eine Datei /etc/rndc.key gibt."
ansible.builtin.stat:
path: /etc/rndc.key
register: bind_check_rndc_key
- name: "Individuellen Schlüssel für rndc erzeugen und ablegen."
ansible.builtin.command:
cmd: rndc-confgen -A hmac-sha512 -b 512 -a -c /etc/rndc.key -k homelab-key -u named
register: bind_rndc_key
changed_when: bind_rndc_key.rc != 0
when: not bind_check_rndc_key.stat.exists
- name: "Berechtigungen der Schlüssel-Datei /etc/rndc.key sicherstellen."
ansible.builtin.file:
path: /etc/rndc.key
owner: root
group: named
mode: '0640'
- name: "Checken ob es bereits eine Datei /var/named/named.root gibt."
ansible.builtin.stat:
path: /var/named/named.root
register: bind_check_named_root
- name: "Liste der 13 Root-Nameserver holen und ablegen."
ansible.builtin.command:
cmd: dig +bufsize=1200 +norec NS . @a.root-servers.net
register: bind_root_server
changed_when: bind_root_server.rc != 0
when: not bind_check_named_root.stat.exists
- name: "Sicherstellen dass die Datei named.root existiert."
ansible.builtin.file:
path: /var/named/named.root
state: touch
owner: root
group: named
mode: '0640'
when: not bind_check_named_root.stat.exists
- name: "Liste der zuvor erstellten 13 Root-Name-Server in /var/named/named.root ablegen."
ansible.builtin.copy:
content: "{{ bind_root_server.stdout }}"
dest: /var/named/named.root
owner: root
group: named
mode: '0640'
when: not bind_check_named_root.stat.exists
- name: "Sicherstellen dass das Verzeichnis für die Zonendateien existiert."
ansible.builtin.file:
path: /var/named/zones
state: directory
owner: root
group: named
mode: '0770'
- name: "Sicherstellen dass das Verzeichnis für die externen Zonendateien existiert."
ansible.builtin.file:
path: /var/named/zones_external
state: directory
owner: root
group: named
mode: '0770'
...
Das Anlegen der Zonefiles erfolgt dann mit Hilfe des Task-Gruppe mit dem tag zonefiles mit den Daten aus dem Inventory konfiguriert.
Damit wir uns nicht die Finger brechen bzw. wund tippen speziell bei den Reverse-IPv6-Adressen delegieren wir solch stupide und fehleranfällige Arbeiten an Ansible. Zur Konvertierung der IPv6-Adressen ist hierzu das Paket netaddr notwendig, das wir bei Bedarf mit Hilfe des Paketmanagers auf unserem Linux-Ansible-Kontrollnode/-Workstation noch installieren:
$ sudo pacman -S netaddr
.
Anschließens generieren wir noch das spezielle Zone-File, welches wir dann später bei unserem ISP einkippen werden.
---
- name: "Zonen Datei für IPv4|6 Forward Auflösung der Zone intra.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/intra.nausch.org.j2
dest: /var/named/zones/intra.nausch.org.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4 Reverse Auflösung der Zone intra.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/10.0.10.in-addr.arpa.zone.db.j2
dest: /var/named/zones/intra.nausch.org.in-addr.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv6 Reverse Auflösung der Zone intra.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/intra.nausch.org.ip6.j2
dest: /var/named/zones/intra.nausch.org.ip6.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4|6 Forward Auflösung der Zone idmz.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/idmz.nausch.org.j2
dest: /var/named/zones/idmz.nausch.org.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4 Reverse Auflösung der Zone idmz.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/idmz.nausch.org.in-addr.j2
dest: /var/named/zones/idmz.nausch.org.in-addr.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv6 Reverse Auflösung der Zone idmz.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/idmz.nausch.org.ip6.j2
dest: /var/named/zones/idmz.nausch.org.ip6.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4|6 Forward Auflösung der Zone edmz.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/edmz.nausch.org.j2
dest: /var/named/zones/edmz.nausch.org.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4 Reverse Auflösung der Zone edmz.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/edmz.nausch.org.in-addr.j2
dest: /var/named/zones/edmz.nausch.org.in-addr.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv6 Reverse Auflösung der Zone edmz.nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/edmz.nausch.org.ip6.j2
dest: /var/named/zones/edmz.nausch.org.ip6.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4|6 Forward Auflösung der Zone nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/nausch.org.j2
dest: /var/named/zones/nausch.org.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4 Reverse Auflösung der Zone nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/12.92.217.in-addr.arpa.zone.db.j2
dest: /var/named/zones/nausch.org.in-addr.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv6 Reverse Auflösung der Zone nausch.org erzeugen und kopieren."
ansible.builtin.template:
src: templates/nausch.org.ip6.j2
dest: /var/named/zones/nausch.org.ip6.db
owner: named
group: named
mode: '0640'
notify: Restart bind
- name: "Zonen Datei für IPv4|6 Forward Auflösung der Zone nausch.org für core-networks.de erzeugen und kopieren."
ansible.builtin.template:
src: templates/cn.nausch.org.j2
dest: /var/named/zones_external/nausch.org.db
owner: named
group: named
mode: '0640'
...
Das zuvor generierte spezielle Zone-File holen wir uns nun auf unseren Linux-Ansible-Kontrollnode/-Workstation, damit wir dieses dann später bei unserem ISP einkippen. Hierzu erstellen wir noch ein entsprechendes Verzeichnis auf unserer lokalen Workstation.
$ mkdir ~/devel/isp/
Der Task zum Holen des Zonefiles für den ISP beschränkt sich lediglich auf einen Schritt zum Downloaden der betreffenden Datei.
---
- name: "Konfiguration der firewalld Regeln in Zone_2 für die Kea-Daemon."
ansible.posix.firewalld:
zone: '{{ guest_zone_2 }}'
service: '{{ item.service }}'
immediate: true
permanent: true
state: enabled
with_items: '{{ guest_fw_services }}'
- name: "Zum Schluss den aktuellen permanenten Regelsatz final neu laden."
ansible.builtin.service:
name: firewalld
state: reloaded
...
Sollte bei der Abarbeitung des Playbook die Konfigurationsdatei named.conf bzw. bei den Zonefiles unter /var/named/zones verändert werden, ist natürlich hierbei ein Restart der betreffenden ISC Bind-Daemon notwendig. Hierzu verwenden wir die Ansible Playbook Handlers. Dieser Handler wird bei den betreffenden Tasks zur Erstellung der Kea-Konfigurationsdateie bze. der Zonesfiles mit Hilfe eines handler-Calls aufgerufen, sofern sich die Dateien verändert hat.
Wir brauchen wir noch eine Konfiguration der Aufgaben die bei einem notify abgearbeitet werden sollen.
// ********************************* named.conf **********************************
// * Ansible managed Konfigurationsdatei des ISC BIND, nicht manuell bearbeiten! *
// ********************************* named.conf **********************************
// Konfig-Beschreibung: https://dokuwiki.nausch.org/doku.php/linux:bind
// ********** Variablendefinition für die unterschiedlichen ACLs **********
acl local {
127.0.0.1;
::1;
};
acl interfaces {
127.0.0.1;
::1;
};
// *********************** rndc Schlüsseldefinition ***********************
include "/etc/rndc.key";
// *********************** rndc Control-Definition ************************
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "homelab-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/keys";
// Das Verzeichnis, in dem die Dateien gespeichert werden, welche
// die verwalteten DNSSEC-Schlüssel verfolgen.
managed-keys-directory "/var/named/dynamic";
// Dies gibt das Verzeichnis an, in dem die Konfigurationsparameter für
// Zonen gespeichert werden, die über rndc addzone hinzugefügt wurden.
// Standardmäßig ist dies das Arbeitsverzeichnis.
new-zones-directory "/var/named/zones";
// 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";
// Hiermit werden Speicherstatistiken in die Datei geschrieben, die beim
// Beenden durch memstatistics-file angegeben wird. Die Standardeinstell-
// ung ist "no", es sei denn, -m record wird in der Befehlszeile angege-
// ben. In diesem Fall lautet die Einstellung "yes".
memstatistics yes;
// Der Pfadname der Datei, in die der Server beim Beenden die
// Speicherverbrauchsstatistik schreibt.
memstatistics-file "/var/named/data/named_mem_stats.txt";
// Hiermit wird der Algorithmus festgelegt, der beim Generieren des Ser-
// ver-Cookies verwendet werden soll. Die Optionen sind "aes", "sha1"
// oder "sha256". Der Standardwert ist "aes", sofern dies von der krypto-
// grafischen Bibliothek unterstützt wird, andernfalls "sha256".
// cookie-algorithm aes;
// 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";
// Dies ist der für den TSIG-Sitzungsschlüssel zu verwendende Algorithmus.
// Gültige Werte sind hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384,
// hmac-sha512 und hmac-md5. Wenn nichts angegeben wird, ist der
// Standardwert hmac-sha256.
session-keyalg hmac-sha512;
// Hiermit wird die maximale RSA-Exponentengröße in Bits festgelegt, die
// bei der Validierung akzeptiert wird. Gültige Werte sind 35 bis 4096
// Bits. Der Standardwert Null wird ebenfalls akzeptiert und entspricht
// 4096.
max-rsa-exponent-size 4096;
// 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-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 {
localhost;
};
// Definiert welche Hosts gewöhnliche DNS-Fragen stellen dürfen.
allow-query {
localhost;
};
// Definiert welche lokalen Adressen gewöhnliche DNS-Anfragen
// annehmen können.
allow-query-on {
localhost;
};
// Definiert welche Hosts Antworten aus dem Cache erhalten dürfen.
allow-query-cache {
localhost;
};
// Definiert welche lokalen Adressen Antworten aus dem Cache senden können.
allow-query-cache-on {
localhost;
};
// Legt fest, welche Hosts rekursive Abfragen über diesen Server
// durchführen dürfen.
allow-recursion {
localhost;
};
// Legt fest, welche lokalen Adressen rekursive Abfragen akzeptieren können.
allow-recursion-on {
localhost;
};
// Gibt an, welche Hosts Zonentransfers vom Server empfangen dürfen.
allow-transfer {
localhost;
};
// Ist die dynamische Aktualisierung für eine Zone mit der Option
// "allow-update" aktiviert, darf KEINENFALLS die Zonendatei manuell
// bearbeitet werden!
allow-update {
none;
};
// Wenn ja,dann können Zonen zur Laufzeit über rndc addzone hinzugefügt
// werden. Die Standardeinstellung ist "no". Die Konfigurationsparame-
// ter neu hinzugefügter Zonen werden gespeichert, sodass sie nach einem
// Neustart des Servers erhalten bleiben. Die Konfigurationsinformationen
// werden in einer Datei namens "viewname.nzf" gespeichert (oder, wenn
// "named" mit liblmdb kompiliert wurde, in einer LMDB-Datenbankdatei
// namens "viewname.nzd"). "viewname" ist der Name der Ansicht, es sei
// denn, der Name der Ansicht enthält Zeichen, die nicht mit der Verwen-
// dung als Dateiname kompatibel sind. In diesem Fall wird stattdessen
// ein kryptografischer Hash des Ansichtsnamens verwendet. Konfigurati-
// onen für Zonen, die zur Laufzeit hinzugefügt werden, werden entweder
// in einer New-Zone-Datei (NZF) oder einer New-Zone-Datenbank (NZD)
// gespeichert, je nachdem, ob named zum Zeitpunkt der Kompilierung mit
// liblmdb verknüpft wurde. Weitere Informationen zu rndc addzone finden
// Sie unter rndc – Name-Server-Steuerungsprogramm.
allow-new-zones no;
// 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 { interfaces; };
listen-on-v6 port 53 { interfaces; };
// 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 *;
// Die Abfrageprotokollierung bietet ein vollständiges Protokoll aller
// eingehenden Abfragen und aller Abfragefehler. Dies bietet einen besseren
// Einblick in die Serveraktivität, allerdings mit einem erheblichen
// Leistungsabfall bei stark ausgelasteten Servern. Die Option "querylog"
// gibt an, ob die Abfrageprotokollierung beim ersten Start von named
// aktiv sein soll.
querylog no;
// 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 2048;
// 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.
// Dieser Wert ist immer auf 0 gesetzt. Weitere Informationen finden sich
// im Sicherheitshinweis zu CVE-2021-25219.
lame-ttl 0;
// 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.
hostname none;
server-id none;
// BIND 9-Zugriffskontrolllisten werden verwendet, um den Zugriff auf ver-
// schiedene Serverfunktionen entsprechend der IP-Adresse des Anfragenden
// zu beschränken. BIND 9.10 kann Daten aus MaxMind GeoIP-Datenbanken ver-
// wenden, um Beschränkungen basierend auf dem (vermuteten) geografischen
// Standort dieser Adresse zu erreichen.
geoip-directory none;
};
// Die BIND 9-Statistiken können auch über das HTTP-Protokoll von
// einem laufenden BIND 9-Server abgerufen werden. BIND 9 verfügt
// über einen winzigen integrierten Webserver, der die Statistik-
// daten im XML- oder JSON-Format bereitstellt.
statistics-channels {
inet 127.0.0.1 port 8080 allow {
127.0.0.1;
};
};
// ************** Definition einer eigenen policy für DNSSEC **************
dnssec-policy "{{ bind_zone_dnssec_policy }}" {
keys {
// Combined Signing Key CSK lifetime und Key Algorithmus
// Definition des standardmäßigen Speicherorts der automatisch generierten
// Schlüsseldateien. Ferner kann die lifetime angegeben sowie der zu ver-
// wendendeten Algorithus angegeben werden.
csk key-directory lifetime unlimited algorithm ecdsa256;
};
// Gibt an, ob BIND 9 eine separate signierte Version einer Zone verwaltet.
// Die Verwendung von Inline-Signing wird durch die dnssec-policy für die
// Zone bestimmt. Wenn Inline-Signing in Zone explizit auf yes oder no
// gesetzt wird, überschreibt dies jeden Wert von dnssec-policy.
inline-signing yes;
// Proof of Non-Existence mit Hilfe von NSEC3
// Alles nach nsec3param ist optional. Werden diese nicht explizit defi-
// niert, verwendet BIND 9 Standardwerte. Will man jedoch sicherstellen
// dass die Parameter mit entsprechend vorgegebenen bzw. vorhandenen
// NSEC3-Parametern übereinstimmen, sind diese explizit festzulegen.
// Zu beachten ist, dass man kein bestimmtes Salt defionieren kann. sofern
// ein vorhandene Salt jedoch dieselbe Länge wie salt-length hat, ent-
// spricht es der Richtlinie und es erfolgt kein erneutes Salting.
nsec3param iterations 0 optout no salt-length 0;
// Schlüssel-Timing-Informationen
// Zu beachten ist, dass dnssec-policy zwar Schlüssel-Timing-Informationen
// festlegt, aber eine eigene state-machine verwendet, um zu bestimmen,
// welche Aktionen ausgeführt werden sollen.
dnskey-ttl PT1H;
publish-safety PT1H;
retire-safety PT1H;
purge-keys P90D;
// Signature-Timing-Informationen
signatures-refresh P5D;
signatures-validity P14D;
signatures-validity-dnskey P14D;
// Zonen Parameter
max-zone-ttl P1D;
zone-propagation-delay PT5M;
parent-ds-ttl P1D;
parent-propagation-delay PT1H;
};
// ******************** 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!
//
// 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!
view "intern" IN {
// Ist der Anfragende Client aus dem Intranet (Zone intra)?
match-clients {
local;
};
// View: intern - Zone: localhost
zone "localhost" IN {
type master;
file "localhost.zone";
};
// View: intern - Zone: localhost IPv4 (reverse)
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
};
// View: intern - Zone: localhost IPv6 (reverse)
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" {
type master;
file "localhost.ip6.zone";
};
// View: intern - Zone: root server
zone "." IN {
type hint;
file "named.root";
};
// View: intern - Zone: {{ bind_zone_intranet_zonename }} (forward)
zone "{{ bind_zone_intranet_zonename }}" IN {
type master;
file "zones/{{ bind_zone_intranet_zonename }}.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_intranet_zonename }} (reverse)
zone "10.0.10.in-addr.arpa" IN {
type master;
file "zones/{{ bind_zone_intranet_zonename }}.in-addr.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_intranet_zonename }} (IPv6 ULA reverse)
zone "{{ bind_zone_intranet_ipv6reverse }}.ip6.arpa" IN {
type master;
file "zones/{{ bind_zone_intranet_zonename }}.ip6.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_idmz_zonename }} (forward)
zone "{{ bind_zone_idmz_zonename }}" IN {
type master;
file "zones/{{ bind_zone_idmz_zonename }}.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_idmz_zonename }} (reverse)
zone "0.0.10.in-addr.arpa" IN {
type master;
file "zones/{{ bind_zone_idmz_zonename }}.in-addr.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_idmz_zonename }} (IPv6 ULA reverse)
zone "{{ bind_zone_idmz_ipv6reverse }}.ip6.arpa" IN {
type master;
file "zones/{{ bind_zone_idmz_zonename }}.ip6.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_edmz_zonename }} (forward)
zone "{{ bind_zone_edmz_zonename }}" IN {
type master;
file "zones/{{ bind_zone_edmz_zonename }}.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_edmz_zonename }} (reverse)
zone "2.17.172.in-addr.arpa" IN {
type master;
file "zones/{{ bind_zone_edmz_zonename }}.in-addr.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_edmz_zonename }} (IPv6 ULA reverse)
zone "{{ bind_zone_edmz_ipv6reverse }}.ip6.arpa" IN {
type master;
file "zones/{{ bind_zone_edmz_zonename }}.ip6.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: {{ bind_zone_domain_zonename }} (forward)
zone "nausch.org" IN {
type master;
file "zones/{{ bind_zone_domain_zonename }}.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: nausch.org (reverse)
zone "13.92.217.in-addr.arpa" IN {
type master;
file "zones/nausch.org.in-addr.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: nausch.org (IPv6 GUA reverse)
zone "3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa" IN {
type master;
file "zones/nausch.org.ip6.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: omni128.de (forward)
zone "omni128.de" IN {
type master;
file "zones/omni128.de.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: ebersberger-liedersammlung.de (forward)
zone "ebersberger-liedersammlung.de" IN {
type master;
file "zones/ebersberger-liedersammlung.de.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
// View: intern - Zone: wetterstation-pliening.info (forward)
zone "wetterstation-pliening.info" IN {
type master;
file "zones/wetterstation-pliening.info.db";
inline-signing yes;
dnssec-policy "{{ bind_zone_dnssec_policy }}";
};
};
// ******************* Definition der Logging-Parameter *******************
logging {
// Definition der unterschiedlichen Kanäle
channel default_log {
file "/var/log/named/default" versions 4 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel auth_servers_log {
file "/var/log/named/auth_servers" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnssec_log {
file "/var/log/named/dnssec" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel zone_transfers_log {
file "/var/log/named/zone_transfers" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel ddns_log {
file "/var/log/named/ddns" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel client_security_log {
file "/var/log/named/client_security" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rate_limiting_log {
file "/var/log/named/rate_limiting" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rpz_log {
file "/var/log/named/rpz" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnstap_log {
file "/var/log/named/dnstap" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
// Wenn man die Kategorie "queries" definiert hat und standardmässig keine
// Abfrageprotokollierung wünscht, stellt man sicher, dass Sie die Option
// "querylog no"“ vorhanden ist. So kann man anschliessend die Abfrage-
// protokollierung mit dem Befehl "rndc querylog" ein- und ausschalten.
channel queries_log {
file "/var/log/named/queries" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
// Dieser Kanal ist dynamisch, sodass bei einer Erhöhung des Debug-Levels
// mit Hilfe von rndc bei laufendem Server zusätzliche Informationen über
// fehlgeschlagene Abfragen protokolliert werden.
// Andere Debug-Informationen für andere Kategorien werden an den Kanal
// default_debug (der ebenfalls dynamisch ist) gesendet, ohne jedoch die
// reguläre Protokollierung zu beeinträchtigen.
channel query-errors_log {
file "/var/log/named/query-errors" versions 4 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;
};
// Dies ist der Standard-Syslog-Kanal, der hier der Übersichtlichkeit
// halber definiert wurde. Man muss ihn nicht verwenden, wenn man lieber
// in eigenen Kanälen protokollieren möchte. Er sendet an die Daemon-
// Einrichtung von syslog und sendet nur protokollierte Nachrichten mit
// der Priorität "info" und höher. (Die Optionen zum Ausgeben von Zeit,
// Kategorie und Severity sind nicht standardmäßig.)
channel default_syslog {
print-time yes;
print-category yes;
print-severity yes;
syslog daemon;
severity info;
};
// Dies ist der Standard-Debug-Ausgabekanal, welcher hier aus Gründen
// der Übersichtlichkeit definiert wurde. Man kann natürlich das Ausgabe-
// ziel auch neu definieren, wenn dies nicht zu den eigenen lokalen
// Systemadministrationsplan für die Protokollierung passt. Es handelt
// sich auch um einen speziellen Kanal, der nur dann eine Ausgabe erzeugt,
// wenn der Debug-Level ungleich Null ist.
channel default_debug {
print-time yes;
print-category yes;
print-severity yes;
file "/var/log/named/named.run";
severity dynamic;
};
// Protokollieren von Routinevorgängen in Syslog und Standardprotokoll
category default { default_syslog; default_debug; default_log; };
category config { default_syslog; default_debug; default_log; };
category dispatch { default_syslog; default_debug; default_log; };
category network { default_syslog; default_debug; default_log; };
category general { default_syslog; default_debug; default_log; };
// Ab BIND 9.12 und neuer kann man die Zonenlastprotokollierung mit der
// neuen Kategorie "zoneload logging" auf einen anderen Kanal umleiten.
// Wenn dies als nützlich erachtet wird, muss man zunächst den neuen
// Kanal definieren und bearbeitet dann die folgende Zeile, um die
// Kategorie dorthin umzuleiten, anstatt sie an syslog und das Standard-
// protokoll zu senden:
category zoneload { default_syslog; default_debug; default_log; };
// Protokollnachrichten, die sich auf das beziehen, was wir während der
// Rekursion von autoritativen Servern zurückerhalten haben (z.B. wenn
// Lame-Server und deaktivierte DNS-Server andere Nachrichten verdecken,
// kann man diese an ihren eigenen Kanal oder an null gesendet werden).
// Manchmal sind diese Protokollnachrichten nützlich, um zu untersuchen,
// warum einige Domains nicht oder nicht zuverlässig aufgelöst werden.
category resolver { auth_servers_log; default_debug; };
category cname { auth_servers_log; default_debug; };
// category delegation-only { auth_servers_log; default_debug; };
category lame-servers { auth_servers_log; default_debug; };
category edns-disabled { auth_servers_log; default_debug; };
// Protokollieren von Problemen mit DNSSEC:
category dnssec { dnssec_log; default_debug; };
// Protokollieren aller Nachrichten, die sich auf die autoritative
// Zonen Propagation (Ausbreitung) beziehen.
category notify { zone_transfers_log; default_debug; };
category xfer-in { zone_transfers_log; default_debug; };
category xfer-out { zone_transfers_log; default_debug; };
// Protokollieren aller Nachrichten, die sich auf dynamische Aktualisie-
// rungen von DNS-Zonendaten beziehen.
category update{ ddns_log; default_debug; };
category update-security { ddns_log; default_debug; };
// Protokollieren aller Nachrichten, die sich auf den Client-Zugriff und
// die Sicherheit beziehen. (Es gibt eine zusätzliche Kategorie "unmatched",
// die standardmässig an null gesendet wird, aber hier hinzugefügt werden
// kann, wenn man mehr als die einzeilige Zusammenfassung wünscht, die für
// Fehler bei der Zuordnung zu einer Ansicht protokolliert wird).
category client{ client_security_log; default_debug; };
category security { client_security_log; default_debug; };
// Protokollieren aller Nachrichten, die wahrscheinlich mit der Rate-Limiting
// zusammenhängen. Dies umfasst RRL (Response Rate Limiting) – wird normaler-
// weise auf autorisierenden Servern und Abrufen pro Server/Zone eingesetzt.
// Hierbei ist zu beachten, dass dies nicht die Protokollierung von Änderun-
// gen für Clients pro Abfrage umfasst (die im Cateory Resolver protokolliert
// werden). Wichtig ist hier auch, dass gelegentlich andere Protokollnach-
// richten von der Datenbankkategorie ausgegeben werden können, die sich
// nicht auf das Rate-Limiting Verhalten von named beziehen.
category rate-limit { rate_limiting_log; default_debug; };
category spill { rate_limiting_log; default_debug; };
category database { rate_limiting_log; default_debug; };
// Protokollieren von DNS-RPZ-Meldungen (Response Policy Zone), sofern DNS-
// -RPZ nicht verwendet wird, kann man diese Kategorie und den zugehörigen
// Kanal auskommentieren.
category rpz { rpz_log; default_debug; };
// Protokollnachrichten zum DNS-Verkehrserfassungssystem "dnstap". (Wenn
// man dnstap nicht verwenden will, muss man diese Kategorie und den zugehö-
// rigen Kanal auskommentieren).
category dnstap { dnstap_log; default_debug; };
// Sofern mane einen Server betreiben (z. B. einen der Internet-Root-Name-
// server), der RFC 5011-Vertrauensanker-Updates bereitstellt, dann ist es
// unter Umständen von Interesse, die Vertrauensanker-Telemetrieberichte zu
// protokollieren, die der Server empfängt, um die Trust Anchor Propagierungs-
// raten während eines Schlüsselwechsels zu analysieren.
// Erachtet man dies als nützlich, konfiguriert man zunächst den neuen Kanal
// und entfernt dann das Kommentarzeichen und die folgende Zeile, um die
// Kategorie dorthin zu leiten, anstatt zu syslog und default log:
category trust-anchor-telemetry { default_syslog; default_debug; default_log; };
// Wenn man die Kategorie "queries" definiert hat und standardmäßig keine Ab-
// frageprotokollierung wünschen, muss man sicherstellen, dass Sie die Option
// "querylog no"“ hinzufügt wurde. Anschliessend kann man da die Abfrageproto-
// kollierung mit dem Befehl "rndc querylog" ein- und wieder ausschalten.
category queries { queries_log; };
// Diese Protokollkategorie gibt nur Meldungen auf Debug-Ebene 1 oder höher
// aus. Sie kann bei der Fehlerbehebung nützlich sein, wenn Abfragen zu einer
// SERVFAIL-Antwort führen.
category query-errors { query-errors_log; };
};
Für die Erstellung der Zone-Files im Verzeichnis /var/named/zones benötigen wir nun noch jeweils ein Jinja2 Templates.
$ vim roles/bind/templates/0.0.10.in-addr.arpa.zone.db.j2
$TTL {{ bind_nausch_org_ip6_db_default_ttl }} ; Defaultwert für die TTL
@ IN SOA ns1 {{ bind_nausch_org_ip6_db_email }} (
{{ bind_nausch_org_ip6_db_serial }} ; serial - Seriennummer im Format YYYYMMDDnn
{{ bind_nausch_org_ip6_db_refresh }} ; refresh (1 Stunde)
{{ bind_nausch_org_ip6_db_retry }} ; retry (15 Minuten)
{{ bind_nausch_org_ip6_db_expire }} ; expire (2 Wochen)
{{ bind_nausch_org_ip6_db_caching }} ) ; negative caching TTL (10 Minuten)
IN NS ns1.{{ guest_zone_1 }}
IN MX 10 mx1.{{ guest_zone_1 }}
ns1.{{ guest_zone_1 }} IN A {{ guest_ip4_1 }}
IN AAAA {{ guest_ip6_ula_1 }}
mx1.{{ guest_zone_1 }} IN A {{ bind_nausch_org_db_mx1_ipv4 }}
IN AAAA {{ bind_nausch_org_db_mx1_ipv6 }}
$ORIGIN 0.0.0.0.0.0.0.0.0.1.0.0
1.0.0.0 IN PTR fwa.nausch.org.
5.2.0.0 IN PTR mx1.nausch.org.
3.5.0.0 IN PTR ns1.nausch.org.
0.1.1.0 IN PTR pop3.nausch.org.
3.4.1.0 IN PTR imap.nausch.org.
3.9.9.0 IN PTR imaps.nausch.org.
5.9.9.0 IN PTR pop3s.nausch.org.
{% for item in bind_external_host_cnames %}
{{ item.ipv6_ula | ansible.utils.ipaddr('revdns') | truncate(7, True, '', 0) }} IN PTR {{item.name}}.{{ guest_domain }}.
{% endfor %}
2.4.2.4 IN PTR lists.nausch.org.
Ausführung - Playbooklauf
Die orchestrierte Variante der Installation und Konfiguration unserer kea-Daemon gestaltet sich ab sofort sehr einfach, brauchen wir doch lediglich die Konfigurationswerte im Inventory zu hinterlegen und zu pflegen und letztendlich das Playbook entsprechend aufzurufen, wenn z.B. ein Client im Intranet hinzugefügt, entfernt oder ausgetauscht wird:
$ ansible-playbook playbooks/kea_dhcp.yml
[15:16:47] Gathering Facts
↳ vml010110 | SUCCESS | 2.06s
[15:16:49] bind : Installation des BIND-Servers.
↳ vml010110 | SUCCESS | 33ms
[15:16:49] ↳ install: Installation der benötigten bind Paketes.
↳ vml010110 | CHANGED | 4.05s
[15:16:53] bind : Grundkonfiguration des BIND-Servers.
↳ vml010110 | SUCCESS | 18ms
[15:16:53] ↳ grundkonfiguration: Checken ob es bereits eine Datei /etc/rndc.key gibt.
↳ vml010110 | SUCCESS | 737ms
[15:16:54] ↳ grundkonfiguration: Individuellen Schlüssel für rndc erzeugen und ablegen.
↳ vml010110 | SUCCESS | 767ms
[15:16:54] ↳ grundkonfiguration: Berechtigungen der Schlüssel-Datei /etc/rndc.key sicherstellen.
↳ vml010110 | CHANGED | 760ms
[15:16:55] ↳ grundkonfiguration: Checken ob es bereits eine Datei /var/named/named.root gibt.
↳ vml010110 | SUCCESS | 660ms
[15:16:56] ↳ grundkonfiguration: Liste der 13 Root-Nameserver holen und ablegen..
↳ vml010110 | SUCCESS | 746ms
[15:16:57] ↳ grundkonfiguration: Sicherstellen dass die Datei named.root existiert.
↳ vml010110 | CHANGED | 683ms
[15:16:57] ↳ grundkonfiguration: Liste der zuvor erstellten 13 Root-Name-Server in /var/named/named.root ablegen.
↳ vml010110 | CHANGED | 1.40s
[15:16:59] ↳ grundkonfiguration: Sicherstellen dass das Verzeichnis für die Zonendateien existiert.
↳ vml010110 | CHANGED | 649ms
[15:16:59] ↳ grundkonfiguration: Sicherstellen dass das Verzeichnis für die externen Zonendateien existiert.
↳ vml010110 | CHANGED | 692ms
[15:17:00] bind : Konfiguration der BIND-Zonen für die Domain nausch.org.
↳ vml010110 | SUCCESS | 20ms
[15:17:00] ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone intra.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.50s
[15:17:02] ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone intra.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.45s
[15:17:03] ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone intra.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.56
[15:17:05] ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone idmz.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.37s
[15:17:06] ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone idmz.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.31s
[15:17:07] ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone idmz.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.46s
[15:17:09] ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone edmz.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.29s
[15:17:10] ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone edmz.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.29s
[15:17:12] ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone edmz.nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.40s
[15:17:13] ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.46s
[15:17:14] ↳ zonefiles_nausch: Zonen Datei für IPv4 Reverse Auflösung der Zone nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.29s
[15:17:16] ↳ zonefiles_nausch: Zonen Datei für IPv6 Reverse Auflösung der Zone nausch.org erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.41s
[15:17:17] ↳ zonefiles_nausch: Zonen Datei für IPv4|6 Forward Auflösung der Zone nausch.org für core-networks.de erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.45s
[15:17:19] bind : Konfiguration der BIND-Zone für die Domain omni128.de.
↳ vml010110 | SUCCESS | 15ms
[15:17:19] ↳ zonefiles_omni128.de: Zonen Datei für IPv4|6 Forward Auflösung Domain omni128.de erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.41s
[15:17:20] ↳ zonefiles_omni128.de: Zonen Datei für IPv4 Reverse Auflösung der Zone omni128.de für core-networks.de erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.45s
[15:17:21] bind : Konfiguration der BIND-Zone für die Domain ebersberger-liedersammlung.de.
↳ vml010110 | SUCCESS | 26ms
[15:17:21] ↳ zonefiles_liedersammlung: Zonen Datei für IPv4|6 Forward Auflösung Domain ebersberger-liedersammlung.de erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.23s
[15:17:23] ↳ zonefiles_liedersammlung: Zonen Datei für IPv4|6 Forward Auflösung der Zone ELS für core-networks.de erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.33s
[15:17:24] Konfiguration der BIND-Zone für die Domain wetterstation-pliening.info.
↳ vml010110 | SUCCESS | 16ms
[15:17:24] ↳ zonefiles_wetterstation: Zonen Datei für IPv4|6 Forward Auflösung Domain wetterstation-pliening.info für die interne view erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.36s
[15:17:25] ↳ zonefiles_wetterstation: Zonen Datei für IPv4|6 Forward Auflösung der Domain wetterstation-pliening.info für core-networks.de erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.22s
[15:17:27] bind : Sichern der Zonefiles für externen DNS.
↳ vml010110 | SUCCESS | 15ms
[15:17:27] ↳ fetchzonefiles: Erstelltes Zonefile für die Domain nausch.org holen.
↳ vml010110 | SUCCESS | 710ms
[15:17:27] ↳ fetchzonefiles: Erstelltes Zonefile für die Domain ebersberger-liedersammlung.de holen.
↳ vml010110 | SUCCESS | 681ms
[15:17:28] ↳ fetchzonefiles: Erstelltes Zonefile für die Domain omni128.de holen.
↳ vml010110 | SUCCESS | 701ms
[15:17:29] ↳ fetchzonefiles: Erstelltes Zonefile für die Domain wetterstation-pliening.info holen.
↳ vml010110 | SUCCESS | 658ms
[15:17:29] bind : Konfiguration des BIND-Servers.
↳ vml010110 | SUCCESS | 36ms
[15:17:29] ↳ konfiguration: Checken ob es bereits eine Backupdatei named.conf gibt.
↳ vml010110 | SUCCESS | 632ms
[15:17:30] ↳ konfiguration: Backupdatei der Konfigurationsdatei named.conf erstellen.
↳ vml010110 | CHANGED | 681ms
[15:17:31] ↳ konfiguration: Individuelle Konfigurationsdatei named.conf erzeugen und kopieren.
↳ vml010110 | CHANGED | 1.34s
[15:17:32] ↳ konfiguration: Verzeichnis für die private und public DNSSEC-Schlüssel erstellen.
↳ vml010110 | CHANGED | 703ms
[15:17:33] ↳ konfiguration: Caching-Verzeichnis für die verwalteten DNSSEC-Schlüssel erstellen.
↳ vml010110 | CHANGED | 673ms
[15:17:34] ↳ konfiguration: Data-Dump-Verzeichnis erstellen.
↳ vml010110 | SUCCESS | 706ms
[15:17:34] ↳ konfiguration: Sicherstellen, dass der BIND Daemon reboot(-fest) startet.
↳ vml010110 | CHANGED | 673ms
[15:17:35] ↳ konfiguration: Logging-Verzeichnis erstellen.
↳ vml010110 | SUCCESS | 706ms
[15:17:36] ↳ konfiguration: Data-Dump-Verzeichnis erstellen.
↳ vml010110 | SUCCESS | 679ms
[15:17:36] bind : Konfiguration der firewalld-Regeln für den BIND.
↳ vml010110 | SUCCESS | 1.18ms
[15:17:36] ↳ firewalld: Konfiguration der firewalld Regeln in Zone_1 für den BIND-Server.
↳ vml010110 | SUCCESS | 7.74s
[15:17:44] ↳ firewalld: Konfiguration der firewalld Regeln in Zone_2 für den BIND-Server.
↳ vml010110 | SUCCESS | 7.82s
[15:17:52] ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.
↳ vml010110 | CHANGED | 979ms
triggering handler | bind : Restart bind
↳ vml010110 | CHANGED | 1.78s
[15:17:54] system
-- Play recap --
vml010110 : ok=55 changed=32 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
In diesem Beispiel haben wir nach nicht einmal 70 Sekunden einen voll funktionsfähigen DNSSEC-fähigen Namserver für vier Domains mit sehr umfangreichen 20 Zonefiles mit bis zu 800 Zeilen in einem Zone-File, die nun wirklich niemand mehr manuell pflegen will. Die automatisierte Erstellung dieser Zonefiles aus den Daten des Inventories hat unscheinbare Vorteile. Man hat sauber formatierte Zonefiles mit aktuellen Daten und die Fehleranfälligkeit durch manuelles Editieren ist auf ein Mindestmaß begrenzt und es gibt auch keine unterschiedlichen Meinungen mehr im Admin-Team ob nun so ein Zonefile mit TABs oder SPACEes formatiert werden soll! ;)
Ergebniskontrolle
Ob die Konfigurationsdateien valide erstellt und auch von den Kea-Daemons erfolgreich geladen worden sind, kontrollieren wir zum Beispiel auf dem Zielhost mit einem Blick in die betreffenden Konfigurationsdateie, mit Prüfung der erstellten Zonefiles und mit Hilfe der systemctl status-Abfrage des betreffenden named-Daemons.
named-checkconf
# named-checkconf /etc/named.conf
named-checkzone
# root@vml000110:~# named-checkzone edmz.nausch.org /var/named/zones/edmz.nausch.org.db
zone edmz.nausch.org/IN: loaded serial 2026011201
OK
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
BIND1) des Internet Systems Consortium ist eine Software, die für die Ausführung der Aufgabe des DNS-Servers verantwortlich ist. Bind ist derzeit ein Standard und wird häufig in Linux-Betriebssystemen und auch in Unix verwendet.
ist das Äquivalent für die IPv6-Adresszuweisung, was eben der 
Es wird die 
Wir bekommen bei der Frage nach der IPv4- oder auch der IPv6-Adresse keine Antwort, da in der view diese Adressen exkludiert wurden! 
django