22.7. DNS – Domain Name System

DNS (engl. Domain Name System) wird benötigt, um die Domain- und Rechnernamen in IP-Adressen aufzulösen. Bevor Sie einen eigenen Nameserver einrichten, sollten Sie die allgemeinen Informationen zu DNS im Abschnitt 22.1.3. “Domain Name System – DNS” lesen.

22.7.1. Nameserver BIND starten

Der Nameserver BIND (Berkeley Internet Name Domain) ist auf SUSE LINUX bereits soweit vorkonfiguriert, dass man ihn problemlos sofort nach der Installation starten kann. Hat man bereits eine funktionsfähige Internetverbindung und trägt in der /etc/resolv.conf als Nameserver 127.0.0.1 für localhost ein, hat man in der Regel schon eine funktionierende Namensauflösung, ohne dass man den DNS des Providers kennt. BIND führt so die Namensauflösung über die Root-Nameserver durch, was aber merklich langsamer ist. Normalerweise sollte man den DNS des Providers mit seiner IP-Adresse in der Konfigurationsdatei /etc/named.conf unter forwarders eintragen, um eine effektive und sichere Namensauflösung zu erhalten. Funktioniert das soweit, läuft der Nameserver als reiner „Caching-only“-Nameserver. Erst wenn man ihm eigene Zonen bereitstellt, wird er ein richtiger DNS werden. Ein einfaches Beispiel dafür, findet man im Dokumentations-Verzeichnis /usr/share/doc/packages/bind/sample-config.

[Tip]Automatische Angabe des Nameservers

Je nach Art des Internetzugangs oder nach aktueller Netzwerkumgebung kann der Nameserver automatisch für die jeweiligen Gegebenheiten eingestellt werden. Setzen Sie hierzu in der Datei /etc/sysconfig/network/config die Variable MODIFY_NAMED_CONF_DYNAMICALLY auf den Wert yes.

Man sollte allerdings keine offizielle Domain aufsetzen, solange man diese nicht von der zuständigen Institution — für .de ist das die DENIC eG — zugewiesen bekommen hat. Auch wenn man eine eigene Domain hat, diese aber vom Provider verwaltet wird, sollte man diese besser nicht verwenden, da BIND sonst keine Anfragen für diese Domain mehr forwarden (weiterleiten) würde und so zum Beispiel der Webserver beim Provider für die eigene Domain nicht mehr erreichbar wäre.

Um den Nameserver zu starten, gibt man auf der Kommandozeile als root ein:

rcnamed start

Erscheint rechts in grün „done“, ist der named, so heißt der Nameserver-Prozess, erfolgreich gestartet. Auf dem lokalen System kann man die Funktionsfähigkeit des Nameservers sofort testen, indem man die Programme host oder dig verwendet.

Als Default-Server muss localhost mit der Adresse 127.0.0.1 angezeigt werden. Sollte das nicht der Fall sein, steht wahrscheinlich in der /etc/resolv.conf ein falscher Nameserver oder diese Datei existiert gar nicht. Für einen ersten Test gibt man host 127.0.0.1 ein, das sollte immer funktionieren; erhält man eine Fehlermeldung, sollte man mit folgendem Kommando überprüfen, ob der named überhaupt läuft

rcnamed status

Falls der Nameserver nicht startet oder ein fehlerhaftes Verhalten zeigt, findet man die Ursache in den meisten Fällen in /var/log/messages protokolliert.

Um den Nameserver des Providers oder um einen eigenen, der bereits im lokalen Netz läuft, als „Forwarder“ zu verwenden, trägt man diesen oder auch mehrere, im Abschnitt options unter forwarders ein; die in Beispiel 22.10. “Forwarding-Optionen in named.conf” verwendeten IP-Adressen sind willkürlich gewählt und müssen entsprechend den eigenen Gegebenheiten angepasst werden.

Beispiel 22.10. Forwarding-Optionen in named.conf

options { 
        directory "/var/lib/named";
        forwarders { 10.11.12.13; 10.11.12.14; };
        listen-on { 127.0.0.1; 192.168.0.99; };
        allow-query { 127/8; 192.168.0/24; };
        notify no;
        };

