Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / SUSE Linux Enterprise Server-Dokumentation / Verwaltungshandbuch / Services / Domain Name System (DNS)
Gilt für SUSE Linux Enterprise Server 15 SP3

31 Domain Name System (DNS)

DNS (Domain Name System) ist zur Auflösung der Domänen- und Hostnamen in IP-Adressen erforderlich. So wird die IP-Adresse 192.168.2.100 beispielsweise dem Hostnamen jupiter zugewiesen. Bevor Sie Ihren eigenen Namenserver einrichten, sollten Sie die allgemeinen Informationen zu DNS in Abschnitt 19.3, „Namensauflösung“ lesen. Die folgenden Konfigurationsbeispiele gelten für BIND, den standardmäßigen DNS-Server.

31.1 DNS-Terminologie

Zone

Der Domänen-Namespace wird in Regionen, so genannte Zonen, unterteilt. So ist beispielsweise example.com der Bereich (oder die Zone) example der Domäne com.

DNS-Server

Der DNS-Server ist ein Server, auf dem der Name und die IP-Informationen für eine Domäne gespeichert sind. Sie können einen primären DNS-Server für die Masterzone, einen sekundären Server für die Slave-Zone oder einen Slave-Server ohne jede Zone für das Caching besitzen.

DNS-Server der Masterzone

Die Masterzone beinhaltet alle Hosts aus Ihrem Netzwerk und der DNS-Server der Masterzone speichert die aktuellen Einträge für alle Hosts in Ihrer Domäne.

DNS-Server der Slave-Zone

Eine Slave-Zone ist eine Kopie der Masterzone. Der DNS-Server der Slave-Zone erhält seine Zonendaten mithilfe von Zonentransfers von seinem Masterserver. Der DNS-Server der Slave-Zone antwortet autorisiert für die Zone, solange er über gültige (nicht abgelaufene) Zonendaten verfügt. Wenn der Slave keine neue Kopie der Zonendaten erhält, antwortet er nicht mehr für die Zone.

Forwarder

Forwarders sind DNS-Server, an die der DNS-Server Abfragen sendet, die er nicht bearbeiten kann. Zum Aktivieren verschiedener Konfigurationsquellen in einer Konfiguration wird netconfig verwendet (siehe auch man 8 netconfig).

Datensatz

Der Eintrag besteht aus Informationen zu Namen und IP-Adresse. Die unterstützten Einträge und ihre Syntax sind in der BIND-Dokumentation beschrieben. Einige spezielle Einträge sind beispielsweise:

NS-Eintrag

Ein NS-Eintrag informiert die Namenserver darüber, welche Computer für eine bestimmte Domänenzone zuständig sind.

MX-Eintrag

Die MX (Mailaustausch)-Einträge beschreiben die Computer, die für die Weiterleitung von Mail über das Internet kontaktiert werden sollen.

SOA-Eintrag

Der SOA (Start of Authority)-Eintrag ist der erste Eintrag in einer Zonendatei. Der SOA-Eintrag wird bei der Synchronisierung von Daten zwischen mehreren Computern über DNS verwendet.

31.2 Installation

Zur Installation eines DNS-Servers starten Sie YaST, und wählen Sie Software › Software installieren oder löschen. Wählen Sie Ansicht › Schemata und schließlich DHCP- und DNS-Server aus. Bestätigen Sie die Installation der abhängigen Pakete, um den Installationsvorgang abzuschließen.

Alternativ geben Sie den folgenden Befehl in der Befehlszeile ein:

tux > sudo zypper in -t pattern dhcp_dns_server

31.3 Konfiguration mit YaST

Verwenden Sie das DNS-Modul von YaST, um einen DNS-Server für das lokale Netzwerk zu konfigurieren. Beim ersten Starten des Moduls werden Sie von einem Assistenten aufgefordert, einige grundlegende Entscheidungen hinsichtlich der Serveradministration zu treffen. Mit dieser Ersteinrichtung wird eine grundlegende Serverkonfiguration vorgenommen. Für erweiterte Konfigurationsaufgaben, beispielsweise zum Einrichten von ACLs, für Protokollaufgaben, TSIG-Schlüssel und andere Optionen, verwenden Sie den Expertenmodus.

31.3.1 Assistentenkonfiguration

Der Assistent besteht aus drei Schritten bzw. Dialogfeldern. An bestimmten Stellen im Dialogfeld können Sie in den Konfigurationsmodus für Experten wechseln.

  1. Wenn Sie das Modul zum ersten Mal starten, wird das Dialogfeld Forwarder-Einstellungen (siehe Abbildung 31.1, „DNS-Server-Installation: Forwarder-Einstellungen“) geöffnet. Die Richtlinie für lokale DNS-Auflösung bietet die folgenden Optionen:

    • Zusammenführen von Forwardern ist deaktiviert

    • Automatisches Zusammenführen

    • Zusammenführen von Forwardern ist aktiviert

    • Benutzerdefinierte Konfiguriation – Wenn die benutzerdefinierte Konfiguriation aktiviert ist, können Sie die benutzerdefinierte Richtlinie angeben. Standardmäßig (Option Automatisches Zusammenführen ist aktiviert) ist die benutzerdefinierte Richtlinie auf automatisch eingestellt; hier können Sie die Schnittstellennamen jedoch selbst festlegen oder aus den beiden besonderen Richtliniennamen STATIC und STATIC_FALLBACK wählen.

    Geben Sie unter Forwarder für lokale DNS-Auflösung den zu verwendenden Service an: System-Nameserver werden verwendet, Dieser Nameserver (Bind) oder Lokaler dnsmasq-Server.

    Weitere Informationen zu diesen Einstellungen finden Sie auf der man-Seite man 8 netconfig.

    DNS-Server-Installation: Forwarder-Einstellungen
    Abbildung 31.1: DNS-Server-Installation: Forwarder-Einstellungen

    Forwarders sind DNS-Server, an die der DNS-Server Abfragen sendet, die er nicht selbst bearbeiten kann. Geben Sie ihre IP-Adresse ein und klicken Sie auf Hinzufügen.

  2. Das Dialogfeld DNS-Zonen besteht aus mehreren Teilen und ist für die Verwaltung von Zonendateien zuständig, wie in Abschnitt 31.6, „Zonendateien“ beschrieben. Bei einer neuen müssen Sie unter Name der Zone einen Namen angeben. Um eine Reverse Zone hinzuzufügen, muss der Name auf .in-addr.arpa enden. Wählen Sie zum Schluss den Typ (Master, Slave oder Forward) aus. Weitere Informationen hierzu finden Sie im Abbildung 31.2, „DNS-Server-Installation: DNS-Zonen“. Klicken Sie auf Bearbeiten, um andere Einstellungen für eine bestehende Zone zu konfigurieren. Zum Entfernen einer klicken Sie auf Zone löschen.

    DNS-Server-Installation: DNS-Zonen
    Abbildung 31.2: DNS-Server-Installation: DNS-Zonen
  3. Im letzten Dialogfeld können Sie den DNS-Port in der Firewall öffnen, indem Sie auf Firewall-Port öffnen klicken. Legen Sie anschließend fest, ob der DNS-Server beim Booten gestartet werden soll (Ein oder Aus). Außerdem können Sie die LDAP-Unterstützung aktivieren. Siehe Abbildung 31.3, „DNS-Server-Installation: Wizard beenden“.

    DNS-Server-Installation: Wizard beenden
    Abbildung 31.3: DNS-Server-Installation: Wizard beenden

