Zum Inhalt springen

Berkeley Internet Name Domain/Zone-Dateien

Aus Foxwiki
Version vom 20. August 2025, 08:00 Uhr von Dirkwagner (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Zone-Dateien == ''Zone-Dateien'' sind im <tt>named</tt>-Arbeitsverzeichnis, <tt>/var/named/</tt>, gespeichert und enthalten Informationen über einen bestimmten Namespace. * Jede Zone-Datei ist gemäß der Daten der <tt>file</tt>-Option in der <tt>zone</tt>-Direktive benannt. * Normalerweise bezieht sich der Name auf die entsprechende Domain und identifiziert die Datei als Datei, die Zone-Daten enthält, wie beispielsweise <tt>example.com.zone</tt>.…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Zone-Dateien

Zone-Dateien sind im named-Arbeitsverzeichnis, /var/named/, gespeichert und enthalten Informationen über einen bestimmten Namespace.

  • Jede Zone-Datei ist gemäß der Daten der file-Option in der zone-Direktive benannt.
  • Normalerweise bezieht sich der Name auf die entsprechende Domain und identifiziert die Datei als Datei, die Zone-Daten enthält, wie beispielsweise example.com.zone.

Jede Zone-Datei kann Direktiven und Resource-Records enthalten. Direktiven weisen den Name-Server an, bestimmte Aktionen auszuführen oder spezielle Einstellungen für die Zone zu verwenden. Resource-Records legen die Parameter der Zone fest.

  • Diese ordnen bestimmten Systemen innerhalb des Namespaces der Zone eine Identität zu.
  • Anweisungen sind optional, aber Resource-Records sind notwendig, um dieser Zone den Name-Service zur Verfügung zu stellen.

Alle Anweisungen und Resource-Records sollten in einer eigenen Zeile stehen.

Kommentare können in Zone-Dateien nach dem Semikolon (;) platziert werden.

Zone-Dateien-Direktiven

Anweisungen werden durch das vorangestellte Dollarzeichen $ identifiziert, das vor dem Namen der Anweisung üblicherweise im oberen Teil der Zone-Datei steht.

Folgende Anweisungen werden am häufigsten verwendet:

  • $INCLUDE — Weist named an, in diese Zone-Datei an Stelle der Anweisung eine andere Zone-Datei einzufügen.
  • Dadurch können zusätzliche Einstellungen der Zone getrennt von der Haupt-Zone-Datei gespeichert werden.
  • $ORIGIN — Stellt den Domain-Name so ein, dass er an alle ungeeigneten Records angefügt wird.
  • Wie beispielsweise die, die ausschließlich den Host festlegen.

Eine Zone-Datei könnte beispielsweise folgende Zeile enthalten:

$ORIGIN example.com.An alle Namen, die in Resource-Records verwendet werden und nicht mit einem Punkt (.) enden, wird example.com angehängt.
Anmerkung
Die Verwendung der $ORIGIN-Direktive ist nicht erforderlich, wenn der Name der Zone in /etc/named.conf mit dem Wert übereinstimmt, den Sie $ORIGIN zuweisen würden.
  • Standardmäßig wird der Name der Zone als Wert der $ORIGIN-Anweisung verwendet.
  • $TTL — Legt den Standard-Time to Live (TTL)-Wert für die Zone fest.
  • Dieser Wert legt für die Name-Server in Sekunden fest, wie lange das Resource-Record für die Zone gültig ist.
  • Ein Resource- Record kann einen eigenen TTL-Wert besitzen, der den Wert dieser Anweisung für die Zone überschreibt.

Wird dieser Wert erhöht, können die Remote-Name-Server die Zone-Informationen länger verarbeiten.

  • Dadurch werden zwar die Abfragen für diese Zone reduziert, es vergrößert sich jedoch der Zeitraum, bis man von den Änderungen der Resource-Records profitieren kann.

Resource-Records der Zone-Datei

Die Hauptkomponente einer Zone-Datei sind deren Resource-Records.

Es gibt viele Typen von Resource-Records.

  • Folgende werden am häufigsten verwendet:
  • A — Adressen-Record, das einem Namen eine IP-Adresse zuweist.
  • Beispiel:
<host>     IN     A     <IP-address>Wenn der <host>-Wert nicht angegeben wird, verweist ein A-Record auf eine standardmäßige IP-Adresse für den oberen Teil des Namespaces. 
  • Dieses System gilt für alle nicht-FQDN-Anfragen.

Beachten Sie das folgende A-Record-Beispiel für die example.com Zone-Datei:

             IN     A       10.0.1.3
server1      IN     A       10.0.1.5Anfragen für example.com richten sich an 10.0.1.3, während Anfragen für server1.example.com sich an 10.0.1.5 richten. * CNAME — Name-Record, welcher Namen untereinander zuordnet. 
  • Dieser Typ ist auch als Alias bekannt.

Im nächsten Beispiel wird named angewiesen, dass alle Anfragen, die an den <alias-name> gesendet werden, auf den Host <real-name> zeigen. CNAME-Records werden am häufigsten verwendet, um auf Dienste zu verweisen, die ein allgemeines Namensschema für den korrekten Host, wie www für Web-Server, verwenden.

  • server1 IN A 10.0.1.5
www          IN     CNAME   server1* MX — Mail eXchange- Record, das angibt, welchen Weg eine Mail nimmt, die an ein bestimmtes Namespace gesendet und von dieser Zone kontrolliert wurde.
      IN     MX     <preference-value>  <email-server-name>In diesem Beispiel ermöglicht <preference-value>, die E-Mail-Server der Reihenfolge nach zu nummerieren, auf denen Sie für dieses Namespace bestimmte E-Mails empfangen möchten, indem Sie einigen E-Mail-Systemen den Vorrang vor anderen geben. 
  • Der MX-Resource-Record mit dem niedrigsten <preference-value> wird den anderen vorgezogen.
  • Sie können mehreren E-Mail-Servern denselben Wert zuweisen, um den E-Mail-Verkehr zwischen den Servern zu verteilen.

Der <email-server-name> kann ein Hostname oder ein FQDN sein. IN MX 10 mail.example.com.

      IN     MX     20     mail2.example.com.In diesem Beispiel wird der erste mail.example.com-E-Mail-Server vor dem mail2.example.com-E-Mail-Server bevorzugt, wenn eine E-Mail für die Domain example.com ankommt. * NS — Name-Server-Record, der die maßgeblichen Name-Server für eine bestimmte Zone anzeigt.

Beispiel für einen NS-Record:

      IN     NS     <nameserver-name>Der <nameserver-name> sollte ein FQDN sein.

Anschließend werden zwei Nameserver als maßgeblich für die Domain aufgelistet.

  • Es ist nicht so wichtig, ob diese Namenserver Slave- oder Master-Nameserver sind, da beide bereits maßgebend sind. IN NS dns1.example.com.
      IN     NS     dns2.example.com.* PTR — PoinTeR-Record verweist auf einen anderen Teil des Namespace.

PTR-Records werden primär für eine umgekehrte Namensauflösung verwendet, da diese IP-Adressen zu einem bestimmten Namen verweisen.

  • Unter Abschnitt 12.3.4 finden Sie weitere Beispiele von PTR-Records in Verwendung. * SOA — Start Of Authority-Record, gibt wichtige maßgebliche Informationen über den Namespace an den Name-Server.

Nach den Direktiven festgelegt ist ein SOA-Resource-Record, der erste Resource-Record in einer Zone-Datei.

Das folgende Beispiel zeigt die Basisstruktur eines SOA-Resource-Record:

@     IN     SOA    <primary-name-server>     <hostmaster-email> (
                    <serial-number>
                    <time-to-refresh>
                    <time-to-retry>
                    <time-to-expire>
                    <minimum-TTL> )

Das @-Symbol richtet die $ORIGIN-Anweisung (oder den Namen der Zone, falls die $ORIGIN-Direktive nicht eingestellt ist) als Namespace ein, das von diesem SOA-Resource-Record eingestellt wurde.

  • Als <primary-Nameserver> wird der erste, für diese Domain maßgebliche Name-Server verwendet und die E-Mail der über diesen Namespace zu kontaktierenden Person wird durch die <hostmaster-email> ersetzt.

Die <serial-number> wird bei jeder Änderung der Zone-Datei erhöht, so dass named erkennt, dass diese Zone neu geladen werden kann.

  • Die <time-to-refresh> teilt den Slave-Servern mit, wie lange sie warten müssen, bevor sie beim Master-Nameserver anfragen, ob alle Änderungen für die Zone durchgeführt wurden.
  • Der Wert der <serial-number> wird vom Slave-Server verwendet, um festzustellen, ob veraltete Daten der Zone verwendet werden, die aktualisiert werden sollten.

Die <time-to-retry> gibt den Zeitraum an, nach dem eine neue Anfrage bezüglich der Aktualisierung durchgeführt werden soll, wenn der Master-Nameserver auf die letzte Anfrage nicht reagiert hat.

  • Wenn der Master-Nameserver nicht geantwortet hat, bevor die <time-to-expire> abläuft, reagiert der Slave-Nameserver nicht mehr auf Anfragen bezüglich des Namespaces.

<minimum-TTL> ist die Zeit, die anderen Nameservern zum Verarbeiten der Zonen-Informationen mindestens zur Verfügung steht.

In BIND werden alle Zeiten in Sekunden angegeben.

  • Sie können jedoch auch Abkürzungen für andere Zeiteinheiten verwenden, wie beispielsweise
  • Minuten (M), Stunden (H), Tage (D) und Wochen (W).
  • In der Tabelle unter Tabelle 12-1 finden Sie Zeiträume in Sekunden und die entsprechende Zeit in anderen Formaten.
Sekunden Andere Zeiteinheiten
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D
Sekunden im Vergleich zu anderen Zeiteinheiten

Das folgende Beispiel zeigt Ihnen, wie ein SOA-Resource-Record aussehen könnte, wenn es mit echten Werten konfiguriert ist.

@     IN     SOA    dns1.example.com.     hostmaster.example.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

Beispiele für Zone-Dateien

Einzeln betrachtet könnten die Anweisungen und Resource-Records schwer zu verstehen sein.

  • Sind beide in einer gemeinsamen Datei plaziert, wird es einfacher.

Im nächsten Beispiel ist eine sehr einfache Zone-Datei abgebildet.

$ORIGIN example.com.
$TTL 86400
@     IN     SOA    dns1.example.com.     hostmaster.example.com. (
 2001062501 ; serial
 21600      ; refresh after 6 hours
 3600       ; retry after 1 hour
 604800     ; expire after 1 week
 86 400 )    ; minimum TTL of 1 day

 IN     NS     dns1.example.com.
 IN     NS     dns2.example.com.

 IN     MX     10     mail.example.com.
 IN     MX     20     mail2.example.com.

             IN     A       10.0.1.5

server1      IN     A       10.0.1.5
server2      IN     A       10.0.1.7
dns1         IN     A       10.0.1.2
dns2         IN     A       10.0.1.3

ftp          IN     CNAME   server1
mail         IN     CNAME   server1
mail2        IN     CNAME   server2
www          IN     CNAME   server2
In diesem Beispiel werden Standard-Anweisungen und SOA-Werte verwendet
  • Die maßgeblichen Name-Server sind dabei als dns1.example.com und dns2.example.com eingestellt, die über A-Records verfügen, wodurch sie mit 10.0.1.2 bzw. 10.0.1.3 verbunden sind.
  • Die mit MX-Records konfigurierten E-Mail-Server verweisen auf server1 und server2 über CNAME- Records.
  • Da die server1- und server2-Namen nicht mit einem Punkt enden (.), wird die $ORIGIN-Domain nach ihnen abgelegt, wobei sie zu server1.domain.com und server2.domain.com erweitert werden.
  • Mit den dazugehörigen A-Resource-Records können dann ihre IP-Adressen bestimmt werden.
  • Die beliebten FTP- und Web-Dienste, die unter den standardmäßigen Namen ftp.domain.com und www.domain.com zur Verfügung stehen, verweisen auf Rechner, die entsprechende Dienste für die Namen bieten, die CNAME-Records verwenden.

Zone-Dateien für die umgekehrte Auflösung von Namen

Eine Zone-Datei für die Auflösung von Reverse-Namen wird verwendet, um eine IP-Adresse in ein bestimmtes Namespace in einem FQDN umzusetzen.

  • Sie ähnelt einer standardmäßigen Zone-Datei, mit dem Unterschied, dass die PTR-Resource-Records zur Verknüpfung der IP-Adressen mit gültigen Domain-Namen verwendet werden.

Ein PTR-Record sieht Folgendem ähnlich:

<last-IP-digit>      IN     PTR    <FQDN-of-system>

Die <last-IP-digit>ist die letzte Nummer in einer IP-Adresse, mit der auf die FQDN eines bestimmtenSystems hingewiesen wird.

Im folgenden Beispiel werden die IP-Adressen 10.0.1.20 durch 10.0.1.25 den korrespondierenden FQDN zugewiesen.

$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@     IN     SOA    dns1.example.com.     hostmaster.example.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.example.com.
      IN     NS     dns2.example.com.

20    IN     PTR    alice.example.com.
21    IN     PTR    betty.example.com.
22    IN     PTR    charlie.example.com.
23    IN     PTR    doug.example.com.
24    IN     PTR    ernest.example.com.
25    IN     PTR    fanny.example.com.

Diese Zone-Datei würde mit einer zone-Anweisung in der named.conf-Datei in den Dienst übernommen, was dann so ähnlich aussieht wie:

zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};

Es gibt nur einen kleinen Unterschied zwischen diesem Beispiel und einer standardmäßigen zone-Direktive:

  • der Name wird anders angegeben.
  • Bitte beachten Sie, dass bei einer Zone für eine umgekehrte Auflösung die ersten drei Blöcke der IP-Adresse zum Umkehren benötigt werden und .in-addr.arpa danach angegeben ist.
  • Dadurch kann ein einzelner Block von IP-Ziffern, der in der Zone-Datei zum umgekehrten Auflösen von Namen verwendet wird, richtig an diese Zone angefügt werden.