Installation Bind Nameserver (DNS)

Installation

Standardmässig ist der Bind DNS Server unter FreeBSD in der Version 9 installiert. Um ihn zu aktivieren muss man folgendes ins /etc/rc.conf eintragen:

#-----------------------------------------------#
#       DNS Server                              #
#-----------------------------------------------#
named_enable="YES"

Natürlich kann man Bind auch Upgraden. Auf FreeBSD 8 ist BIND 9.6.2 vorinstalliert. Um upzugraden einfach die aktuellste Version installieren.

ACHTUNG: ging bei meinem letzten Versuch nicht:

make: don't know how to make /usr/ports/dns/bind98/work/.install_done.bind98._usr_local. Stop
*** Error code 2
cd /usr/ports/dns/bind98
make install clean
  lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
  x                Options for bind98-devel 9.8.0.b1                   x
  x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x
  x x[X] SSL             Building without OpenSSL removes DNSSEC     x x
  x x[X] LINKS           Create conf file symlinks in /usr/local     x x
  x x[ ] XML             Support for xml statistics output           x x
  x x[ ] IDN             Add IDN support to dig, host, etc.          x x
  x x[X] REPLACE_BASE    Replace base BIND with this version         x x
  x x[ ] LARGE_FILE      64-bit file support                         x x
  x x[ ] SIGCHASE        dig/host/nslookup will do DNSSEC validation x x
  x x[ ] IPV6            IPv6 Support (autodetected by default)      x x
  x x[X] THREADS         Compile with thread support                 x x
  x x[ ] DLZ_POSTGRESQL  DLZ Postgres driver                         x x
  x x[ ] DLZ_MYSQL       DLZ MySQL driver (single-threaded BIND)     x x
  x x[ ] DLZ_BDB         DLZ BDB driver                              x x
  x x[ ] DLZ_LDAP        DLZ LDAP driver                             x x
  x x[ ] DLZ_FILESYSTEM  DLZ filesystem driver                       x x
  x x[ ] DLZ_STUB        DLZ stub driver                             x x
  tqmqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqjqu
  x                       [  OK  ]       Cancel                        x
  mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

danach im /etc/rc.conf

named_enable="YES"
named_program="/usr/local/sbin/named"

eintragen.

Config

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

Bestehende Verzeichnisse kopieren:

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

Logfiles löschen:

cd log
true > error.log
true > query.log

named.conf.template anpassen -> neue IP Adresse des / der Server updaten

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

Zonen generieren und auf den Secondary übertragen

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

Nameserver neu starten:

/etc/rc.d/named restart

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 bind  bind    512 Feb  2 09:21 log/
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   3 root  wheel   512 Feb  2 09:20 secondary/
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(/etc/namedb)> 

Nameserver auf localhost anpassen

after install, please edit:

/etc/resolv.conf

erste zeile: 127.0.0.1 danach nameserver der reihe nach 1. zeile primary, 2. secondary etc.

Login

Auf dem Secondary dem User BIND ein Passwort geben, damit er connecten kann:

passwd bind
Changing local password for bind
New Password:
Retype New Password:
vipw

Zeile anpassen

bind:$1$pHvgus.l$WmF.NomwkCuORls4e13Ff/:53:53::0:0:Bind Sandbox:/etc/namedb:/usr/local/bin/bash
##bind:$1$pHvgus.l$WmF.NomwkCuORls4e13Ff/:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin

Der authorized_keys2 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 -t dsa

copy inhalt von /root/.ssh/id_dsa.pub Primary ins /violet/.ssh/authorized_keys2 von Secondary

Auf Secondary

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

Secondary

cd /etc/namedb
mkdir config
mkdir log
mkdir secondary
mkdir secondary/diverses
mkdir secondary/shoe
chown -R bind:bind config/
chown -R bind:bind log/
chown bind:wheel 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:

/etc/rc.d/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.

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.

Testen

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

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

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:

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

 

  • Gwyneth Llewelyn
    #1 geschrieben von Gwyneth Llewelyn vor 2 Jahren

    Nicht schlecht, aber du hast die BIND-Sandbox annulliert, und mit einer Passwort verfügt — das kann mal problematisch sein. Besser wäre es, daß die BIND-Konfiguration eine Sandbox benützt, ohne Passwort, aber mit die SSH-Keys wie du vorgeschlagen hast.

    Das kann ich aber leider nicht recht konfigurieren… es sieht so aus, als ob SSH die .ssh/authorized_keys nicht findet, wenn diese innerhalb der Sandbox sind…

  • RebuyIT.eu
    #2 geschrieben von RebuyIT.eu vor 6 Monaten

    Schöne Anleitung um den bind9 auf nem BSD zum laufen zu bekommen! Jedoch muss ich meinem vorposter zustimmen!

    BIND ohne Sandbox ist ne recht heikle Angelegenheit!

    Hast du ggf noch Optimerungsvorschläge um bsp das Cacheing von BIND zu Optimieren?

  • *

    Du kannst diese HTML tags verwenden: <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <s> <strike> <strong>

  • Kommentar-Feed für diesen Beitrag
nach oben