31.3.2 Konfiguration für Experten

Nach dem Starten des Moduls öffnet YaST ein Fenster, in dem mehrere Konfigurationsoptionen angezeigt werden. Nach Abschluss dieses Fensters steht eine DNS-Server-Konfiguration mit Grundfunktionen zur Verfügung:

31.3.2.1 Start

Legen Sie unter Start fest, ob der DNS-Server beim Booten des Systems oder manuell gestartet werden soll. Um den DNS-Server sofort zu starten, klicken Sie auf DNS-Server nun starten. Um den DNS-Server anzuhalten, klicken Sie auf DNS-Server nun anhalten. Zum Speichern der aktuellen Einstellungen wählen Sie Jetzt Einstellungen speichern und DNS-Server neu laden. Sie können den DNS-Anschluss in der Firewall mit Firewall-Port öffnen öffnen und die Firewall-Einstellungen mit Firewall-Details bearbeiten.

Wenn Sie LDAP-Unterstützung aktiv wählen, werden die Zone-Dateien von einer LDAP-Datenbank verwaltet. Alle Änderungen an Zonendaten, die in der LDAP-Datenbank gespeichert werden, werden vom DNS-Server erfasst, wenn er neu gestartet oder aufgefordert wird, seine Konfiguration neu zu laden.

31.3.2.2 Forwarder

Falls Ihr lokaler DNS-Server eine Anforderung nicht beantworten kann, versucht er, diese Anforderung an einen Forwarder weiterzuleiten, falls dies so konfiguriert wurde. Dieser Forwarder kann manuell zur Forwarder-Liste hinzugefügt werden. Wenn der Forwarder nicht wie bei Einwahlverbindungen statisch ist, wird die Konfiguration von netconfig verarbeitet. Weitere Informationen über netconfig finden Sie auf man 8 netconfig.

31.3.2.3 Grundlegende Optionen

In diesem Abschnitt werden grundlegende Serveroptionen festgelegt. Wählen Sie im Menü Option das gewünschte Element aus, und geben Sie dann den Wert im entsprechenden Textfeld an. Nehmen Sie den neuen Eintrag auf, indem Sie auf Hinzufügen klicken.

31.3.2.4 Protokollierung

Um festzulegen, was und wie der DNS-Server protokollieren soll, wählen Sie Protokollieren aus. Geben Sie unter Protokolltyp an, wohin der DNS-Server die Protokolldaten schreiben soll. Verwenden Sie das systemweite Protokoll durch Auswahl von Systemprotokoll, oder geben Sie durch Auswahl von Datei eine andere Datei an. In letzterem Fall müssen Sie außerdem einen Namen, die maximale Dateigröße in Megabyte und die Anzahl der zu speichernden Versionen von Protokolldateien angeben.

Weitere Optionen sind unter Zusätzliches Protokollieren verfügbar. Durch Aktivieren von Alle DNS-Abfragen protokollieren wird jede Abfrage protokolliert. In diesem Fall kann die Protokolldatei extrem groß werden. Daher sollte diese Option nur zur Fehlersuche aktiviert werden. Um den Datenverkehr zu protokollieren, der während Zonenaktualisierungen zwischen dem DHCP- und dem DNS-Server stattfindet, aktivieren Sie Zonen-Updates protokollieren. Um den Datenverkehr während eines Zonentransfers von Master zu Slave zu protokollieren, aktivieren Sie Zonen-Transfer protokollieren. Siehe Abbildung 31.4, „DNS-Server: Protokollieren“.

DNS-Server: Protokollieren
Abbildung 31.4: DNS-Server: Protokollieren

31.3.2.5 ACLs

In diesem Dialogfeld legen Sie ACLs (Access Control Lists = Zugriffssteuerungslisten) fest, mit denen Sie den Zugriff einschränken. Nach der Eingabe eines eindeutigen Namens unter Name geben Sie unter Wert eine IP-Adresse (mit oder ohne Netzmaske) wie folgt an:

{ 192.168.1/24; }

Die Syntax der Konfigurationsdatei erfordert, dass die Adresse mit einem Strichpunkt endet und in geschwungenen Klammern steht.

31.3.2.6 TSIG-Schlüssel

