31 Domain Name System (DNS) #

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

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.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. Weitere Informationen hierzu finden Sie unter Figure 31.4, “DNS-Server: Protokollieren”.

Figure 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 Section 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 Figure 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.

Figure 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. Weitere Informationen hierzu finden Sie unter Figure 31.6, “DNS-Server: Zonen-Editor (DNS-Einträge)”.

Figure 31.6: DNS-Server: Zonen-Editor (DNS-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. Weitere Informationen hierzu finden Sie unter Figure 31.7, “DNS-Server: Zonen-Editor (MX-Einträge)”.

Figure 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 Example 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.

Figure 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.

   

   Figure 31.9: Hinzufügen eines Eintrags für eine Masterzone #

    

4. Fügen Sie im Fenster DNS-Zonen eine Reverse-Masterzone hinzu.

   

   Figure 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.

   

   Figure 31.11: Hinzufügen eines Reverse-Eintrags #

    

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

Tip: 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.

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.

Tip: Automatische Anpassung der Namenserverinformationen

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 Example 31.1, “Weiterleitungsoptionen in named.conf” handelt es sich lediglich um Beispiele. Passen Sie diese Einträge an Ihr eigenes Setup an.

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 “.” sollte immer 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.

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 Example 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";
};

logging {
        category default { null; };
};

zone "example.com" in {
      type master;
      file "example.com.zone";
      notify no;
};

zone "example.net" in {
      type slave;
      file "slave/example.net.zone";
      masters { 10.0.0.1; }; 
};

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

Tip: 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 platzierter „.“ ist wahrscheinlich die häufigste Ursache von Fehlern bei der Namenserverkonfiguration.

Der erste zu betrachtende Fall ist die Zonendatei example.com.zone, die für die Domäne example.com zuständig ist (siehe Example 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 anderenfalls 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 E-Mail-Adresse der für diesen Namenserver zuständigen Person. Da das Zeichen @ bereits eine besondere Bedeutung hat, wird hier stattdessen „.“ 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 E-Mails 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. Note: 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 Example 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.

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

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 individuell für jeden Zoneneintrag durch Hinzufügen einer optionalen allow-update- bzw. update-policy-Regel konfiguriert. 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 Section 31.8, “Sichere Transaktionen” beschrieben.

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 mandnssec-keygen):

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

Dadurch werden zwei Schlüssel mit ungefähr folgenden Namen erstellt:

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

Der Schlüssel selbst (eine Zeichenkette, wie beispielsweise ejIkuCyyGJwwuN3xAteKgg==) ist in beiden Dateien enthalten. Um ihn für Transaktionen zu verwenden, muss die zweite Datei (Khost1-host2.+157+34265.key) auf den entfernten Host übertragen werden, möglichst auf eine sichere Weise (z. B. über SCP). Auf dem entfernten Server muss der Schlüssel in der Datei /etc/named.conf enthalten sein, damit eine sichere Kommunikation zwischen host1 und host2 möglich ist:

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

Warning: 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.

DNSSEC (DNS-Sicherheit) wird in RFC 2535 beschrieben. Die für DNSSEC verfügbaren Werkzeuge 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.

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.