Installation Bind Nameserver (DNS)

Installation

Die Grundinstallation erfolgt auf beiden Servern (ns1 und ns2).

pkg install bind918

Nun im /etc/rc.conf eintragen:

#-----------------------------------------------#
#       DNS Server                              #
#-----------------------------------------------#
named_enable="YES"
named_chrootdir="/var/named/chroot"   # Pfad zum gewünschten Jail Verzeichnis
named_chroot_autoupdate="YES"         # Automatically install/update chrooted components of named.
named_symlink_enable="NO"             # symlink the chrooted pid file

• Ich lasse Bind in einer Jailed Umgebung laufen, daher muss man hier das Chroot Verzeichnis angeben, ich habe als Verzeichnis named_chrootdir="/var/named/chroot" gewählt.
• Der named_symlink_enable="YES" Eintrag ist optional und kann verwendet werden, um Symlinks zu erstellen, die für die Logdateien nützlich sein können.

Da ich Bind in einer jailed Umgebung installiere, muss ich für syslog noch ein log socket installieren:

sysrc altlog_proglist+=named

und syslog neu starten

service syslogd restart

Verzeichnisse erstellen

Quickinstall bei Serverwechsel (Wenn Zone Files etc. bereits vorhanden sind)

Nach einer frischen Installation unter FreeBSD befinden sich die Configfiles hier:

/usr/local/etc/namedb

Ich erstelle nun einen Symlink, da ich mich gewohnt bin, named im /etc/namedb zu haben:

ln -s /usr/local/etc/namedb/ /etc/namedb

Nun erstelle ich das Verzeichnis für die chroot-Umgebung: Ich wähle /var/named/chroot als Basisverzeichnis.

mkdir -p /var/named/chroot

Bestehende Verzeichnisse kopieren (falls vorhanden):