Der Hauptzweck von TSIG-Schlüsseln (Transaction Signatures = Transaktionssignaturen) ist die Sicherung der Kommunikation zwischen DHCP- und DNS-Servern. Diese werden unter Abschnitt 31.8, „Sichere Transaktionen“ beschrieben.

Zum Erstellen eines TSIG-Schlüssels geben Sie einen eindeutigen Namen im Feld mit der Beschriftung Schlüssel-ID ein und geben die Datei an, in der der Schlüssel gespeichert werden soll (Dateiname). Bestätigen Sie Ihre Einstellung mit Erzeugen.

Wenn Sie einen vorher erstellten Schlüssel verwenden möchten, lassen Sie das Feld Schlüssel-ID leer und wählen die Datei, in der der gewünschte Schlüssel gespeichert wurde, unter Dateiname. Dann bestätigen Sie die Auswahl mit Hinzufügen.

31.3.2.7 DNS-Zonen (Hinzufügen einer Slave-Zone)

Wenn Sie eine Slave-Zone hinzufügen möchten, klicken Sie auf DNS-Zonen, wählen Sie den Zonentyp Slave aus, geben Sie den Namen der neuen Zone ein und klicken Sie auf Hinzufügen.

Geben Sie im Zonen-Editor unter IP des Master DNS-Servers den Master an, von dem der Slave die Daten abrufen soll. Um den Zugriff auf den Server zu beschränken, wählen Sie eine der ACLs aus der Liste aus.

31.3.2.8 DNS-Zonen (Hinzufügen einer Master-Zone)

Wenn Sie eine Masterzone hinzufügen möchten, klicken Sie auf DNS-Zonen, wählen Sie den Zonentyp Master aus, geben Sie den Namen der neuen Zone ein und klicken Sie auf Hinzufügen. Beim Hinzufügen einer Masterzone ist auch eine Reverse Zone erforderlich. Wenn Sie beispielsweise die Zone example.com hinzufügen, die auf Hosts in einem Subnetz 192.168.1.0/24 zeigt, sollten Sie auch eine Reverse Zone für den betreffenden IP-Adressbereich erstellen. Per Definition sollte dieser den Namen 1.168.192.in-addr.arpa erhalten.

31.3.2.9 DNS-Zonen (Bearbeiten einer Master-Zone)

Wenn Sie eine Masterzone bearbeiten möchten, klicken Sie auf DNS-Zonen, wählen Sie die Masterzone in der Tabelle aus und klicken Sie auf Bearbeiten. Dieses Dialogfeld besteht aus mehreren Seiten: Grundlagen (die zuerst geöffnete Seite), DNS-Einträge, MX-Einträge, SOA und Einträge.

Im grundlegenden Dialogfeld in Abbildung 31.5, „DNS-Server: Zonen-Editor (Grundlagen)“ können Sie die Einstellungen für das dynamische DNS festlegen und auf Optionen für Zonentransfers an Clients und Slave-Namenserver zugreifen. Zum Zulassen dynamischer Aktualisierungen von Zonen wählen Sie Dynamische Updates erlauben und den entsprechenden TSIG-Schlüssel. Der Schlüssel muss definiert werden, bevor die Aktualisierung startet. Zum Aktivieren der Zonentransfers wählen Sie die entsprechenden ACLs. ACLs müssen bereits definiert sein.

Wählen Sie im Dialogfeld Grundlagen aus, ob Zonen-Transfers aktiviert werden sollen. Verwenden Sie die aufgelisteten ACLs, um festzulegen, wer Zonen herunterladen kann.

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

Im Dialogfeld NS-Einträge können Sie alternative Nameserver für die angegebenen Zonen definieren. Vergewissern Sie sich, dass Ihr eigener Namenserver in der Liste enthalten ist. Um einen Eintrag hinzuzufügen, geben Sie seinen Namen unter Hinzuzufügender Namenserver ein und bestätigen Sie den Vorgang anschließend mit Hinzufügen. Siehe Abbildung 31.6, „DNS-Server: Zonen-Editor (NS-Einträge)“.

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

Um einen Mailserver für die aktuelle Zone zur bestehenden Liste hinzuzufügen, geben Sie die entsprechende Adresse und den entsprechenden Prioritätswert ein. Bestätigen Sie den Vorgang anschließend durch Auswahl von Hinzufügen. Siehe Abbildung 31.7, „DNS-Server: Zonen-Editor (MX-Einträge)“.

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

Auf dieser Seite können Sie SOA (Start of Authority)-Einträge erstellen. Eine Erklärung der einzelnen Optionen finden Sie in Beispiel 31.6, „Die Datei /var/lib/named/example.com.zone“. Das Ändern von SOA-Datensätzen wird für dynamischen Zonen, die über LDAP verwaltet werden, nicht unterstützt.

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

In diesem Dialogfeld wird die Namenauflösung verwaltet. Geben Sie unter Eintragschlüssel den Hostnamen an, und wählen Sie anschließend den Typ aus. Der Typ A bezeichnet den Haupteintrag. Der Wert hierfür sollte eine IP-Adresse (IPv4) sein. Für IPv6-Adressen verwenden Sie AAAA. CNAME ist ein Alias. Verwenden Sie die Typen NS und MX für detaillierte oder partielle Einträge, mit denen die Informationen aus den Registerkarten NS-Einträge und MX-Einträge erweitert werden. Diese drei Typen werden in einen bestehenden A-Eintrag aufgelöst. PTR dient für Reverse Zones. Es handelt sich um das Gegenteil eines A-Eintrags, wie zum Beispiel:

hostname.example.com. IN A 192.168.0.1
1.0.168.192.in-addr.arpa IN PTR hostname.example.com.
31.3.2.9.1 Hinzufügen von Reverse Zones