Nach den options folgen die Einträge für die Zonen, die Einträge für localhost, 0.0.127.in-addr.arpa, sowie . vom type hint sollten immer vorhanden sein. Die zugehörigen Dateien müssen nicht verändert werden, da sie so funktionieren wie sie sind. Beachten muss man auch, dass nach jedem Eintrag ein ; steht und die geschweiften Klammern korrekt gesetzt sind. Hat man nun Änderungen an der Konfigurationsdatei /etc/named.conf oder an den Zonen-Dateien vorgenommen, muss man BIND mit dem Kommando rcnamed reload dazu veranlassen, diese neu einzulesen. Alternativ kann man den Nameserver auch komplett mit dem Befehl rcnamed restart neu starten. Mit dem Kommando rcnamed stop kann man den Nameserver jederzeit komplett beenden.

22.7.2. Die Konfigurationsdatei /etc/named.conf

Alle Einstellungen zum Nameserver BIND sind in der Datei /etc/named.conf vorzunehmen. Die Zonendaten selbst, die Rechnernamen, IP-Adressen usw. für die zu verwaltenden Domains, sind in separaten Dateien im Verzeichnis /var/lib/named abzulegen, dazu aber unten mehr.

Die /etc/named.conf unterteilt sich grob in zwei Bereiche, zum einen der Abschnitt options für allgemeine Einstellungen und zum anderen die zone-Einträge für die einzelnen Domains. Außerdem kann man noch einen Bereich logging, sowie Einträge vom Typ acl (engl. Access Control List) definieren. Kommentarzeilen beginnen mit einem #-Zeichen, alternativ ist // auch erlaubt.

Eine minimalistische /etc/named.conf stellt Datei 22.11. “Minimalistische Datei /etc/named.conf” dar.

Beispiel 22.11. Minimalistische Datei /etc/named.conf

options { 
        directory "/var/lib/named"; 
        forwarders { 10.0.0.1; };
        notify no;
};

zone "localhost" in {
       type master;
       file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.0.0.zone";
};

zone "." in {
        type hint;
        file "root.hint";
};
[Important]Weitere Informationen zur BIND-Konfiguration

Weitere aktuelle Information zur BIND-Konfiguration unter SUSE LINUX erhalten Sie unter /usr/share/doc/packages/bind/README.SuSE.

22.7.3. Die wichtigsten Konfigurationsoptionen im Abschnitt options

directory "filename";

gibt das Verzeichnis an, in dem der BIND die Dateien mit den Zonendaten findet; dies ist in der Regel /var/lib/named.

forwarders { ip-address; };

verwendet man, um den oder die Nameserver (meist des Providers) anzugeben, an den oder die die DNS-Anfragen weitergereicht werden, die nicht direkt beantwortet werden können. Anstelle von ip-address verwenden Sie eine IP-Adresse wie 10.0.0.1.

forward first;

bewirkt, dass die DNS-Anfragen zu erst geforwarded werden, bevor versucht wird diese über die Root-Nameserver aufzulösen. Anstelle von forward first kann man auch forward only schreiben, dann werden alle Anfragen weitergeleitet und die Root-Nameserver werden gar nicht mehr angesprochen. Das kann für Firewall-Konfigurationen sinnvoll sein.

listen-on port 53 { 127.0.0.1; ip-address; };

sagt BIND, auf welchen Netzwerkinterfaces und welchem Port er Anfragen der Clients entgegen nehmen soll. Die Angabe port 53 kann man sich dabei sparen, da 53 ohnehin der Standardport ist. Mit 127.0.0.1 lässt man Anfragen von localhost zu. Lässt man diesen Eintrag komplett weg, werden standardmäßig alle Interfaces verwendet.

listen-on-v6 port 53 { any; };

sagt dem BIND, auf welchem Port er auf Anfragen der Clients horcht, die IPv6 verwenden. Außer any ist alternativ nur noch none erlaubt, da der Server stets auf der IPv6-Wildcard-Adresse horcht.

query-source address * port 53;

Dieser Eintrag kann notwendig sein, wenn eine Firewall die externen DNS-Abfragen blockiert. So wird BIND dazu gebracht, Anfragen nach außen von Port 53 aus und nicht von den hohen Ports > 1024 zu stellen.

query-source-v6 address * port 53;

Dieser Eintrag muss für Anfragen über IPv6 verwendet werden.

allow-query { 127.0.0.1; net; };

bestimmt die Netze, aus denen Clients DNS-Anfragen stellen dürfen. Anstelle von net trägt man Adressenangaben wie 192.168.1/24 ein; dabei ist /24 eine Kurzschreibweise für die Anzahl der Bits in der Netzmaske, in diesem Fall 255.255.255.0.

allow-transfer { ! *; };

regelt, welche Rechner Zonentransfers anfordern dürfen, dieses Beispiel unterbindet sie, aufgrund des ! * komplett. Ohne diesen Eintrag können Zonentransfers ohne Einschränkungen von überall angefordert werden.

