Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Rerenzhandbuch- Zone-Dateien

12.3. 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 z.B. 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.

12.3.1. 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 z.B. die, die ausschlie�lich den Host festlegen.

    Eine Zone-Datei k�nnte z.B. 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.

    AnmerkungAnmerkung
     

    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.

12.3.2. 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.5

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

    <alias-name>     IN     CNAME       <real-name>

    Betrachten Sie das folgende Beispiel. In dieser Einrichtung bindet der A-Record einen Hostnamen an eine IP-Adresse, w�hrend ein CNAME-Record den allgemein verwendeten Hostnamen www zuweist.

    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 z.B. 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.

    SekundenAndere Zeiteinheiten
    601M
    180030M
    36001H
    108003H
    216006H
    4320012H
    864001D
    2592003D
    6048001W
    31536000365D

    Tabelle 12-1. 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

12.3.3. 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
                    86400 )    ; 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.

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

 
 
  Published under the terms of the GNU General Public License Design by Interspire