So fügen Sie eine Reverse Zone hinzu:

  1. Starten Sie YaST › DNS-Server › DNS-Zonen.

  2. Falls Sie noch keine Forward-Masterzone angelegt haben, holen Sie dies jetzt nach und bearbeiten Sie sie.

  3. Geben Sie auf der Registerkarte Einträge den entsprechenden Eintragsschlüssel und Eintragswert an. Legen Sie dann den Eintrag mit Hinzufügen an und bestätigen Sie den Vorgang mit OK. Wenn YaST eine Meldung ausgibt, dass ein Eintrag für einen Nameserver fehlt, geben Sie diesen Eintrag auf der Registerkarte DNS-Einträge an.

    Hinzufügen eines Eintrags für eine Master Zone
    Abbildung 31.9: Hinzufügen eines Eintrags für eine Master Zone
  4. Fügen Sie im Fenster DNS-Zonen eine Reverse-Masterzone hinzu.

    Hinzufügen einer Reverse Zone
    Abbildung 31.10: Hinzufügen einer Reverse Zone
  5. Bearbeiten Sie die Reverse Zone. Auf der Registerkarte Einträge wird der Eintragstyp PTR: Umgekehrte Übersetzung aufgeführt. Geben Sie den entsprechenden Eintragsschlüssel und Eintragswert an, klicken Sie auf Hinzufügen und bestätigen Sie den Vorgang mit OK.

    Hinzufügen eines Reverse-Eintrags
    Abbildung 31.11: Hinzufügen eines Reverse-Eintrags

    Fügen Sie bei Bedarf einen Nameserver-Eintrag hinzu.

Tipp
Tipp: Bearbeiten der Reverse Zone

Wechseln Sie nach dem Hinzufügen einer Forward Zone wieder in das Hauptmenü und wählen Sie die Reverse Zone zur Bearbeitung aus. Markieren Sie im Karteireiter Grundlagen das Kontrollkästchen Einträge automatisch generieren aus und wählen Sie Ihre Forward Zone aus. Auf diese Weise werden alle Änderungen an der Forward Zone automatisch in der Reverse Zone aktualisiert.

31.4 Starten des BIND-Nameservers

Bei SUSE® Linux Enterprise Server-Systemen ist der Namenserver BIND (Berkeley Internet Name Domain) vorkonfiguriert, sodass er problemlos unmittelbar nach der Installation gestartet werden kann. Wenn Sie bereits über eine funktionierende Internetverbindung verfügen und 127.0.0.1 als Namenserver-Adresse für localhost in /var/run/netconfig/resolv.conf eingegeben haben, verfügen Sie normalerweise bereits über eine funktionierende Namensauflösung, ohne dass Ihnen der DNS des Anbieters bekannt sein muss. BIND führt die Namenauflösung über den Root-Namenserver durch. Dies ist ein wesentlich langsamerer Prozess. Normalerweise sollte der DNS des Anbieters zusammen mit der zugehörigen IP-Adresse in die Konfigurationsdatei /etc/named.conf unter forwarders eingegeben werden, um eine effektive und sichere Namenauflösung zu gewährleisten. Wenn dies so weit funktioniert, wird der Namenserver als reiner Nur-Cache-Namenserver ausgeführt. Nur wenn Sie seine eigenen Zonen konfigurieren, wird er ein richtiger DNS. Ein einfaches Beispiel zur Veranschaulichung finden Sie unter /usr/share/doc/packages/bind/config.

Tipp
Tipp: Automatische Anpassung der Nameserverinformationen

Je nach Typ der Internet- bzw. Netzwerkverbindung können die Namenserverinformationen automatisch an die aktuellen Bedingungen angepasst werden. Legen Sie die Variable NETCONFIG_DNS_POLICY in der Datei /etc/sysconfig/network/config dazu auf auto fest.

Richten Sie jedoch erst eine offizielle Domäne ein, wenn Sie eine Domäne von der zuständigen Stelle zugewiesen bekommen. Selbst wenn Sie eine eigene Domäne besitzen und diese vom Anbieter verwaltet wird, sollten Sie sie besser nicht verwenden, da BIND ansonsten keine Anforderungen für diese Domäne weiterleitet. Beispielsweise könnte in diesem Fall für diese Domäne der Zugriff auf den Webserver beim Anbieter nicht möglich sein.

Starten Sie den Nameserver mit dem Befehl systemctl start named als root. Prüfen Sie mit systemctl status named, ob der Nameserverprozess „named“ ordnungsgemäß gestartet wurde. Testen Sie den Nameserver umgehend auf dem lokalen System mit den Programmen host oder dig. Sie sollten localhost als Standardserver mit der Adresse 127.0.0.1 zurückgeben. Ist dies nicht der Fall, enthält /var/run/netconfig/resolv.conf wahrscheinlich einen falschen Nameserver-Eintrag oder die Datei ist nicht vorhanden. Geben Sie beim ersten Test host 127.0.0.1 ein. Dieser Eintrag sollte immer funktionieren. Wenn Sie eine Fehlermeldung erhalten, überprüfen Sie mit systemctl status named, ob der Server tatsächlich ausgeführt wird. Wenn der Nameserver nicht startet oder sich ungewöhnlich verhält, prüfen Sie die Ausgabe von journalctl -e.

Um den Namenserver des Anbieters (oder einen bereits in Ihrem Netzwerk ausgeführten Server) als Forwarder zu verwenden, geben Sie die entsprechende IP-Adresse(n) im Abschnitt options unter forwarders ein. Bei den Adressen in Beispiel 31.1, „Weiterleitungsoptionen in named.conf“ handelt es sich lediglich um Beispiele. Passen Sie diese Einträge an Ihr eigenes Setup an.

Beispiel 31.1: Weiterleitungsoptionen 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.1.116; };
        allow-query { 127/8; 192.168/16 };
        notify no;
};

