Installation Bind Nameserver (DNS)

Analog zur FreeBSD Installation, hier die Anleitung unter Ubuntu.

Installation

sudo apt-get install bind9 bind9utils

Konfiguration

Die Startup Optionen kann man bei Bedarf im File /etc/default/bind9 anpassen.

Grundsätzlich mache ich dieselbe Konfiguration wie unter FreeBSD (siehe Tutorial). Beachte, dass das Verzeichnis unter Ubuntu nicht /etc/namedb lautet, sondern /etc/bind.

Dann gibt es noch weitere Besonderheiten unter Ubuntu:

Logfiles

sudo mkdir /var/log/bind
sudo touch /var/log/bind/error.log
sudo chown -R bind:bind /var/log/bind/
sudo chmod 755 /var/log/bind/
sudo chmod 644 /var/log/bind/*

Location der Logfiles im named.conf  (bzw. im entsprechenden Template) noch entsprechend anpassen:

{...}

channel error_logging {
       file "/var/log/bind/error.log"
       versions 3 size 20M; 
       print-time yes;
       print-category yes;
};

Berechtigungen

Da ich alle Files im /etc/bind Verzeichnis habe und das Verzeichnis/var/cache/bind nicht verwende, sowie die Logfiles auslagere, müssen diverse Anpassungen im AppArmor gemacht werden.

Das Default Config File für AppArmor ist /etc/apparmor.d/usr.sbin.named

hier am Ende den Include der Custom Config aktivieren:

sudo vi /etc/apparmor.d/usr.sbin.named
{...}

  # Site-specific additions and overrides. See local/README for details.
  #include <local/usr.sbin.named>
  include <local/usr.sbin.named>
}

Nun die eigenen Rules im Custom File definieren:

sudo vi /etc/apparmor.d/local/usr.sbin.named 
# Site-specific additions and overrides for usr.sbin.named.
# For more details, please see /etc/apparmor.d/local/README.
#
# Infos zu den Berechtigungen unter Profilaufbau:
# https://wiki.ubuntuusers.de/AppArmor/
#
# Ausgelagerte Logfiles
/var/log/bind/** rw,
/var/log/bind/ rw,
# Zones (analog zu /var/cache/bind)
/etc/bind/zones/** lwr,
/etc/bind/zones/ rw,
# TMP Files
/etc/bind/tmp-* rw,
# restliches
  /proc/*/task/*/comm rw,
  /etc/bind/_bind.nta rw,
  /etc/bind/_default.nta rw,

Service restarten

sudo service apparmor stop 
sudo service apparmor start

Apparmor Fehlermeldungen

Nach wie vor sind trotzdem noch Fehlermeldungen aufgetaucht:

Jun 8 11:48:35 patsy kernel: [5017625.547357] audit: type=1400 audit(1654681715.445:384): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/_default.nta" pid=2548471 comm="named" requested_mask="c" denied_mask="c" fsuid=123 ouid=123
Jun 8 11:48:35 patsy kernel: [5017625.547360] audit: type=1400 audit(1654681715.445:385): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/_bind.nta" pid=2548471 comm="named" requested_mask="c" denied_mask="c" fsuid=123 ouid=123
Jun 8 11:48:35 patsy kernel: [5017625.643739] audit: type=1400 audit(1654681715.541:386): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/proc/2549756/task/2549772/comm" pid=2549756 comm="named" requested_mask="wr" denied_mask="wr" fsuid=123 ouid=123

hier also auch einfach alles durchgehen und die entsprechenden Zeilen in

vi /etc/apparmor.d/local/usr.sbin.named

ergänzen. In dem Fall:

# restliches
/proc/*/task/*/comm rw,
/etc/bind/_bind.nta rw,
/etc/bind/_default.nta rw,

Und Service restarten

sudo service apparmor stop 
sudo service apparmor start

/etc/resolv.conf

Bisher hat man im resolv.conf jeweils in der ersten Zeile den localhost (127.0.0.1) eingetragen, danach die restlichen Nameserver. So wird, wenn man einen eigenen Nameserver betreibt, zuerst auf dem eigenen Server gesucht, danach werden entfernte Nameserver abgefragt, falls der eigene Server keine Resultate bringen konnte.

Mittlerweile wird jedoch das File automatisch von resolvconf generiert – somit würden manuelle Änderungen an diesem File überschrieben werden. So hätte das File zum Beispiel so aussehen können:

nameserver 127.0.0.1
nameserver 111.222.33.44
nameserver 222.333.44.55
search mysearchdomain1.com mysearchdomain2.com

Heute macht man keine manuellen Änderungen mehr im resolv.conf File!

Stattdessen nutzt man dazu einfach das bind9 Startup Configfile:

sudo vi /etc/default/bind9 

und setze RESOLVCONF auf yes:

# run resolvconf?
RESOLVCONF=yes

und jetzt Bind restarten:

sudo service bind9 restart

Bug in Ubuntu 16.0.4

Nun müsste bei einer nslookup Abfage als erstes der localhost antworten, tut es aber nicht *grummel*

root@patsy:~/.ssh# nslookup teslina.com
Server: 178.22.66.167
Address: 178.22.66.167#53

Non-authoritative answer:
Name: teslina.com
Address: 178.22.71.83
root@patsy:~/.ssh# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 178.22.66.167
nameserver 178.22.71.56
nameserver 162.213.38.38

Obwohl man RESOLVCONF=yes setzt, wird das resolv.conf nicht korrekt geupdated (127.0.0.1 fehlt, nur die per DHCP erhaltenen Nameserver sind aufgelistet).

Der Bug wird hier erklärt.

Fix:

sudi mkdir /etc/systemd/system/bind9-resolvconf.service.d/
sudo vi /etc/systemd/system/bind9-resolvconf.service.d/fix-744304.conf
# systemd drop-in for bind9-resolvconf.service
# Fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744304
#
[Service]
RemainAfterExit=yes

und noch den Service restarten:

sudo systemctl enable bind9-resolvconf.service

und jetzt Bind restarten:

sudo service bind9 restart

Nun wird das resolv.conf korrekt generiert:

root@patsy:/etc/systemd/system$ nslookup teslina.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: teslina.com
Address: 178.22.71.83
root@patsy:/etc/systemd/system$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

Searchdomain

Falls man jetzt noch eine DNS-Searchdomain (wie im oberen Beispiel myserverdomain.com) hinzufügen möchte, kann man das hier:

sudo vi /etc/network/interfaces

und unterhalb iface lo den dns-search einfügen

# The loopback network interface
auto lo
iface lo inet loopback
dns-search mysearchdomain1.com mysearchdomain2.com

Und interface neu starten

ifdown lo; ifup lo

Referenz: askubuntu.com

 

Bind starten/stoppen

sudo service bind9 {start|stop|reload|restart|force-reload|status}

Logfiles

sudo tail -f /var/log/syslog
sudo tail -f /var/log/bind/error.log

 

 

Fehlermeldungen

isc_stdio_open ‚/var/log/bind/error.log‘ failed: permission denied

Jun 28 10:32:57 patsy named[24253]: configuring command channel from '/etc/bind/rndc.key'
Jun 28 10:32:57 patsy named[24253]: command channel listening on 127.0.0.1#953
Jun 28 10:32:57 patsy named[24253]: configuring command channel from '/etc/bind/rndc.key'
Jun 28 10:32:57 patsy named[24253]: command channel listening on ::1#953
Jun 28 10:32:57 patsy systemd[1]: bind9.service: Main process exited, code=exited, status=1/FAILURE
Jun 28 10:32:57 patsy named[24253]: the working directory is not writable
Jun 28 10:32:57 patsy named[24253]: isc_stdio_open '/var/log/bind/error.log' failed: permission denied
Jun 28 10:32:57 patsy named[24253]: configuring logging: permission denied
Jun 28 10:32:57 patsy named[24253]: loading configuration: permission denied
Jun 28 10:32:57 patsy named[24253]: exiting (due to fatal error)
Jun 28 10:32:57 patsy rndc[24260]: rndc: connect failed: 127.0.0.1#953: connection refused
Jun 28 10:32:57 patsy systemd[1]: bind9.service: Control process exited, code=exited status=1
Jun 28 10:32:57 patsy systemd[1]: bind9.service: Unit entered failed state.
Jun 28 10:32:57 patsy systemd[1]: bind9.service: Failed with result 'exit-code'.

Daran hatte ich jetzt lange zu kauen, denn es waren alle Permissions korrekt gesetzt (Das Verzeichnis /var/log/bind mit bind:bind 755 / und die Logfiles selber mit bind:bind 644)

Das Problem wurde durch den Service AppArmor verursacht. Wenn man den killt, klappts!

service bind9 stop
service apparmor teardown
service bind9 start

Ich habe die Konfiguration im Tutorial soweit angepasst, dass AppArmor berücksichtigt wird – ohne dass man AppArmor deinstallieren muss.

Referenzen:

/etc/apparmor.d/usr.sbin.named

BIND9 startet nicht – keine offensichtliche Fehlermeldungen

Versuch zuerst mit

service bind9 status

herauszufinden, ob es irgendwo offensichtliche Probleme gibt. Im aktuellen Fall war das hier leider nicht sehr hilfreich:

● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2023-10-16 10:01:21 CEST; 1min 16s ago
Docs: man:named(8)
Process: 775200 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE)
Main PID: 775200 (code=exited, status=1/FAILURE)

Okt 16 10:01:21 patsy.nameserver.com systemd[1]: named.service: Scheduled restart job, restart counter is at 5.
Okt 16 10:01:21 patsy.nameserver.com systemd[1]: Stopped BIND Domain Name Server.
Okt 16 10:01:21 patsy.nameserver.com systemd[1]: named.service: Start request repeated too quickly.
Okt 16 10:01:21 patsy.nameserver.com systemd[1]: named.service: Failed with result 'exit-code'.
Okt 16 10:01:21 patsy.nameserver.com systemd[1]: Failed to start BIND Domain Name Server.

Hilfreich war jedoch das syslog. Stoppe und Starte Bind und beobachte das syslog:

tail -f /var/log/syslog
service bind9 stop
service bind9 start
Oct 16 10:00:43 patsy named[775004]: loading configuration from '/etc/bind/named.conf'
Oct 16 10:00:43 patsy named[775004]: /etc/bind/named.conf:30: option 'directory' contains relative path ''
Oct 16 10:00:43 patsy named[775004]: directory '' is not writable
Oct 16 10:00:43 patsy named[775004]: /etc/bind/named.conf:30: parsing failed: permission denied
Oct 16 10:00:43 patsy named[775004]: loading configuration: permission denied
Oct 16 10:00:43 patsy named[775004]: exiting (due to fatal error)
Oct 16 10:00:43 patsy systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE
Oct 16 10:00:43 patsy systemd[1]: named.service: Failed with result 'exit-code'.
Oct 16 10:00:44 patsy systemd[1]: named.service: Scheduled restart job, restart counter is at 1.
Oct 16 10:00:44 patsy systemd[1]: Stopped BIND Domain Name Server.

Das Problem war hier das Auto-Generation Script für die DNS Zonen (was das named.conf generiert). Es hatte ein leeres Working Directory ins Config File geschrieben. Nachdem der Fehler behoben war, startete Bind wieder normal.

.

nach oben