cd /etc/namedb
mv named.conf named.conf-dist
scp -pr username@oldserver:/etc/namedb/* .
chown -R bind:wheel * 

Unbedingt darauf achten, dass named.conf ein Symlink ist. Kann beim Kopieren verloren gehen. Es muss also so aussehen, dann ist gut:

drwxr-xr-x  11 root  wheel   512 Feb  2 09:25 ./
drwxr-xr-x   3 root  wheel   512 Feb  2 09:28 ../
drwxr-xr-x   2 root  wheel   512 Feb  2 09:34 config/
drwxr-xr-x   2 bind  wheel   512 Feb  2 09:20 dynamic/
drwxr-xr-x   2 root  wheel   512 Jul 19  2010 master/
lrwxr-xr-x   1 root  wheel    17 Feb  2 09:25 named.conf@ -> config/named.conf
-rw-r--r--   1 root  wheel  2515 May 19  2007 named.root
-r--r--r--   1 root  wheel  1211 May 19  2007 rndc.conf.sample
-rw-------   1 root  wheel    77 May 19  2007 rndc.key
drwxr-xr-x   2 bind  wheel   512 Feb  2 09:20 slave/
drwxr-xr-x   2 root  wheel   512 Feb  2 09:20 tools/
drwxr-xr-x   2 bind  wheel   512 Jul 19  2010 working/
drwxr-xr-x   4 root  wheel   512 Feb  2 09:20 zones/
root@patsy(/var/named/chroot/usr/local/etc/namedb)> 

named.conf.template anpassen -> neue IP Adresse des / der Server updaten. Ausserdem schauen, dass die logs nur auf /var/log zeigen, da das Startup Script keine weiteren Sub-Verzeichnisse im Logfolder erstellt.

vi /etc/namedb/config/named.conf.template

Passe die Pfade in deiner BIND-Konfiguration (named.conf und etwaige inkludierte Dateien) an, sodass sie auf die korrekten Pfade verweisen. Beachte: du musst nix beachten bezüglich des Chrooted Verzeischnisses. FreeBSD wird beim Start von Bind alle nötigen Anpassungen machen.

Beispiel für die Logging Settings im named.conf

logging
{
   channel bind_log {
    file "/var/log/bind.log" versions 3 size 5m;
    severity info;
    print-time yes;
    print-severity yes;
    print-category yes;
   };
   category default { bind_log; };

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

   channel resolver_file {
    file "/var/log/bind-resolver.log" versions 3 size 5m;
    severity dynamic;
    print-time yes;
   };
   category resolver { resolver_file; };
}

Jetzt noch das Verzeichnis für die Logfiles verlinken:

cd /var/log
ln -s /var/named/chroot/var/log/ bind

Sobald named gestartet wird, werden die logs in das /var/log von der Jailed Umgebung gespeichert.

Sie befinden sich also hier:

/var/named/chroot/var/log/

da ich einen Symlink drauf habe, finde ich die Logs nun auch normal über

/var/log/bind 

auslesen.

Starten

service named start

Testen

Überprüfe, ob BIND korrekt läuft und ob es innerhalb der chroot-Umgebung ausgeführt wird:

sockstat -4l | grep :53

Dies zeigt dir, welche Anwendungen auf Port 53 (DNS) lauschen. Du solltest Einträge sehen, die named zugeordnet sind:

bind named 1841 54 udp4 127.0.0.1:53 *:*
bind named 1841 55 udp4 127.0.0.1:53 *:*
bind named 1841 56 udp4 127.0.0.1:53 *:*
bind named 1841 57 tcp4 127.0.0.1:53 *:*
bind named 1841 58 tcp4 127.0.0.1:53 *:*
bind named 1841 59 tcp4 127.0.0.1:53 *:*

Nameserver auf localhost anpassen

after install, please edit:

/etc/resolv.conf

Hier muss der Localhost rein: 127.0.0.1

Inzwischen wird resolv.conf nur noch von resolvconf generiert – somit werden manuelle Änderungen an /etc/resolv.conf bei jedem Reboot überschrieben. Damit man den Localhost eintragen kann, wie folgt vorgehen:

Nun die dhclient.conf bearbeiten. Und dann die Server eintragen.

vi /etc/dhclient.conf

folgendes Eintragen

prepend domain-name-servers 127.0.0.1;

und nun Interface restarten, damit Config übernommen wird:

service dhclient restart vtnet0

Nun ist die gewünschte Zeile drin:

$ cat /etc/resolv.conf 

# Generated by resolvconf
nameserver 127.0.0.1

ns1

Folgender Abschnitt betrifft nur den Master Server (ns1)

Zonen generieren und auf den Secondary übertragen

/etc/namedb/config/generate-zones.sh

ns2

Folgender Abschnitt betrifft nur den Slave Server (ns2)

Login für secondary Files Transfer

Auf dem Secondary Login für User Bind mit SSH Key forcieren (Passwort Login abschalten):

vi /etc/ssh/sshd_config

Am Ende des Files folgendes eintragen:

Match User bind
    PasswordAuthentication no

Und sshd restarten:

/etc/rc.d/sshd restart

Nun dem User BIND den Zugriff auf die Bash und Homeverzeichnis geben:

vipw

Zeile anpassen

bind:*:53:53::0:0:Bind Sandbox:/etc/namedb:/usr/local/bin/bash
#bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin

Der authorized_keys wird im Verzeichnis

/etc/namedb/.ssh 

gespeichert

Damit der Primary DNS Server auf den Secondary connecten kann, ohne User & Passwort eingeben zu müssen, muss noch ein Public Key erzeugt werden:

Auf Primary

ssh-keygen

copy inhalt von /root/.ssh/id_rsa.pub Primary ins /etc/namedb/.ssh/authorized_keys von Secondary

Auf Secondary

chown -R bind:wheel /etc/namedb/.ssh/authorized_keys
chmod 600 /etc/namedb/.ssh/authorized_keys

Secondary Verzeichnisstruktur

cd /etc/namedb
mkdir config
mkdir /var/log/bind
mkdir working/secondary
mkdir working/secondary/diverses
mkdir working/secondary/shoe
chown -R bind:bind config/
chown -R bind:bind /var/log/bind/
chown -R bind:bind working/secondary/
cd config
ln -s secondary.file named.conf

cd /etc/namedb
mv named.conf named.conf-sample
ln -s config/named.conf named.conf

Starten

Anschliessend muss man nur noch den Server neu starten oder den DNS Service:

service named start

Output:

wrote key file "/etc/namedb/rndc.key"
wrote key file "/var/named/etc/namedb/rndc.key"
Starting named.

Sollte man Probleme haben, so findet man in den Bind9 Manual Pages einige Unterstützung.

Testen

dig shoe.org @localhost
dig test.com @localhost
dig blick.ch @localhost

Diverses

named.root aktualisieren

Erscheinen solche Fehlermeldungen, sollte man das named.root aktualisieren.

Mar 4 10:50:42 violet-new named[1680]: checkhints: b.root-servers.net/A (170.247.170.2) missing from hints
Mar 4 10:50:42 violet-new named[1680]: checkhints: b.root-servers.net/A (199.9.14.201) extra record in hints
Mar 4 10:50:42 violet-new named[1680]: checkhints: b.root-servers.net/AAAA (2801:1b8:10::b) missing from hints
Mar 4 10:50:42 violet-new named[1680]: checkhints: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

Backup machen des bestehenden Files und das aktuelle runterladen:

cd /etc/namedb
cp named.root named.root.bk
wget --user=ftp --password=ftp ftp://ftp.rs.internic.net/domain/db.cache -O /etc/namedb/named.root
service named restart

DNS bei Switch / internetbs registrieren

Switch

• Mit der eigenen SWITCH UserID einloggen > Name-Server > Registrieren
• Nameserver eintragen

internetbs.net

• In der domainliste den root domain des DNS servers suchen und auswählen.
• auf EXPERTE tab klicken
• Erstellen / Aktualisieren des Nameservers
• IP Adresse aktualisieren.

Fehlermeldungen

the working directory is not writable

Das Problem ist das Verzeichnis

/etc/namedb/working

drwxr-xr-x   2 bind  wheel   512 Jul 19  2010 working/

Das Problem ist, dass es nichts nützt, wenn ich es auf chown bind:bind setze, da bei einem restart des dns Servers, die Permissions wieder auf root gesetzt sind. Man kann diesen Fehler aber einfach ignorieren. Das working Directory wurde noch nie benutzt oder benötigt – bei unserer Config auf jedenfall. Der Fehler taucht erst seit neueren Bind Versionen auf. Hab gegoogelt und die meisten sagen, dass das einfach eine nervige Info sei, die man aber wirklich ignorieren könne.

checkhints: l.root-servers.net/A (xxx.x.xx.xx) missing from hints

Manchmal kann es im

/var/log/messages

zu solchen Fehlermeldungen kommen:

Feb 12 04:37:57 shoe named[4722]: checkhints: l.root-servers.net/A (199.7.83.42) missing from hints
Feb 12 04:37:57 shoe named[4722]: checkhints: l.root-servers.net/A (198.32.64.12) extra record in hints

Das bedeutet, dass das Root-Server File etwas veraltet ist und es neue Root Server gibt, die man lokal in /etc/namedb/named.root

speichern sollte.
/etc/namedb/named.root

Das aktuellste File kann man hier herunterladen und bestehendes damit überschreiben.

fetch ftp://ftp.internic.net/domain/named.root

Danach Nameserver neu starten.

managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found

hier kann man einfach das File erstellen, wenn es nicht vorhanden ist:

touch /etc/namedb/managed-keys.bind
chown bind:wheel /etc/namedb/managed-keys.bin

could not listen on UDP socket: permission denied

Nach einem Server Reboot gab’s die folgenden Fehlermeldungen:

Jul 12 15:00:13 violet named[643]: could not listen on UDP socket: permission denied
Jul 12 15:00:13 violet named[643]: creating IPv4 interface vtnet0 failed; interface ignored

Nach einem

service named restart

hat zunächst wieder alles funktioniert. Ein halbes Jahr später hatte ich das selbe Problem plötzlich wieder, doch restarts halfen nur kurzfristig. Oft trat das Problem ein paar Stunden später wieder auf.

Lösung:

Auf dem Server gibt der dhcclient regelmässig, diese Info aus:

Feb 6 22:48:31 violet dhclient: New IP Address (vtnet0): xx.xxx.xxx.xxx
Feb 6 22:48:31 violet dhclient: New Subnet Mask (vtnet0): 255.255.252.0
Feb 6 22:48:31 violet dhclient: New Broadcast Address (vtnet0): xx.xx.xxx.xxx
Feb 6 22:48:31 violet dhclient: New Routers (vtnet0): xx.xxx.xxx.x
Feb  6 22:56:24 violet named[9990]: could not listen on UDP socket: permission denied
Feb  6 22:56:24 violet named[9990]: creating IPv4 interface vtnet0 failed; interface ignored

Dies führt dazu, dass named sich nach dem interface scan nicht mehr selber restarten kann, da es ursprünglich als root gestartet wurde. (hier beschrieben)

Wenn man jetzt im named.conf den Eintrag

interface-interval 0;

hinzufügt & den nameserver restartet:

service named stop
service named start

nun müsste das Problem behoben sein.

Zum testen vielleicht einfach kurz den dhcclient restarten und /var/log/messages dabei beobachten:

service dhclient restart vtnet0

/etc/resolvconf/update-libc.d/sendmail: 7: .: Can’t open /usr/share/sendmail/dynamic

Nach einem BIND Upgrade unter Ubuntu (apt-get dist-upgrade), kam nach einem BIND Neustart plötzlich dieser Fehler:

Feb 16 23:10:59 patsy sh[18401]: /etc/resolvconf/update-libc.d/sendmail: 7: .: Can't open /usr/share/sendmail/dynamic
Feb 16 23:10:59 patsy sh[18401]: run-parts: /etc/resolvconf/update-libc.d/sendmail exited with return code 2
Feb 16 23:10:59 patsy sh[18401]: run-parts: /etc/resolvconf/update.d/libc exited with return code 1
Feb 16 23:10:59 patsy systemd[1]: bind9-resolvconf.service: Main process exited, code=exited, status=1/FAILURE

Auf diesem Server ist jedoch gar kein Sendmail installiert.

Lösung: /etc/resolvconf/update-libc.d/sendmail löschen

Zur Sicherheit vielleicht einfach zuerst an einen anderen Ort verschieben:

mv /etc/resolvconf/update-libc.d/sendmail /tmp 

Danach Bind neustarten

sudo service bind9 restart

Danach müsste wieder alles funktionieren. Check Syslog:

sudo tail -f /var/log/syslog

Wenn jetzt alles wieder funktioniert, das sendmail File löschen

rm /tmp/sendmail

Upgrade

/usr/ports/dns/bind9
make install

Backup Lösungen bei Server Ausfall

MX Records

Fällt ein Mailserver aus, kann der zweite die Funktionen übernehmen.

@                       MX      5 mail
; backup mailserver, falls corky down ist, wird
; hier zwischengespeichert
@                       MX      10 violet.shoe.org.

die Zahlen 5 und 10 sind die Prioritäten. Fällt Priorität (5) aus, übernimmt der Server mit Priorität (10).

Den Backup Server muss man glaubs noch irgendwie konfigurieren, damit er die Mails entsprechend entgegen nehmen kann.

A Records

Bei den A-Records geht das leider noch nicht so wirklich. Es gibt diverse Lösungen für Load Balancing, aber anscheinend ist das meiste noch Experimentell.

Lösungsvorschlag 1

Nun, du brächtest zwei Server mit uneingeschränkten Zugriff. Dann kannst Du MySQL replizieren lassen, welche Konfiguration Du verwendest hängt von Deinen Anforderung ab, hierbei wäre aber wohl ein Master – Master System interessant (ich würde aber trotzdem wohl eher ein Master – Slave System nehmen, auch enn man dies händisch umstellen müsste, wenn eines ausfällt). Dabei sind beide Master vom reinen MySQL-Server her genau gleich schnell wie ein einzelnes System (gemassen halt am langsameren Server), sprich Du kannst nicht (dauerhaft) die doppelte Menge an Zugriffen erfüllen, da beide Master sich zumindestens schreibend Abgleichen müssen. Dafür musst Du natürlich MySQL für das Netzwerk öffnen und nicht nur am Socket gebunden betreiben.

Dann müsstest Du dein DNS System so einrichten, dass Du nur auf Deinen Hauptserver die Dateien hochlädst (sprich ftp.domain.de verweißt nur auf eine IP-Adresse, während www.domain.de auf beide IP-Adressen verweist, mysql.domain.de muss entsprechend Deiner Anforderungen eingestellt werden).

Und dann musst du natürlich noch das Dateisystem in regelmäßigen Intervallen synchronisieren (z. B. mit Hilfe des Befehls rsync).

Bei dem Mail-System reich eigentlich ein Backup aus, könntest Du zur Not auch einrichten und im DNS als Backup-Server ausgeben. Solange Du es nicht benötigst, synchronisierst Du nur die Datenbestände auf den Backup-Server und konfigurierst den Server vorläufig als Teergrube (also als eine Falle für Spammer, damit Du diese an den zweiten Server bindest und somit weniger Last auf Deinen Hauptserver kommt). Wenn Du ihn brauchst, ersetzt Du die Konfiguration mit den Einstellungen des Hauptservers.

Lösungsvorschlag 2 – SRV

SRV = Lokalisierung von Serverdiensten

Hauptproblem: SRV ist noch experimentell und wird nicht von allen Clients unterstützt. Wäre jedoch die sauberste Lösung.

Allerdings hab ich hier etwas gefunden, das freude macht 🙂

TODO for DNS admins: If you don't do it yet, please start using SRV records now. 
They are really not that complex, they're much like MX records. These SRV records 
can co-exist as superior alternatives with old-fashioned A and CNAME records. You 
are welcome to generate any examples you need here, or test your domain's SRV 
records here.
The documentation in rfc2782 is, in contrast to common RFC practice, short and 
readable. Don't worry about name server support, these things have been part of 
bind for a long time.

SRV-Typen werden hauptsächlich von Microsoft und ADS-Diensten verwendet. Hier besteht z.B. die Möglichkeit explizit Dienste an IP-Adressen zu binden, z.B.:

_http._tcp.www.movie.edu.  IN  SRV  0  2  80 www.movie.edu.

Dies besagt, dass der http-Server (die TCP-Version) für www.movie.edu auf Port 80 von www.movie.edu zu finden ist.

Die beiden anderen Zahlenwerte sind die Priorität und das Gewicht. Die Priorität ähnelt der bei MX-Records, je niedriger der Wert desto höher ist der Name priorisiert. D.h. bei mehreren Einträgen muss zuerst der mit dem niedrigsten Wert angesprochen werden. Antwortet dieser Server nicht, so muss der nächste in der Prioritätsliste verwendet werden.

Das Gewicht bestimmt wie die Last bei Records mit gleicher Priorität verteil werden soll.

Weitere Quellen dazu:

• http://www.unix.com.ua/orelly/networking_2ndEd/dns/ch16_06.htm
• http://dns.vanrein.org/srv/tools/ (ist eventuell etwas veraltet?)
• http://dns.vanrein.org/srv/srv-promotion/rfc2782.txt
• http://www.dns-sd.org/ServiceTypes.html

Master Record Config

Hier ein Template für den Master Record. Bei einem Server Umzug muss man übrigens den minimum TTL ändern (z.b. auf 60 Sekunden) das geht z.b. mit dem Script das auf dem DNS Server unter den tools abgelegt ist.

Das „@“ ist ein Joker-Symbol für den Wert von $ORIGIN. Wenn also $ORIGIN = bound.ch ist, ist „@“ = bound.ch

$ORIGIN bound.ch.
$TTL            600
;
@               IN      SOA     ns1.shoeinternational.net. hostmaster.shoe.org. (
                         2008082607  ; serial INCREMENT AFTER CHANGE
                              10800  ; refresh (3 hours)
                               3600  ; retry (1 hour)
                             604800  ; expire (1 week)
                               3600 ); minimum ttl (1 hour)
;
@               IN      NS      ns1.shoeinternational.net.
@               IN      NS      ns2.shoeinternational.net.
;
@                       MX      5 mail
;
@               IN      A       80.74.159.5
www             IN      A       80.74.159.5
mail            IN      A       80.74.159.5