Auf den Eintrag options folgen Einträge für die Zone, localhost und 0.0.127.in-addr.arpa. Der Eintrag type hint unter . muss stets vorhanden sein. Die entsprechenden Dateien müssen nicht bearbeitet werden und sollten so funktionieren, wie sie sind. Achten Sie außerdem darauf, dass jeder Eintrag mit einem ; abgeschlossen ist und dass sich die geschweiften Klammern an der richtigen Position befinden. Nach dem Ändern der Konfigurationsdatei /etc/named.conf oder der Zonendateien müssen Sie BIND anweisen, diese Datei(en) erneut zu lesen. Führen Sie hierzu den Befehl systemctl reload named aus. Dieselbe Wirkung erzielen Sie, wenn Sie den Nameserver mit systemctl restart named anhalten und neu starten. Sie können den Server jederzeit mit systemctl stop named anhalten.

31.5 Die Konfigurationsdatei /etc/named.conf

Alle Einstellungen für den BIND-Namenserver selbst sind in der Datei /etc/named.conf gespeichert. Die Zonendaten für die zu bearbeitenden Domänen, die aus Hostnamen, IP-Adressen usw. bestehen, sind jedoch in gesonderten Dateien im Verzeichnis /var/lib/named gespeichert. Einzelheiten hierzu werden weiter unten beschrieben.

/etc/named.conf lässt sich grob in zwei Bereiche untergliedern. Der eine ist der Abschnitt options für allgemeine Einstellungen und der zweite besteht aus zone-Einträgen für die einzelnen Domänen. Der Abschnitt logging und die Einträge unter acl (access control list, Zugriffssteuerungsliste) sind optional. Kommentarzeilen beginnen mit # oder mit //. Eine Minimalversion von /etc/named.conf finden Sie in Beispiel 31.2, „Eine Grundversion von /etc/named.conf“.

Beispiel 31.2: Eine Grundversion von /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";
};

31.5.1 Wichtige Konfigurationsoptionen

directory "DATEINAME";

Gibt das Verzeichnis an, in dem BIND die Dateien mit den Zonendaten finden kann. In der Regel ist dies /var/lib/named.

forwarders { IP-ADRESSE; };

Gibt die Namenserver (zumeist des Anbieters) an, an die DNS-Anforderungen weitergeleitet werden sollen, wenn sie nicht direkt aufgelöst werden können. Ersetzen Sie IP-ADRESSE durch eine IP-Adresse wie 192.168.1.116.

forward first;

Führt dazu, dass DNS-Anforderungen weitergeleitet werden, bevor versucht wird, sie über die Root-Namenserver aufzulösen. Anstatt forward first kann forward only verwendet werden. Damit werden alle Anforderungen weitergeleitet, ohne dass sie an die Root-Namenserver gesendet werden. Dies ist bei Firewall-Konfigurationen sinnvoll.

listen-on port 53 { 127.0.0.1; IP-ADRESSE; };

Informiert BIND darüber, an welchen Netzwerkschnittstellen und Ports Client-Abfragen akzeptiert werden sollen. port 53 muss nicht explizit angegeben werden, da 53 der Standardport ist. Geben Sie 127.0.0.1 ein, um Anforderungen vom lokalen Host zuzulassen. Wenn Sie diesen Eintrag ganz auslassen, werden standardmäßig alle Schnittstellen verwendet.

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

Informiert BIND darüber, welcher Port auf IPv6-Client-Anforderungen überwacht werden soll. Die einzige Alternative zu any ist none. Bei IPv6 akzeptiert der Server nur Platzhalteradressen.

query-source address * port 53;

Dieser Eintrag ist erforderlich, wenn eine Firewall ausgehende DNS-Anforderungen blockiert. Dadurch wird BIND angewiesen, Anforderungen extern von Port 53 und nicht von einem der Ports mit den hohen Nummern über 1024 aufzugeben.

query-source-v6 address * port 53;

Informiert BIND darüber, welcher Port für IPv6-Abfragen verwendet werden soll.

allow-query \{ 127.0.0.1; NETZ; };

Definiert die Netzwerke, von denen aus Clients DNS-Anforderungen aufgeben können. Ersetzen Sie NETZ durch Adressinformationen wie 192.168.2.0/24. Der Wert /24 am Ende ist ein abgekürzter Ausdruck für die Netzmaske, hier 255.255.255.0).

allow-transfer ! *;;

Legt fest, welche Hosts Zonentransfers anfordern können. Im vorliegenden Beispiel werden solche Anforderungen mit ! * vollständig verweigert. Ohne diesen Eintrag können Zonentransfer ohne Einschränkungen von jedem beliebigen Ort aus angefordert werden.

statistics-interval 0;

Ohne diesen Eintrag generiert BIND im Systemjournal mehrere Zeilen mit statistischen Informationen pro Stunde. Setzen Sie diesen Wert auf „0“, um diese Statistiken vollständig zu unterdrücken, oder legen Sie ein Zeitintervall in Minuten fest.

cleaning-interval 720;

Diese Option legt fest, in welchen Zeitabständen BIND den Cache leert. Damit wird bei jedem Ausführen dieses Vorgangs ein Eintrag im Systemjournal ausgelöst. Die verwendete Einheit für die Zeitangabe ist Minuten. Der Standardwert ist 60 Minuten.

interface-interval 0;

BIND durchsucht die Netzwerkschnittstellen regelmäßig nach neuen oder nicht vorhandenen Schnittstellen. Wenn dieser Wert auf 0 gesetzt ist, wird dieser Vorgang nicht durchgeführt und BIND überwacht nur die beim Start erkannten Schnittstellen. Anderenfalls wird das Zeitintervall in Minuten angegeben. Der Standardwert ist 60 Minuten.

notify no;

no verhindert, dass anderen Namenserver informiert werden, wenn Änderungen an den Zonendaten vorgenommen werden oder wenn der Namenserver neu gestartet wird.

Eine Liste der verfügbaren Optionen finden Sie auf der man-Seite man 5 named.conf.

31.5.2 Protokollierung