statistics-interval 0;

Ohne diesen Eintrag produziert BIND stündlich mehrere Zeilen Statistikmeldungen in /var/log/messages. Die Angabe von 0 bewirkt, dass diese komplett unterdrückt werden; hier kann man die Zeit in Minuten angeben.

cleaning-interval 720;

Diese Option legt fest, in welchem Zeitabstand BIND seinen Cache aufräumt. Die Aktivität führt jedes Mal zu einem Eintrag in /var/log/messages. Die Zeitangabe erfolgt in Minuten. Voreingestellt sind 60 Minuten.

interface-interval 0;

BIND durchsucht regelmäßig die Netzwerkschnittstellen nach neuen oder nicht mehr vorhandenen Interfaces. Setzt man diesen Wert auf 0, so wird darauf verzichtet und BIND lauscht nur auf den beim Start gefundenen Interfaces. Alternativ kann man das Intervall in Minuten angeben. Voreingestellt sind 60 Minuten.

notify no;

Das no bewirkt, dass keine anderen Nameserver benachrichtigt werden, wenn an den Zonendaten Änderungen vorgenommen werden oder der Nameserver neu gestartet wird.

22.7.4. Der Konfigurationsabschnitt Logging

Was und wie wohin mitprotokolliert wird, kann man beim BIND recht vielseitig konfigurieren. Normalerweise sind die Voreinstellungen ausreichend. Datei 22.12. “Logging wird unterdrückt” zeigt die einfachste Form eines solchen Eintrags und unterdrückt das „Logging“ komplett.

Beispiel 22.12. Logging wird unterdrückt

logging {
        category default { null; };
};

22.7.5. Aufbau der Zonen-Einträge

Nach zone wird der Name der zu verwaltenden Domain angegeben, hier willkürlich meine-domain.de gefolgt von einem in und einem in geschweiften Klammern gesetzten Block zugehöriger Optionen; vgl. 22.13. “Zone-Eintrag für meine-domain.de”.

Beispiel 22.13. Zone-Eintrag für meine-domain.de

zone "meine-domain.de" in {
       type master;
       file "meine-domain.zone";
       notify no;
};

Will man eine „Slave-Zone“ definieren, ändert sich nur der type auf slave und es muss ein Nameserver angegeben werden, der diese Zone als master verwaltet – das kann aber auch ein „slave“ sein; vgl. Datei 22.14. “Zone-Eintrag für andere-domain.de”.

Beispiel 22.14. Zone-Eintrag für andere-domain.de

zone "andere-domain.de" in {
       type slave;
       file "slave/andere-domain.zone";
       masters { 10.0.0.1; };
};

Die Zonen-Optionen:

type master;

Das master legt fest, dass diese Zone auf diesem Nameserver verwaltet wird. Das setzt eine korrekt erstellte Zonendatei voraus.

type slave;

Diese Zone wird von einem anderen Nameserver transferiert. Muss zusammen mit masters verwendet werden.

type hint;

Die Zone . vom Typ hint wird für die Angabe der Root-Nameserver verwendet. Diese Zonendefinition kann man unverändert lassen.

file "meine-domain.zone" oder file "slave/andere-domain.zone";

Dieser Eintrag gibt die Datei an, in der die Zonendaten für die Domain eingetragen sind. Bei einem slave braucht die Datei nicht zu existieren, da ihr Inhalt von einem anderen Nameserver geholt wird. Um Master- und Slave-Dateien auseinander zu halten, gibt man für die Slave-Dateien das Verzeichnis slave an.

masters { server-ip-address; };

Diesen Eintrag braucht man nur für Slave-Zonen und er gibt an, von welchem Nameserver die Zonendatei transferiert werden soll.

allow-update { ! *; };

diese Option regelt den Schreibzugriff von extern auf die Zonendaten. Damit wäre es Clients möglich, sich selbst im DNS einzutragen, was aus Sicherheitsgründen nicht wünschenswert ist. Ohne diesen Eintrag, sind Zonen-Updates generell untersagt, dieses Beispiel würde daran auch nichts ändern, da ! * ebenfalls alles verbietet.

22.7.6. Aufbau der Zonendateien

Man benötigt zwei Arten von Zonen-Dateien, die einen dienen dazu, einem Rechnernamen die IP-Adresse zuzuordnen und die anderen gehen den umgekehrten Weg und liefern zu einer gegebenen IP-Adresse den Rechnernamen.

[Tip]Der Punkt (.) in Zonendateien

