Bewertung 3


Die Kandidaten sollten in der Lage sein, ein Zonen-File für eine „forward“ oder „reverse“ Zone bzw. einen Root-Level-Server anzulegen. Dieses Lernziel beinhaltet das Setzen passender Werte für den SOA Datensatz, NS Datensätze und MX Datensätze. Ebenfalls enthalten ist das Hinzufügen von Hosts mit A und CNAME Datensätzen je nach Anforderung, das Hinzufügen von Hosts zu „reverse“ Zonen mit PTR Datensätzen und das Hinzufügen der Zone in der /etc/named.conf Datei unter Verwendung des zone Statements mit passenden Typen-, Datei- und Master-Werten.

Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:

  • Inhalt von /var/named
  • Zonen-File Syntax
  • Datensatzformate
  • dig
  • nslookup
  • host

Wenn ein Nameserver nicht nur caching only server sein soll, sondern tatsächlich Informationen über eine (oder mehrere) Zonen anbieten soll, dann benötigen wir natürlich etwas mehr Konfigurationsarbeit, als bisher. Zumindestens benötigt jede Zone eine Datei, in der die Namen in IP-Adressen aufgelöst werden (forward-Datei) und eine, die umgekehrt die IP-Adressen in Namen auflöst (reverse-Datei).

Dazu muss in der zentralen Konfigurationsdatei /etc/named.conf ein entsprechender Eintrag zu diesen Dateien vorhanden sein.

Neben den Einträgen für den Root-Server haben wir also je einen Eintrag für die Zone und die reverse-Zone. Dabei gilt zu entscheiden, ob der Server der Master- oder der Slave-Server sein soll. Der Master-Server gibt alle seine Einträge an alle Slave-Server mittels Zone-Transfer weiter. Hier ist einmal ein Beispiel für einen Eintrag eines Master-Servers für eine Zone beispiel.xyz, die die IP-Adresse 199.45.67.0 hat:

  options {
    directory "/var/named";
  };

  zone "beispiel.xyz" IN {
    type master;                   # Es ist ein Master-Server
    file "beispiel.xyz.zone";      # Die Zonendatei
  };
                
  zone "67.45.199.in-addr.arpa" IN {
    type master;
    file "67.45.199.in-addr.arpa.zone";
  };

Die Angaben sprechen für sich. Es handelt sich also um den Master-Server für die angegebenen Zonen (type master) und es wird in beiden Fällen eine Datei angegeben, in der die eigentlichen Zoneninformationen zu finden sind. Der Dateiname wird relativ zu dem Verzeichnis verstanden, das bei den Optionen unter directory angegeben wurde, in unserem Beispiel also /var/named.

Die Zonendateien