Der Umfang, die Art und Weise und der Ort der Protokollierung kann in BIND extensiv konfiguriert werden. In der Regel dürften die Standardeinstellungen ausreichen. Beispiel 31.3, „Eintrag zur Deaktivierung der Protokollierung“ zeigt die einfachste Form eines solchen Eintrags und unterdrückt die Protokollierung vollständig.

Beispiel 31.3: Eintrag zur Deaktivierung der Protokollierung
logging {
        category default { null; };
};

31.5.3 Zoneneinträge

Beispiel 31.4: Zoneneintrag für „example.com“
zone "example.com" in {
      type master;
      file "example.com.zone";
      notify no;
};

Geben Sie nach zone den Namen der zu verwaltenden Domäne (example.com) an, gefolgt von in und einem Block relevanter Optionen in geschweiften Klammern, wie in Beispiel 31.4, „Zoneneintrag für „example.com““ gezeigt. Um eine Slave-Zone zu definieren, ändern Sie den Wert von type in slave und geben Sie einen Namenserver an, der diese Zone als master verwaltet (dieser kann wiederum ein Slave eines anderen Masters sein), wie in Beispiel 31.5, „Zoneneintrag für „example.net““ gezeigt.

Beispiel 31.5: Zoneneintrag für „example.net“
zone "example.net" in {
      type slave;
      file "slave/example.net.zone";
      masters { 10.0.0.1; }; 
};

Zonenoptionen:

type master;

Durch die Angabe master wird BIND darüber informiert, dass der lokale Namenserver für die Zone zuständig ist. Dies setzt voraus, dass eine Zonendatei im richtigen Format erstellt wurde.

type slave;

Diese Zone wird von einem anderen Namenserver übertragen. Sie muss zusammen mit masters verwendet werden.

type hint;

Die Zone . vom Typ hint wird verwendet, um den root-Namenserver festzulegen. Diese Zonendefinition kann unverändert beibehalten werden.

file example.com.zone or file slave/example.net.zone;

In diesem Eintrag wird die Datei angegeben, in der sich die Zonendaten für die Domäne befinden. Diese Datei ist für einen Slave nicht erforderlich, da die betreffenden Daten von einem anderen Namenserver abgerufen werden. Um zwischen Master- und Slave-Dateien zu unterscheiden, verwenden Sie das Verzeichnis slave für die Slave-Dateien.

importserver { SERVER_IP_ADRESSE; };

Dieser Eintrag ist nur für Slave-Zonen erforderlich. Er gibt an, von welchem Namenserver die Zonendatei übertragen werden soll.

allow-update {! *; };

Mit dieser Option wird der externe Schreibzugriff gesteuert, der Clients das Anlegen von DNS-Einträgen gestatten würde. Dies ist in der Regel aus Sicherheitsgründen nicht erstrebenswert. Ohne diesen Eintrag sind keine Zonenaktualisierungen zulässig. Der oben stehende Eintrag hat dieselbe Wirkung, da ! * solche Aktivitäten effektiv unterbindet.

31.6 Zonendateien

Zwei Arten von Zonendateien sind erforderlich. Eine Art ordnet IP-Adressen Hostnamen zu, die andere stellt Hostnamen für IP-Adressen bereit.

Tipp
Tipp: Verwenden des Punkts in Zonendateien

Im Verzeichnis “.“ hat eine wichtige Bedeutung in den Zonendateien. Bei Angabe von Hostnamen ohne abschließenden Punkt (.) wird die Zone angehängt. Vollständige Hostnamen mit vollständiger Domäne benötigen den abschließenden Punkt (.), damit die Domäne nicht erneut hinzugefügt wird. Ein fehlender oder falsch gesetzter Punkt („.“) ist wahrscheinlich die häufigste Ursache für Nameserver-Konfigurationsfehler.

Der erste zu betrachtende Fall ist die Zonendatei example.com.zone, die für die Domäne example.com zuständig ist (siehe Beispiel 31.6, „Die Datei /var/lib/named/example.com.zone“).

Beispiel 31.6: Die Datei /var/lib/named/example.com.zone
$TTL 2D 1
example.com. IN SOA      dns  root.example.com. ( 2
             2003072441  ; serial 3
             1D          ; refresh 4
             2H          ; retry 5
             1W          ; expiry 6
             2D )        ; minimum 7

             IN NS       dns 8
             IN MX       10 mail dns 9
gate         IN A        192.168.5.1 10
             IN A        10.0.0.1
dns          IN A        192.168.1.116
mail         IN A        192.168.3.108
jupiter      IN A        192.168.2.100
venus        IN A        192.168.2.101
saturn       IN A        192.168.2.102
mercury      IN A        192.168.2.103
ntp          IN CNAME    dns 11
dns6         IN A6  0    2002:c0a8:174::

1

$TTL legt die Standardlebensdauer fest, die für alle Einträge in dieser Datei gelten soll. In diesem Beispiel sind die Einträge zwei Tage lang gültig (2 D).

2

Hier beginnt der SOA (Start of Authority)-Steuereintrag:

  • Der Name der zu verwaltenden Domäne ist example.com an der ersten Stelle. Dieser Eintrag endet mit „.“, da andernfalls die Zone ein zweites Mal angefügt würde. Alternativ kann hier @ eingegeben werden. In diesem Fall wird die Zone aus dem entsprechenden Eintrag in /etc/named.conf extrahiert.

  • Nach IN SOA befindet sich der Name des Namenservers, der als Master für diese Zone fungiert. Der Name wird von dns zu dns.example.com erweitert, da er nicht mit „.“ endet.

  • Es folgt die Email-Adresse der für diesen Namenserver zuständigen Person. Da das Zeichen @ bereits eine besondere Bedeutung hat, wird hier „.“ eingegeben. Für root@example.com lautet der Eintrag root.example.com.. Im Verzeichnis „.“ muss angehängt werden, damit die Zone nicht hinzugefügt wird.

  • Durch ( werden alle Zeilen bis einschließlich ) in den SOA-Eintrag aufgenommen.

