23.6. DNS - Domain Name Service

23.6.1. Überblick

DNS ist das für die Umwandlung von Rechnernamen in IP-Adressen zuständige Protokoll. FreeBSD verwendet dazu BIND (Berkeley Internet Name Domain), die am häufigsten verwendete Implementierung von DNS. Eine Anfrage nach www.FreeBSD.org gibt die IP-Adresse des FreeBSD-Webservers, eine Anfrage nach ftp.FreeBSD.org die IP-Adresse des entsprechenden FTP-Servers zurück. Der umgekehrte Weg ist ebenso möglich, eine IP-Adresse kann also auch in ihren Rechnernamen aufgelöst werden. Um eine DNS-Abfrage durchzuführen, muss auf dem jeweiligen Rechner kein Nameserver installiert sein.

Im Internet wird DNS durch ein komplexes System von autoritativen Root-Nameservern sowie anderen kleineren Nameservern verwaltet, die individuelle Rechnerinformationen speichern und untereinander abgleichen.

Dieses Dokument beschreibt die unter FreeBSD verwendete stabile Version BIND 8.x. BIND 9.x kann über den Port net/bind9 installiert werden.

Das DNS-Protokoll wird in den RFCs 1034 und 1035 beschrieben.

Derzeit wird BIND vom Internet Software Consortium (http://www.isc.org/) verwaltet.

23.6.2. Begriffsbestimmungen

Um dieses Dokument besser verstehen zu können, müssen einige DNS-spezifische Begriffe genauer definiert werden.

Es folgen nun einige Zonenbeispiele:

• . ist die Root-Zone.

• org. ist eine Zone innerhalb der Root-Zone.

• example.org. ist eine Zone innerhalb der org.-Zone.

• foo.example.org. ist eine Unterdomäne, eine Zone innerhalb der Zone example.org.

• 1.2.3.in-addr.arpa. ist die Zone mit allen IP-Adressen des 3.2.1.*-IP-Adressraums.

Wie man an diesen Beispielen erkennen kann, befindet sich der spezifischere Teil eines Rechnernamens auf der linken Seite der Adresse. example.org. beschreibt einen Rechner also genauer als org., während org. genauer als die Root-Zone ist. Jeder Teil des Rechnernamens hat Ähnlichkeiten mit einem Dateisystem, in dem etwa /dev dem Wurzelverzeichnis untergeordnet ist.

23.6.3. Gründe für die Verwendung eines Nameservers

Es gibt zwei Arten von Nameservern: Autoritative Nameserver sowie zwischenspeichernde (cachende) Nameserver.

Ein autoritativer Nameserver ist notwendig, wenn

• Sie anderen verbindliche DNS-Auskünfte erteilen wollen.

• eine Domain, beispielsweise example.org, registriert wird, und den zu dieser Domain gehörenden Rechnern IP-Adressen zugewiesen werden müssen.

• ein IP-Adressblock reverse-DNS-Einträge benötigt, um IP-Adressen in Rechnernamen auflösen zu können.

• ein Backup-Nameserver (auch Slaveserver genannt) auf Anfragen antworten muss, weil der Hauptserver nicht erreichbar ist.

Ein cachender Nameserver ist notwendig, weil

• ein lokaler DNS-Server Daten zwischenspeichern und daher schneller auf Anfragen reagieren kann als ein entfernter Server.

• die Datenmenge reduziert werden muss (DNS-Verkehr macht etwa 5 % des gesamten Datenverkehrs im Internet aus).

Wird nach www.FreeBSD.org gesucht, leitet der Resolver diese Anfrage an den Nameserver des ISPs weiter und nimmt danach das Ergebnis der Abfrage entgegen. Existiert ein lokaler, zwischenspeichernder DNS-Server, muss dieser die Anfrage nur einmal nach außen weitergeben. Für alle weiteren Anfragen ist dies nicht mehr nötig, da diese Information nun lokal gespeichert ist.

23.6.4. Wie funktioniert DNS?

Unter FreeBSD wird der BIND-Daemon als named bezeichnet.

Zonendateien befinden sich normalerweise im Verzeichnis /etc/namedb und enthalten die vom Nameserver angebotenen DNS-Zoneninformationen.

23.6.5. BIND starten

Da BIND automatisch installiert wird, ist die Konfiguration relativ einfach.

Um den named-Daemon beim Systemstart automatisch zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein:

named_enable="YES"

Um den Daemon (nach der Konfiguration) manuell zu starten, geben Sie Folgendes ein:

# ndc start

23.6.6. Konfigurationsdateien

# cd /etc/namedb
# sh make-localhost

// $FreeBSD$
//
// Refer to the named(8) manual page for details.  If you are ever going
// to setup a primary server, make sure you've understood the hairy
// details of how DNS is working.  Even with simple mistakes, you can
// break connectivity for affected parties, or cause huge amount of
// useless Internet traffic.

options {
        directory "/etc/namedb";

// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
//      forward only;

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the
Internet.
/*
        forwarders {
                127.0.0.1;
        };
*/     

/*
* If there is a firewall between you and name servers you want
* to talk to, you might need to uncomment the query-source
* directive below.  Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;

/*
* If running in a sandbox, you may have to specify a different
* location for the dumpfile.
*/
// dump-file "s/named_dump.db";
};

// Note: the following will be supported in a future release.
/*
host { any; } {
        topology {
                127.0.0.0/8;
        };
};
*/

// Setting up secondaries is way easier and the rough picture for this
// is explained below.
//
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
// Also, make sure to enable it in /etc/rc.conf.

zone "." {
        type hint;
        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

zone
"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.INT" {
        type master;
        file "localhost.rev";
};

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example secondary config entries.  It can be convenient to become
// a secondary at least for the zone where your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is the first bytes of the respective IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to setup a primary zone, better make sure you fully
// understand how DNS and BIND works, however.  There are sometimes
// unobvious pitfalls.  Setting up a secondary is comparably simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.
//
// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf).
// The directory containing the secondary zones must be write accessible
// to BIND.  The following sequence is suggested:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s

/*
zone "example.com" {
        type slave;
        file "s/example.com.bak";
        masters {
                192.168.1.1;
        };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "s/0.168.192.in-addr.arpa.bak";
        masters {
                192.168.1.1;
        };
};
*/     

zone "example.org" {
        type master;
        file "example.org";
};     

zone "example.org" {
        type slave;
        file "example.org";
};     

$TTL 3600

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

; DNS Servers
@       IN NS           ns1.example.org.
@       IN NS           ns2.example.org.

; Machine Names
localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

; Aliases
www             IN CNAME        @

; MX Record
@               IN MX   10      mail.example.org.

recordname      IN recordtype   value

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day

@       IN NS           ns1.example.org.

localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

www             IN CNAME        @

@               IN MX   10      mail.example.org.

$TTL 3600

1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        3600 )          ; Minimum

@       IN NS   ns1.example.org.
@       IN NS   ns2.example.org.

2       IN PTR  ns1.example.org.
3       IN PTR  ns2.example.org.
10      IN PTR  mail.example.org.
30      IN PTR  example.org.

23.6.7. Zwischenspeichernde (cachende) Nameserver

Ein cachender Nameserver ist für keine Zonen verantwortlich. Er stellt lediglich eigene Anfragen und speichert deren Ergebnisse ab. Um einen solchen Nameserver einzurichten, gehen Sie wie gewohnt vor, allerdings definieren Sie keine Zonen.

23.6.8. named in einer Sandbox ausführen

Es ist möglich, named(8) als nicht privilegierter Benutzer in einer mit chroot(8) definierten Sandbox auszuführen. Dadurch hat der named-Daemon keinen Zugriff auf Verzeichnisse und Dateien außerhalb der Sandbox. Sollte named kompromittiert werden, lässt sich dadurch der mögliche Schaden begrenzen. FreeBSD erzeugt dazu automatisch einen Benutzer und eine Gruppe namens bind.

Da named keinen Zugriff auf Dateien außerhalb der Sandbox (wie Systembibliotheken oder Protokolldateien) hat, sind einige Vorbereitungen notwendig, damit named korrekt funktioniert. Im Folgenden wird angenommen, dass die Sandbox unter /etc/namedb eingerichtet wird. Außerdem befinden sich die Dateien in diesem Verzeichnis noch im Originalzustand. Alle Schritte müssen als root durchgeführt werden.

• Erzeugen Sie alle Verzeichnisse, die named benötigt:

  # cd /etc/namedb
  # mkdir -p bin dev etc var/tmp var/run master slave
  # chown bind:bind slave var/*
  

  

  Da named nur schreibend auf diese Verzeichnisse zugreifen muss, werden auch keine weiteren Rechte zugeteilt.

• Erzeugen Sie die Basiszonen sowie die nötigen Konfigurationsdateien:

  # cp /etc/localtime etc
  # mv named.conf etc && ln -sf etc/named.conf
  # mv named.root master
  # sh make-localhost && mv localhost.rev localhost-v6.rev master# cat > master/named.localhost
  $ORIGIN localhost.
  $TTL 6h
  @   IN  SOA localhost. postmaster.localhost. (
              1   ; serial
              3600    ; refresh
              1800    ; retry
              604800  ; expiration
              3600 )  ; minimum
      IN  NS  localhost.
      IN  A       127.0.0.1
  ^D
  

  

  Dadurch ist es named möglich, die korrekte Systemzeit an syslogd(8) weiterzugeben.

• Wenn Sie FreeBSD in einer Version vor 4.9-RELEASE verwenden, erzeugen Sie eine statisch gelinkte Kopie von named-xfer und kopieren diese in Ihre Sandbox:

  # cd /usr/src/lib/libisc
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/lib/libbind
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/libexec/named-xfer
  # make cleandir && make cleandir && make depend && make NOSHARED=yes all
  # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
  

  Nachdem Sie ihre statische gelinkte Version von named-xfer installiert haben, müssen Sie etwas aufräumen, damit keine veralteten Kopien von Bibliotheken oder Programmen in Ihrem Quellbaum verbleiben:

  # cd /usr/src/lib/libisc
  # make cleandir
  # cd /usr/src/lib/libbind
  # make cleandir
  # cd /usr/src/libexec/named-xfer
  # make cleandir
  

  

  Dieser Schritt kann manchmal fehlschlagen. Wenn dies passiert, machen Sie Folgendes:

  # cd /usr/src && make cleandir && make cleandir
  

  Danach löschen Sie /usr/obj inklusive aller Unterverzeichnisse:

  # rm -fr /usr/obj && mkdir /usr/obj
  

  Dadurch entfernen Sie den ganzen “Müll” aus Ihrem Quellbaum und die fehlgeschlagenen Schritte sollten nun ebenfalls funktionieren.

  Wenn Sie FreeBSD in der Version 4.9-RELEASE oder neuer verwenden, wird die in /usr/libexec vorhandene Kopie von named-xfer automatisch statisch gelinkt und Sie können die Datei einfach mit cp(1) in Ihre Sandbox kopieren.

• Erzeugen Sie ein dev/null, auf das named lesend und schreibend zugreifen kann:

  # cd /etc/namedb/dev && mknod null c 2 2
  # chmod 666 null
  

• Linken Sie /etc/namedb/var/run/ndc symbolisch nach /var/run/ndc:

  # ln -sf /etc/namedb/var/run/ndc /var/run/ndc
  

  Anmerkung: Dadurch können Sie auf die Option -c verzichten, wenn Sie ndc(8) aufrufen. Der Inhalt von /var/run wird beim Systemstart automatisch gelöscht. Diese Anweisung kann unter Nutzung der Option @reboot in die crontab von root eingebaut werden. Lesen Sie dazu auch die Hilfeseite crontab(5).

• Weisen Sie syslogd(8) an, einen zusätzlichen log-Socket zu erzeugen, auf den named Schreibzugriff hat. Dazu hängen Sie in der Datei /etc/rc.conf an den Eintrag syslogd_flags die Option -l /etc/namedb/dev/log an.

• Stellen Sie sicher, dass named gestartet wird und sein Wurzelverzeichnis mittels chroot in die Sandbox setzt, indem Sie folgende Einträge in /etc/rc.conf einfügen:

  named_enable="YES"
  named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
  

  Anmerkung: Beachten Sie, dass die Konfigurationsdatei /etc/named.conf durch einen absoluten Pfad (aber relativ zur Sandbox) festgelegt wird. Bei der im obigen Beispiel angesprochenen Datei handelt es sich also um /etc/namedb/etc/named.conf.

Danach bearbeiten Sie /etc/namedb/etc/named.conf, damit named weiß, welche Zonen geladen werden müssen und wo sich diese befinden. Es folgt nun ein kommentiertes Beispiel (alle nicht dokumentierten Einträge gelten auch für einen DNS-Server, der nicht in einer Sandbox läuft):

options {
        directory "/";
        named-xfer "/bin/named-xfer";
        version "";     // Don't reveal BIND version
        query-source address * port 53;
};
// ndc control socket
controls {
        unix "/var/run/ndc" perm 0600 owner 0 group 0;
};
// Zones follow:
zone "localhost" IN {
        type master;
        file "master/named.localhost";
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "master/localhost.rev";
        allow-transfer { localhost; };
        notify no;
};
zone "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.int" {
    type master;
    file "master/localhost-v6.rev";
    allow-transfer { localhost; };
    notify no;
};
zone "." IN {
        type hint;
        file "master/named.root";
};
zone "private.example.net" in {
        type master;
        file "master/private.example.net.db";
    allow-transfer { 192.168.10.0/24; };
};
zone "10.168.192.in-addr.arpa" in {
        type slave;
        masters { 192.168.10.2; };
        file "slave/192.168.10.db";
};   

Nachdem Sie diese Schritte erledigt haben, müssen Sie entweder den Rechner oder syslogd(8) neu starten. Danach starten Sie named(8) unter Verwendung der neuen, unter syslogd_flags und named_flags festgelegten Optionen. Sie verwenden nun eine Sandboxversion von named!

23.6.9. Sicherheit

Obwohl BIND die am meisten verwendete (und kontrollierte) Implementierung von DNS darstellt, werden dennoch manchmal neue Sicherheitsprobleme entdeckt.

Es ist daher eine gute Idee, die Sicherheitshinweise von CERT zu lesen sowie die Mailingliste FreeBSD security notifications zu abonnieren, um sich über Sicherheitsprobleme im Zusammenhang mit dem Internet und FreeBSD zu informieren.

23.6.10. Weitere Informationsquellen

• Hilfeseiten zu BIND/named: ndc(8), named(8), named.conf(5)

• Offizielle ISC-Seite zu BIND

• BIND FAQs

• O'Reilly DNS and BIND 4th Edition

• RFC1034 - Domain Names - Concepts and Facilities

• RFC1035 - Domain Names - Implementation and Specification