Eine wichtige Bedeutung hat der Punkt in den Zonendateien. Werden Rechnernamen, ohne abschließenden . angegeben, wird immer die Zone ergänzt. Man muss also komplette Rechnernamen, die bereits mit vollständiger Domain angegeben wurden, mit einem . abschließen, damit die Domain nicht noch einmal dran gehängt wird. Ein fehlender Punkt oder einer an der falschen Stelle, dürfte die häufigste Fehlerursache bei der Konfiguration von Nameservern sein.

Den ersten Fall betrachten wir die Zonen-Datei welt.zone, die für die Domain welt.all zuständig ist; vgl. Datei 22.15. “Datei /var/lib/named/welt.zone”.

Beispiel 22.15. Datei /var/lib/named/welt.zone

$TTL 2D
welt.all.   IN SOA      gateway  root.welt.all. (
            2003072441  ; serial
            1D          ; refresh
            2H          ; retry
            1W          ; expiry
            2D )        ; minimum

            IN NS       gateway
            IN MX       10 sonne

gateway     IN A        192.168.0.1
            IN A        192.168.1.1
sonne       IN A        192.168.0.2
mond        IN A        192.168.0.3
erde        IN A        192.168.1.2
mars        IN A        192.168.1.3
www         IN CNAME    mond
Zeile 1:

$TTL definiert die Standard-TTL (engl. Time To Live), also zu deutsch Gültigkeitsdauer, die für alle Einträge in dieser Datei gilt: hier 2 Tage (2D = 2 days).

Zeile 2:

Hier beginnt der SOA control record (SOA = Start of Authority):

  • An erster Stelle steht hier der Name der zu verwaltenden Domain welt.all, diese ist mit einem . abgeschlossen, da ansonsten die Zone noch einmal angehängt würde. Alternativ kann man hier ein @ schreiben, dann wird die Zone dem zugehörigen Eintrag in der /etc/named.conf entnommen.

  • Nach dem IN SOA steht der Name des Nameservers, der als Master für diese Zone zuständig ist. In diesem Fall wird der Name gateway zu gateway.welt.all ergänzt, da er nicht mit einem . abgeschlossen ist.

  • Danach folgt eine E-Mail-Adresse, der für diesen Nameserver zuständigen Person. Da das @-Zeichen bereits eine besondere Bedeutung hat, ist hier stattdessen einfach ein . zu setzen, für root@welt.all trägt man hier folglich root.welt.all. ein. Den . am Ende darf man hier nicht vergessen, da sonst die Zone noch angehängt würde.

  • Am Ende folgt eine (, um die folgenden Zeilen, bis zur ) mit in den SOA-Record einzuschließen.

Zeile 3:

Die serial number ist eine willkürliche Zahl, die bei jeder Änderung an dieser Datei erhöht werden sollte. Sie wird benötigt, um sekundäre Nameserver (Slave-Server) über Änderungen zu informieren. Eingebürgert hat sich dafür eine zehnstellige Zahl aus Datum und fortlaufender Nummer in der Form JJJJMMTTNN.

Zeile 4:

Die refresh rate gibt das Zeitintervall an, in dem Sekundär-Nameserver die serial number der Zone überprüfen. In diesem Fall 1 Tag (1D = 1 day).

Zeile 5:

Die retry rate gibt den Zeitabstand an, in dem ein sekundärer Nameserver, im Fehlerfall versucht den primären Server erneut zu kontaktieren. Hier 2 Stunden (2H = 2 hours).

Zeile 6:

Die expiration time gibt den Zeitraum an, nachdem ein sekundärer Nameserver die gecacheten Daten verwirft, wenn er keinen Kontakt zum primären Server mehr bekommen hat. Hier ist das eine Woche (1W = 1 week).

Zeile 7:

Der letzte Eintrag im SOA ist die negative caching TTL. Er sagt aus, wie lange die Ergebnisse von DNS-Anfragen von anderen Servern gecached werden dürfen, die nicht aufgelöst werden konnten.

Zeile 9:

Das IN NS gibt den Nameserver an, der für diese Domain zuständig ist. Auch hier gilt, dass gateway wieder zu gateway.welt.all ergänzt wird, weil es nicht mit einem . abgeschlossen ist. Es kann mehrere Zeilen dieser Art geben, eine für den primären und jeweils eine für jeden sekundären Nameserver. Ist für diese Zone notify in der /etc/named.conf nicht auf no gesetzt, werden alle hier aufgeführten Nameserver über Änderungen der Zonendaten informiert.

Zeile 10:

Der MX-Record gibt den Mailserver an, der für die Domain welt.all die Mails annimmt und weiterverarbeitet oder weiterleitet. In diesem Beispiel ist das der Rechner sonne.welt.all. Die Zahl vor dem Rechnernamen ist der Präferenz-Wert, gibt es mehrere MX-Einträge, wird zuerst der Mailserver mit dem kleinsten Wert genommen und falls die Auslieferung an diesen scheitert, wird der mit dem nächst höheren Wert versucht.

Zeile 12-17:

Das sind jetzt die eigentlichen Adressen-Einträge (engl. Address Records), in denen den Rechnernamen eine oder mehrere IP-Adressen zugeordnet werden. Die Namen stehen hier ohne abschließenden ., da sie ohne angehängte Domain eingetragen sind und alle um welt.all ergänzt werden dürfen. Dem Rechner gateway sind zwei IP-Adressen zugeordnet, da er über zwei Netzwerkkarten verfügt. Das A steht jeweils für eine traditionelle Rechner-Adresse; mit A6 trägt man IPv6-Adressen ein und AAAA ist das obsolete Format für IPv6-Adressen.

Zeile 18:

Mit dem Alias www kann auch mond (CNAME = canonical name) angesprochen werden.

Für die Rückwärts-Auflösung (engl. reverse lookup) von IP-Adressen in Rechnernamen wird die Pseudo-Domain in-addr.arpa zu Hilfe genommen. Diese wird dazu an den in umgekehrter Reihenfolge geschriebenen Netzanteil angehängt. Aus 192.168.1 wird dann 1.168.192.in-addr.arpa.

Beispiel 22.16. Umgekehrte Adress-Auflösung