3

Die Seriennummer ist eine 10-stellige Zahl. Sie muss bei jeder Änderung der Datei ebenfalls geändert werden. Sie wird benötigt, um die sekundären Namenserver (Slave-Server) über Änderungen zu informieren. Dazu ist nun eine 10-stellige Zahl für das Datum und die Laufzeitnummer, geschrieben als YYYYMMDDNN, das übliche Format (YYYY = Jahr, MM = Monat und DD = Tag. NN ist eine Sequenznummer, falls sie an einem Tag mehr als einmal aktualisiert wird).

4

Die Aktualisierungsrate (refresh rate) gibt das Zeitintervall an, in dem die sekundären Namenserver die Seriennummer (serial) der Zone überprüfen. In diesem Fall beträgt dieses Intervall einen Tag.

5

Die Wiederholungsrate (retry) gibt das Zeitintervall an, nach dem ein sekundärer Namenserver bei einem Fehler erneut versucht, Kontakt zum primären Server herzustellen. In diesem Fall sind dies zwei Stunden.

6

Die Ablaufzeit (expiry) gibt den Zeitraum an, nach dem ein sekundärer Server die im Cache gespeicherten Daten verwirft, wenn er keinen erneuten Kontakt zum primären Server herstellen konnte. Hier eine Woche.

7

Die letzte Angabe im SOA-Eintrag gibt die negative Cache-Lebensdauer negative caching TTL an – die Zeitdauer, die Ergebnisse nicht aufgelter DNS-Abfragen von anderen Servern im Cache gespeichert werden knen.

8

IN NS gibt den für diese Domäne verantwortlichen Namenserver an. dns wird zu dns.example.com erweitert; der Eintrag endet nicht auf einen „.“. Es kann mehrere solche Zeilen geben – eine für den primären und jeweils eine für jeden sekundären Namenserver. Wenn notify in /etc/named.conf nicht auf no gesetzt ist, werden alle hier aufgeführten Namenserver über die Änderungen an den Zonendaten informiert.

9

Der MX-Eintrag gibt den Mailserver an, der Emails für die Domäne example.com annimmt, verarbeitet und weiterleitet. In diesem Beispiel ist dies der Host mail.example.com. Die Zahl vor dem Hostnamen ist der Präferenzwert. Wenn mehrere MX-Einträge vorliegen, wird zuerst der Mailserver mit dem kleinsten Wert herangezogen. Falls die Emails nicht an diesen Server zugestellt werden können, wird der Eintrag mit dem nächstkleineren Wert verwendet.

10

Diese und die folgenden Zeilen sind die eigentlichen Adresseinträge, in denen den Hostnamen eine oder mehrere IP-Adressen zugewiesen werden. Die Namen werden hier ohne „.“ aufgelistet, da sie ihre Domäne nicht enthalten. Daher wird ihnen allen example.com hinzugefügt. Dem Host gate werden zwei IP-Adressen zugewiesen, da er zwei Netzwerkkarten aufweist. Bei jeder traditionellen Hostadresse (IPv4) wird der Eintrag mit A gekennzeichnet. Wenn es sich um eine IPv6-Adresse handelt, wird der Eintrag mit AAAA gekennzeichnet.

Anmerkung
Anmerkung: IPv6-Syntax

Die Syntax des IPv6-Eintrags unterscheidet sich geringfügig von der Syntax von IPv4. Aufgrund der Möglichkeit einer Fragmentierung müssen Informationen zu fehlenden Bits vor der Adresse angegeben werden. Um die IPv6-Adresse mit dem erforderlichen Wert 0 auszufüllen, fügen Sie an der korrekten Stelle in der Adresse zwei Doppelpunkte hinzu.

pluto     AAAA 2345:00C1:CA11::1234:5678:9ABC:DEF0
pluto     AAAA 2345:00D2:DA11::1234:5678:9ABC:DEF0

11

Der Alias ntp kann zur Adressierung von dns (CNAME steht für canonical name (kanonischer Name)) verwendet werden.

Die Pseudodomäne in-addr.arpa wird für Reverse-Lookups zur Auflösung von IP-Adressen in Hostnamen verwendet. Sie wird in umgekehrter Notation an den Netzwerk-Teil der Adresse angehängt. 192.168 wird also in 168.192.in-addr.arpa aufgelöst. Siehe Beispiel 31.7, „Reverse-Lookup“.

Beispiel 31.7: Reverse-Lookup
$TTL 2D 1
168.192.in-addr.arpa.   IN SOA dns.example.com. root.example.com. ( 2
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           dns.example.com. 3

1.5                     IN PTR          gate.example.com. 4
100.3                   IN PTR          www.example.com.
253.2                   IN PTR          cups.example.com.

1

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

2

Die Konfigurationsdatei muss Reverse-Lookup für das Netzwerk 192.168 aktivieren. Wenn die Zone 168.192.in-addr.arpa heißt, sollte sie nicht zu den Hostnamen hinzugefügt werden. Alle Domänen werden daher in vollständiger Form eingegeben: mit ihrer Domäne und mit schließendem „.“.). Die restlichen Einträge entsprechen den im vorherigen Beispiel (example.com) beschriebenen Einträgen.

In Beispiel 31.6, „Die Datei /var/lib/named/example.com.zone“ finden Sie weitere Details zu den Einträgen in diesem Datensatz.

3

Diese Zeile gibt den für diese Zone verantwortlichen Nameserver an. Diesmal wird der Name allerdings in vollständiger Form mit Domäne und „.“ am Ende eingegeben.

4

Diese und die folgenden Zeilen sind die Zeiger-Datensätze, die auf die IP-Adressen an den entsprechenden Hosts hinweisen. Am Anfang der Zeile wird nur der letzte Teil der IP-Adresse eingegeben, ohne „.“ am Ende. Wenn daran die Zone angehängt wird (ohne .in-addr.arpa), ergibt sich die vollständige IP-Adresse in umgekehrter Reihenfolge.