Der nächste Schritt wäre jetzt also, die entsprechenden Zonendateien (in unserem Beispiel also /var/named/beispiel.xyz und /var/named/67.45.199.in-addr.arpa.zone anzulegen. Die beiden Namen sind übrigens frei vergebbar, entscheidend ist nur, dass die Dateien eben so heissen, wie in /etc/named.conf angegeben.

Jede Zonendatei ist eine Datenbank mit Datensätzen, die die folgenden Elemente beinhalten: Domain-name Der Name der Domain, auf den sich der Datensatz bezieht. Time-to-live Dieser Wert ist optional und bezeichnet die Stabilität eines Eintrags, also die Frage, wie lange er gültig sein soll. Wird häufig weggelassen. Class Die Informationsklasse. Für Internet Informationen steht hier immer der Begriff IN. Type Gibt an, um was für einen Typ Datensatz es sich handelt. Eine genaue Beschreibung der möglichen Typen finden Sie weiter unten. Value Der eigentliche Wert des Datensatzes. Abhängig vom genannten Typ.

Die Datenbank besteht also aus Einträgen, die sich alle an dieses Format halten. Für den Typ der Information (Type) stehen folgende Werte zur Verfügung:

TypBedeutungEintrag
SOAStart Of AuthorityVerschiedene Parameter für die Zone, die der Nameserver verwalten soll.
AAddressDie Adresse eines Internet Hosts.
MXMail ExchangeDie Priorität und Name des Mailservers der Domain.
NSName ServerName eines Nameservers der Domain.
CNAMECanonical NameDomainname eines Rechners (Aliasfunktion)
PTRPointerAlias für eine numerische IP-Adresse
HINFOHost InformationASCII Beschreibung des Hosts (CPU, OS, …)
TXTTextNicht verwertbarer Text – Kommentar

Der SOA Datensatz

Der erste Datensatz einer Zonendatei ist der sogenannte SOA-Datensatz, also der Start Of Authority-Satz, der markiert, dass hier der Abschnitt beginnt, für den der Nameserver zuständig ist. Dieser Datensatz enthält ein paar sehr kryptische Angaben, die aber eigentlich nicht weiter schwer zu verstehen sind. Ein typischer Eintrag für einen SOA-Datensatz wäre:

  beispiel.xyz. IN SOA  einstein   root.einstein.beispiel.xyz. (
                        20030227001     ; serial
                        1d              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

Der erste Eintrag (beispiel.xyz.) bezeichnet die Domain, um die sich dieser Eintrag dreht. Der abschließende Punkt heisst, dass diese Domain vollständig ist und es nicht notwendig ist, den Domainnamen hinten anzuhängen.

Der zweite Eintrag ist die Klasse, in unserem Fall also IN für eine Internet-Adresse.

Der dritte Eintrag ist der Typ des Eintrags, in unserem Fall also SOA.

Ein SOA-Eintrag besteht aus mehreren Einträgen, die jetzt hier folgen. Der erste ist der Name des Nameservers selbst, in unserem Beispiel habe ich ihn einfach einstein genannt. Der Angabe des Namens folgt kein Punkt, das bedeutet eben, dass hier der Domainnamen noch angehängt werden muss. Aus einstein wird also einstein.beispiel.xyz.

Der nächste Eintrag im SOA-Datensatz ist die E-Mail-Adresse des Systemverwalters. Statt einem Klammeraffen wird hier allerdings auch ein Punkt angegeben. In unserem Beispiel steht hier die ganze Adresse, also folgt wieder ein Punkt. Stattdessen hätten wir auch wieder root.einstein schreiben können. Weil da wieder kein Punkt folgt, würde der Domainnamen wieder hinten angehängt.

Jetzt folgt in Klammern eine Folge von Angaben, die sich auf die Gültigkeit des Datensatzes beziehen. Die erste ist eine Seriennummer, die sich gewöhnlich aus dem Datum der letzten manuellen Änderung der Datei und einer Ganzzahl zusammensetzt. In unserem Beispiel steht hier 20030227001. Das wird von Nameserver als 2003.01.27.001 interpretiert, also der erste Eintrag vom 27.Februar 2003. Dieser Wert wird immer dann benutzt, wenn ein Slave-Server entscheiden muss, ob sein Eintrag noch aktuell ist, oder er einen Zonentransfer durchführen muss. Bei einer manuellen Änderung der Datei sollte diese Zahl also entsprechend angepasst werden, sonst wird der Slave-Server keine Auffrischung seiner Daten vornehmen.

Die weiteren Einträge haben die folgenden Bedeutungen 1d Dieses Feld legt das Intervall fest, das ein Slave-Server wartet, bis er den SOA Eintrag des Master-Servers erneut liesst um zu überprüfen, ob sich darin Neuerungen finden. Die Angabe erfolgt in Sekunden, oder der leichteren Lesbarkeit halber in Stunden, Tagen, Wochen oder Monaten. In diesem Fall muss ein entsprechendes Postfix (H,D,W oder M) angegeben werden. 2H Nach 2 Stunden erfolgt ein erneuter Versuch, wenn ein Versuch des Zonentransfers fehlgeschlagen ist. 1W Nach einer Woche ohne Kontakt zum Master soll der Slave seine Informationen als ungültig erklären und keine Informationen mehr an Nachfragen weitergeben. 2D Dieses Feld gibt den voreingestellten Wert für die Gültigkeit einer Information an, wenn in einem Datensatz weiter unten diese Angabe fehlt.

NS und MX Datensätze

Nach dem SOA-Datensatz folgen in der Regel die Datensätze, die festlegen, wer für diese Zone der Nameserver ist bzw. die Nameserver sind. Diese Nameserverdatensätze bestehen aus der Klasse IN, dem Typ NS und der Angabe des Namens des entsprechenden Servers. Auch hier gilt, wenn dem Namen kein Punkt folgt, wird der Domainname noch angehängt, ansonsten wird er als vollständig interpretiert.

      IN NS  einstein
      IN NS  heisenberg
      IN NS  bohr.beispiel.xyz.

Da diesen Einträgen keine Domain vorangestellt wurde, beziehen sie sich auf die im SOA-Feld genannte. Soll aber beispielsweise eine Subdomain sub.beispiel.xyz einen eigenen Nameserver bekommen, dann ändert sich dieser Eintrag dahingehend, dass vorne der Name der Subdomain steht:

                       IN NS einstein
                       IN NS heisenberg
  sub.beispiel.xyz.    IN NS nameserver.sub.beispiel.xyz.      

Wenn die verwaltete Domain einen oder mehrere Mailserver bereitstellt, dann wird auch dieser Mailserver hier angegeben. Dazu wird der Typ auf MX (Mail Exchange) gesetzt. Dem MX folgt die Angabe einer Zahl, die festlegt, in welcher Reihenfolge mehrere Mailserver benutzt werden sollen. Die niedrigste Zahl wird zuerst versucht, die höchste zuletzt und nur dann, wenn die Mailserver mit niedrigeren Zahlen nicht verfügbar sind.

      IN MX 10 mail
      IN MX 20 bohr.beispiel.xyz.

Auch hier können Mailserver für Subdomains angegeben werden, indem der Name der Subdomain vorangestellt wird.

  sub.beispiel.xyz.    IN MX 10 mail.sub.beispiel.xyz. 

Die Regel mit dem Punkt nach dem Namen ist auch hier wieder die selbe wie oben. Der Beispieleintrag bedeutet, dass zuerst versucht wird, den Rechner mail.beispiel.xyz anzusprechen, wenn das fehlschlägt, so wird der Rechner bohr.beispiel.xyz versucht.

NS und MX Einträge finden sich in der Regel nur in den forward-Zonendateien.

Die Einträge für IP-Adressen in der forward-Datei

Der eigentliche Job des Nameservers besteht ja darin, IP-Adressen und Namen zu verbinden. In der forward-Datei stehen nun zwei mögliche Angaben über diese Namen. Der erste denkbare Eintrag ist der, der die Namen mit IP-Adressen verbindet. Er trägt den Typ A

  einstein       IN  A 199.45.67.1
  heisenberg     IN  A 199.45.67.2
  bohr           IN  A 199.45.67.3

Auch hier wäre es wieder möglich gewesen, die Namen mit vollständigem Domainnamen und folgendem Punkt anzugeben.

Die zweite Form des Eintrags ist die eines Alias-Namens (Canonical Name), die mit dem Typ CNAME erreicht wird:

  mail           IN CNAME einstein
  www            IN CNAME heisenberg.beispiel.xyz.

Hiermit wird festgelegt, dass der Rechner mail.beispiel.xyz eben in Wahrheit einstein.beispiel.xyz ist und der Rechner www.beispiel.xyz nur ein anderer Name für heisenberg.beispiel.xyz ist.

Die Einträge für die reverse-Datei

Die Aufgabe der reverse-Datei ist es, IP-Adressen mit Namen zu verbinden. Also eben genau die umgekehrte (reverse) Aufgabe, die ein Nameserver eigentlich hat.

Unsere reverse-Datei benötigt exakt den selben Eintrag für den SOA-Datensatz wie die forward-Datei. Statt des Domainnamens steht hier nur die Angabe der Adresse der Zone in umgekehrter Reihenfolge. Für die Zone, die die Adresse 199.45.67.0 verwaltet stünde hier also

67.45.199.in-addr.arpa.     ...

Die letzte Zahl der Adresse (bzw. der lokale Teil der Adresse) ist weggelassen.

Statt A oder CNAME Einträgen enthält die Datei jetzt aber sogenannte PTR-Einträge, die sozusagen Pointer von der Adresse auf den Namen sind.

  1          IN  PTR  einstein
  2          IN  PTR  heisenberg
  3          IN  PTR  bohr.beispiel.xyz.  

Die fehlenden Teile der IP-Adresse werden dem SOA-Datensatz entnommen.

Die Programme dig, nslookup und host

Alle drei genannten Programme dienen dazu, Nameserver-Abfragen vorzunehmen.

Schreibe einen Kommentar