$TTL 2D
1.168.192.in-addr.arpa. IN SOA gateway.welt.all. root.welt.all. (
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           gateway.welt.all.

1                       IN PTR          gateway.welt.all.
2                       IN PTR          erde.welt.all.
3                       IN PTR          mars.welt.all.
Zeile 1:

$TTL definiert die Standard-TTL, die hier für alle Einträge gilt.

Zeile 2:

Der „Reverse Lookup“ soll mit dieser Datei für das Netz 192.168.1.0 ermöglicht werden. Da die Zone hier 1.168.192.in-addr.arpa heißt, will man dies natürlich nicht an die Rechnernamen anhängen, deshalb sind diese alle komplett mit Domain und abschließendem . eingetragen. Der Rest entspricht dem, was im vorangegangenen Beispiel für welt.all, bereits beschrieben wurde.

Zeile 3-7:

Siehe vorangegangenes Beispiel für welt.all.

Zeile 9:

Diese Zeile gibt auch hier wieder den Nameserver an, der für diese Zone zuständig ist, diesmal wird aber der Name komplett mit Domain und abschließendem . hier eingetragen.

Zeile 11-13:

Das sind die Pointer-Records, die zu einer IP-Adresse auf den zugehörigen Rechnernamen zeigen. Hier steht am Anfang der Zeile nur die letzte Stelle der IP-Adresse, ohne abschließenden . Wird jetzt die Zone daran angehängt und man denkt sich das .in-addr.arpa weg, hat man die komplette IP-Adresse in umgekehrter Reihenfolge.

Zonentransfers zwischen den verschiedenen Versionen von BIND sollten normalerweise kein Problem darstellen.

22.7.7. Sichere Transaktionen

Sichere Transaktionen kann man mithilfe der „Transaction SIGnatures“ (TSIG) verwirklichen. Dafür kommen Transaktionsschlüssel (engl. Transaction Keys) und -signaturen (engl. Transaction Signatures) zum Einsatz, deren Erzeugung und Verwendung in diesem Abschnitt beschrieben wird.

Benötigt werden sichere Transaktionen bei der Kommunikation von Server zu Server und für dynamische Aktualisierungen der Zonendaten. Eine auf Schlüsseln basierende Zugriffskontrolle bietet dafür eine weit größere Sicherheit als eine Kontrolle, die auf IP-Adressen basiert.

Ein Transaktionsschlüssel kann mit folgendem Kommando erzeugt werden (für mehr Informationen vgl. die Manualpage von dnssec-keygen):

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2

Es entstehen dadurch zwei Dateien mit beispielsweise folgenden Namen:

Khost1-host2.+157+34265.private
Khost1-host2.+157+34265.key

Der Schlüssel ist in beiden Dateien enthalten (z.B. ejIkuCyyGJwwuN3xAteKgg==). Zur weiteren Verwendung sollte Khost1-host2.+157+34265.key auf sicherem Wege (zum Beispiel mit scp) auf den entfernten Rechner übertragen und dort in der /etc/named.conf eingetragen werden, um eine sichere Kommunikation zwischen host1 und host2 zu bewirken:

key host1-host2. {
  algorithm hmac-md5;
  secret "ejIkuCyyGJwwuN3xAteKgg==";
};
[Warning]Zugriffsrechte von /etc/named.conf

Achten Sie darauf, dass die Zugriffsrechte auf /etc/named.conf eingeschränkt bleiben; die Vorgabe ist 0640 für root und die Gruppe named; alternativ kann man die Schlüssel auch in ein eigene geschützte Datei auslagern und diese dann includieren.

Damit auf dem Server host1 der Schlüssel für host2 mit der Beispielsadresse 192.168.2.3 verwendet wird, muss auf dem Server in der /etc/named.conf eingetragen werden:

server 192.168.2.3 {
  keys { host1-host2. ;};
};

In den Konfigurationsdateien von host2 müssen entsprechende Einträge vorgenommen werden.

Zusätzlich zu den ACLs auf Basis von IP-Adressen und Adress-Bereichen, soll man, um sichere Transaktionen auszuführen, TSIG-Schlüssel hinzufügen; ein Beispiel dafür kann so aussehen:

allow-update { key host1-host2. ;};

Mehr dazu findet man im BIND Administrator Reference Manual zu update-policy.

22.7.8. Zonendaten dynamisch aktualisieren

Dynamische Aktualisierungen (engl. Dynamic Update) ist der Terminus, der das Hinzufügen, Ändern oder Löschen von Einträgen in den Zonen-Dateien eines Masters bezeichnet. Beschrieben ist dieser Mechanismus im RFC 2136.

Dynamische Aktualisierungen werden je Zone mit den Optionen allow-update oder update-policy bei den Zonen-Einträgen konfiguriert. Zonen, die dynamisch aktualisiert werden, sollten nicht von Hand bearbeitet werden.

Mit nsupdate werden die zu aktualisierenden Einträge an den Server übertragen; zur genauen Syntax vgl. die Manualpage von nsupdate. Die Aktualisierung sollte aus Sicherheitsüberlegungen heraus unbedingt über sichere Transaktionen (TSIG) geschehen; vgl. Abschnitt 22.7.7. “Sichere Transaktionen”.

22.7.9. DNSSEC

DNSSEC (engl. DNS Security) ist im RFC 2535 beschrieben; welche Tools für den Einsatz von DNSSEC zur Verfügung stehen, ist im BIND-Manual beschrieben.

Eine sichere Zone muss einen oder mehrere Zonen-Schlüssel haben; diese werden, wie die Host-Schlüssel, auch mit dnssec-keygen erzeugt. Zur Verschlüsselung wählt man momentan DSA.

Die öffentlichen Schlüssel (engl. public keys) sollten in die Zonen-Dateien mit $INCLUDE eingebunden werden.

Alle Schlüssel werden mit dnssec-makekeyset zu einem Set zusammengefasst, das auf sicherem Wege an die übergeordnete Zone (engl. Parent Zone) zu übertragen ist, um dort mit dnssec-signkey signiert zu werden.

Die bei der Signierung erzeugten Dateien müssen zum Signieren von Zonen mit dnssec-signzone verwendet werden und die dabei entstandenen Dateien sind schließlich in /etc/named.conf für die jeweilige Zone einzubinden.

22.7.10. Konfiguration mit YaST

Das YaST DNS-Modul dient der Konfiguration eines eigenen DNS-Servers im lokalen Netz. Dieses Modul kennt zwei verschiedene Funktionsmodi:

Wizard-Konfiguration

Beim ersten Start des Moduls werden von Ihnen als Administrator einige grundlegende Entscheidungen verlangt. Nach Abschluss der initialen Konfiguration ist der Server grob vorkonfiguriert und prinzipiell einsatzbereit.

Experten-Konfiguration

Der Expertenmodus dient fortgeschritteneren Konfigurationsaufgaben wie ACL, Logging, TSIG-Keys u. a.

22.7.10.1. Wizard-Konfiguration

Der Wizard gliedert sich in drei Dialoge auf, von denen Sie an geeigneter Stelle in die Expertenkonfiguration abzweigen können.

Installation des DNS-Servers: Forwarder-Einstellungen

Diesen Dialog (siehe Abbildung 22.8. “Installation des DNS-Servers: Forwarders”) erhalten Sie beim ersten Start dieses Moduls. Entscheiden Sie sich, ob Sie die eine Liste von Forwarders vom PPP-Daemon bei der Einwahl per DSL oder ISDN erhalten möchten (PPP-Daemon legt Forwarders fest) oder sie selber eingeben (Forwarders manuell festlegen).

Abbildung 22.8. Installation des DNS-Servers: Forwarders

Installation des DNS-Servers: Forwarders
Installation des DNS-Servers: DNS-Zonen

Die Einträge in diesem Modul, werden in der Experteninstallation (siehe Abschnitt 22.7.10.2. “Expertenkonfiguration”) erklärt.

Installation des DNS-Servers: Wizard beenden

Da während der Installation eine Firewall aktiviert ist, können Sie hier beim Beenden den DNS-Port in der Firewall (Port 53) mit Firewall-Port öffnen öffnen sowie das Startverhalten des DNS-Servers (An oder Aus) festlegen. Auch ist es möglich, von hier in die Experten-Konfiguration zu verzweigen (Expertenkonfiguration für DNS-Server) (siehe Abbildung 22.9. “Installation des DNS-Servers: Wizard beenden”).

Abbildung 22.9. Installation des DNS-Servers: Wizard beenden

Installation des DNS-Servers: Wizard beenden

22.7.10.2. Expertenkonfiguration

Beim ersten Start des Moduls öffnet YaST ein Fenster mit mehreren Konfigurationsmöglichkeiten. Nach dessen Beendigung ist der DNS-Server prinzipiell einsatzbereit:

DNS-Server: Start

Unter der Überschrift Systemstart können Sie den DNS-Server ein (An) oder ausschalten (Aus). Über den Button DNS-Server nun starten können Sie den DNS-Server starten bzw. über DNS-Server nun stoppen den DNS-Server wieder stoppen und mit Einstellungen speichern und DNS-Server nun neu starten können die aktuellen Einstellungen gespeichert werden.

Sie können den DNS-Port in der Firewall öffnen (Firewall-Port öffnen) und über Firewall-Details die Firewall-Einrichtung in den Einzelheiten verändern.

DNS-Server: Forwarders

Dieser Dialog ist derselbe, den Sie auch beim Start im Wizard-Konfiguration erhalten (siehe Abschnitt 22.7.10.1. “Wizard-Konfiguration”).

DNS-Server: Protokollieren

Innerhalb dieser Rubrik stellen Sie ein, was und wie der DNS-Server protokollieren soll.

Unter Protokolltyp spezifizieren Sie, wohin der DNS-Servers die Meldungen hineinschreibt. Sie können es dem System überlassen (In Systemprotokoll protokollieren nach /var/log/messages), oder Sie legen die Datei explizit fest (In Datei protokollieren). Haben Sie letzeres gewählt, können Sie noch die maximale Dateigröße in Megabyte und die Anzahl dieser Logfiles angeben.

Unter Zusätzliches Protokollieren können Sie weitere Optionen einstellen: Anfragen protokollieren protokolliert jede Anfrage. Die Protokolldatei kann daher schnell sehr groß werden. Sie sollten diese Option nur für Debugging-Zwecke aktivieren. Um zwischen DHCP-Server und DNS-Server ein Zonenupdate durchzuführen, wählen Sie Zonen-Updates protokollieren. Um den Datenverkehr beim Transfer der Zonendaten (Zonentransfer) vom Master zum Slave zu protokollieren, aktivieren Sie die Option Zonen-Transfers protokollieren (siehe Abbildung 22.10. “DNS-Server: Protokollieren”).

Abbildung 22.10. DNS-Server: Protokollieren

DNS-Server: Protokollieren
DNS-Server: DNS-Zonen

Dieser Dialog ist in mehrere Bereiche unterteilt und ist dafür zuständig, Zonen-Dateien zu verwalten (siehe Abschnitt 22.7.6. “Aufbau der Zonendateien”).

Unter Name der Zone tragen Sie den neuen Namen einer Zone ein. Um reverse Zonen zu erzeugen muss der Zonenname auf .in-addr.arpa enden. Wählen Sie den Typ (Master oder Slave) mit Zonentyp aus (siehe Abbildung 22.11. “DNS-Server: DNS-Zonen”). Durch Zone bearbeiten... können Sie weitere Einstellungen für eine bestehende Zone festlegen. Wenn Sie eine Zone entfernen wollen, wählen Sie Zone löschen.

Abbildung 22.11. DNS-Server: DNS-Zonen

DNS-Server: DNS-Zonen
DNS-Server: Slave Zonen-Editor

Diesen Dialog erhalten Sie, wenn Sie unter dem Punkt 22.7.10.2. “Expertenkonfiguration” als Zonentyp Slave angewählt haben. Geben Sie unter Master DNS-Server den Masterserver an, der vom Slave abgefragt werden soll. Falls Sie den Zugriff beschränken möchten, können Sie vorher definierte ACLs in der Liste auswählen (siehe Abbildung 22.12. “DNS-Server: Slave Zonen-Editor”).

Abbildung 22.12. DNS-Server: Slave Zonen-Editor

DNS-Server: Slave Zonen-Editor
DNS-Server: Master Zonen-Editor

Diesen Dialog erhalten Sie, wenn Sie unter dem Punkt „DNS-Server: DNS-Zonen“ (vgl. Abschnitt 22.7.10.2. “Expertenkonfiguration”) als Zonentyp Master angewählt haben. Sie unterteilt sich in mehrere Ansichten: Grundlagen (die momentane Seite, die Sie sehen), NS-Einträge, MX-Einträge, SOA und Einträge. Alle folgenden beschriebenen Punkte beziehen sich auf die genannten.

In Abbildung 22.13. “DNS-Server: Zonen-Editor (Grundlagen)” legen Sie dynamische DNS-Einstellungen und die Zugriffsbedingungen für Zonentransfers an Clients und Slave Nameserver fest. Um dynamische Updates der Zonen zu erlauben, wählen Sie Dynamische Updates erlauben und den entsprechenden Transaktions-Schlüssel (TSIG) aus. Achten Sie darauf, dass vorher schon ein Schlüssel definiert wurde, bevor Sie den Updatevorgang starten.

Um Zonentransfers zu erlauben, müssen Sie die entsprechenden ACLs wählen. Sie müssen ACLs vorher bereits definiert haben.

Abbildung 22.13. DNS-Server: Zonen-Editor (Grundlagen)

DNS-Server: Zonen-Editor (Grundlagen)
DNS-Server: Zonen-Editor (NS-Einträge)

Dieser Dialog legt alternative Nameserver für diese Zonen fest. Achten Sie darauf, dass der eigene Nameserver in der Liste enthalten ist. Um einen neuen Eintrag vorzunehmen, geben Sie unter Hinzuzufügender Nameserver den entsprechenden Namen ein und bestätigen Sie mit Hinzufügen (siehe Abbildung 22.14. “DNS-Server: Zonen-Editor (NS-Einträge)”).

Abbildung 22.14. DNS-Server: Zonen-Editor (NS-Einträge)

DNS-Server: Zonen-Editor (NS-Einträge)
DNS-Server: Zonen-Editor (MX-Einträge)

Um einen neuen Mailserver für die aktuelle Zone zur bestehenden Liste einzufügen, geben Sie die zugehörige Adresse und die Priorität ein. Bestätigen Sie mit Hinzufügen (siehe Abbildung 22.15. “DNS-Server: Zonen-Editor (MX-Einträge)”).

Abbildung 22.15. DNS-Server: Zonen-Editor (MX-Einträge)

DNS-Server: Zonen-Editor (MX-Einträge)
DNS-Server: Zonen-Editor (SOA)

Die Anzeige zur SOA Record Configuration (siehe Abbildung 22.16. “DNS-Server: Zonen-Editor (SOA)”) wird verwendet, um SOA-Einträge (Start of Authority) anzulegen. Die Bedeutung der einzelnen Optionen kann im Beispiel 22.15. “Datei /var/lib/named/welt.zone” nachgelesen werden. Achten Sie darauf, dass diese Option nicht bei dynamischen Zonen in Kombination mit LDAP zur Verfügung steht.

Abbildung 22.16. DNS-Server: Zonen-Editor (SOA)

DNS-Server: Zonen-Editor (SOA)
DNS-Server: Zonen-Editor (Einträge)

Dieser Dialog verwaltet eine Liste von Zuordnungen von Namen zu IP-Adressen. Geben Sie im Eingabefeld unter Eintragsschlüssel den Hostnamen ein und wählen Sie den Typ aus (gleichnamiges Dropdown-Menü). A-Record ist der Haupteintrag; CNAME ist ein Alias und unter MX-Relay wird der Eintrag (Name) durch den Wert (Value) überschrieben.

22.7.11. Weitere Informationen

Hinzuweisen ist insbesondere auf das BIND Administrator Reference Manual, das online in /usr/share/doc/packages/bind/ zu finden ist, sowie auf die dort genannten RFCs und die mit BIND 9 mitgelieferten Manualpages.


SUSE LINUX 9.2