Normalerweise sollten Zonentransfers zwischen verschiedenen Versionen von BIND problemlos möglich sein.

31.7 Dynamische Aktualisierung von Zonendaten

Der Ausdruck dynamische Aktualisierung bezieht sich auf Vorgänge, bei denen Einträge in den Zonendateien eines Masterservers hinzugefügt, geändert oder gelöscht werden. Dieser Mechanismus wird in RFC 2136 beschrieben. Die dynamische Aktualisierung wird einzeln für jeden Zoneneintrag konfiguriert; hierzu wird eine optionale Regel allow-update oder update-policy eingefügt. Dynamisch zu aktualisierende Zonen sollten nicht von Hand bearbeitet werden.

Die zu aktualisierenden Einträge werden mit dem Befehl nsupdate an den Server übermittelt. Die genaue Syntax dieses Befehls können Sie der man-Seite für nsupdate (man8 nsupdate) entnehmen. Aus Sicherheitsgründen sollten solche Aktualisierungen mithilfe von TSIG-Schlüsseln durchgeführt werden, wie in Abschnitt 31.8, „Sichere Transaktionen“ beschrieben.

31.8 Sichere Transaktionen

Sichere Transaktionen können mit Transaktionssignaturen (TSIGs) durchgeführt werden, die auf gemeinsam genutzten geheimen Schlüsseln (auch TSIG-Schlüssel genannt) beruhen. In diesem Abschnitt wird die Erstellung und Verwendung solcher Schlüssel beschrieben.

Sichere Transaktionen werden für die Kommunikation zwischen verschiedenen Servern und für die dynamische Aktualisierung von Zonendaten benötigt. Die Zugriffssteuerung von Schlüsseln abhängig zu machen, ist wesentlich sicherer, als sich lediglich auf IP-Adressen zu verlassen.

Erstellen Sie mit dem folgenden Befehl einen TSIG-Schlüssel (genauere Informationen finden Sie unter man tsig-keygen):

tux > sudo tsig-keygen -a hmac-md5 host1-host2 > host1-host2.key

Hiermit wird eine Datei mit dem Namen host1-host2.key erstellt, deren Inhalt etwa wie folgt aussieht:

key "host1-host2" {                       |
    algorithm hmac-md5;
    secret "oHpBLgtcZso6wxnRTWdJMA==";
};

Die Datei muss auf den Remote-Host übertragen werden, nach Möglichkeit auf sichere Weise (z. B. mit scp). Damit die sichere Kommunikation zwischen host1 und host2 gewährleistet ist, muss der Schlüssel sowohl auf dem lokalen Server als auch auf dem Remote-Server in die Datei /etc/named.conf aufgenommen werden.

key host1-host2 {
 algorithm hmac-md5;
 secret "ejIkuCyyGJwwuN3xAteKgg==";
};
Warnung
Warnung: Dateiberechtigungen von /etc/named.conf

Vergewissern Sie sich, dass die Berechtigungen von /etc/named.conf ordnungsgemäß eingeschränkt sind. Der Standardwert für diese Datei lautet 0640, mit root als Eigentümer und named als Gruppe. Alternativ können Sie die Schlüssel in eine gesonderte Datei mit speziell eingeschränkten Berechtigungen verschieben, die dann aus /etc/named.conf eingefügt werden. Zum Einschließen einer externen Datei verwenden Sie:

include  "filename"

Ersetzen Sie filename durch einen absoluten Pfad zu Ihrer Datei mit den Schlüsseln.

Damit Server host1 den Schlüssel für host2 verwenden kann (in diesem Beispiel mit der Adresse 10.1.2.3), muss die Datei /etc/named.conf des Servers folgende Regel enthalten:

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

Analoge Einträge müssen in die Konfigurationsdateien von host2 aufgenommen werden.

Fügen Sie TSIG-Schlüssel für alle ACLs (Access Control Lists, Zugriffssteuerungslisten, nicht zu verwechseln mit Dateisystem-ACLs) hinzu, die für IP-Adressen und -Adressbereiche definiert sind, um Transaktionssicherheit zu gewährleisten. Der entsprechende Eintrag könnte wie folgt aussehen:

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

Dieses Thema wird eingehender im Referenzhandbuch für BIND-Administratoren (unter update-policy) erörtert.

31.9 DNS-Sicherheit

DNSSEC, also die DNS-Sicherheit, wird in RFC 2535 beschrieben. Die verfügbaren Werkzeuge für DNSSEC werden im BIND-Handbuch erörtert.

Einer als sicher betrachteten Zone müssen ein oder mehrere Zonenschlüssel zugeordnet sein. Diese werden mit dnssec-keygen erstellt, genau wie die Host-Schlüssel. Zurzeit wird der DSA-Verschlüsselungsalgorithmus zum Erstellen dieser Schlüssel verwendet. Die generierten öffentlichen Schlüssel sollten mithilfe einer $INCLUDE-Regel in die entsprechende Zonendatei aufgenommen werden.

Mit dem Kommando dnssec-signzone können Sie Sets von generierten Schlüsseln (keyset-Dateien) erstellen, sie auf sichere Weise in die übergeordnete Zone übertragen und sie signieren. Auf diese Weise werden die Dateien generiert, die in die einzelnen Zonen in /etc/named.conf aufgenommen werden sollen.

31.10 Weitere Informationen

Weitere Informationen können Sie dem Referenzhandbuch für BIND-Administratoren im Paket bind-doc entnehmen, das unter /usr/share/doc/packages/bind/arm installiert ist. Außerdem könnten Sie die RFCs zurate ziehen, auf die im Handbuch verwiesen wird, sowie die in BIND enthaltenen man-Seiten. /usr/share/doc/packages/bind/README.SUSE enthält aktuelle Informationen zu BIND in SUSE Linux Enterprise Server.