Zum Hauptinhalt springen

5. Master Files (Masterdateien)

Masterdateien (Master Files) sind Textdateien, die RRs in Textform enthalten. Da der Inhalt einer Zone in Form einer Liste von RRs ausgedrückt werden kann, wird eine Masterdatei am häufigsten zur Definition einer Zone verwendet, obwohl sie auch zum Auflisten des Inhalts eines Caches verwendet werden kann.

Dieser Abschnitt erörtertzuerst das Format von RRs in einer Masterdatei und dann die besonderen Überlegungen, wenn eine Masterdatei zur Erstellung einer Zone in einem Nameserver verwendet wird.

5.1. Format​

Das Format von Masterdateien ist eine Sequenz von Einträgen.

Allgemeine Regeln​

Zeilenorientiertes Format :

  • Einträge sind überwiegend zeilenorientiert
  • Klammern können verwendet werden, um eine Liste von Elementen über eine Zeilengrenze hinweg fortzusetzen
  • Textliterale können CRLF im Text enthalten

Trennzeichen :

  • Jede Kombination von Tabs und Leerzeichen fungiert als Trennzeichen zwischen den separaten Elementen

Kommentare :

  • Das Ende jeder Zeile kann mit einem Kommentar enden
  • Kommentare beginnen mit einem ; (Semikolon)
  • Der Rest der Zeile nach ; wird ignoriert

Leerzeilen :

  • Leerzeilen, mit oder ohne Kommentare, sind überall in der Datei erlaubt

Eintragstypen​

Die folgenden Einträge sind definiert:

<blank>[<comment>]

$ORIGIN <domain-name> [<comment>]

$INCLUDE <file-name> [<domain-name>] [<comment>]

<domain-name><rr> [<comment>]

<blank><rr> [<comment>]

Steuerungseinträge​

Zwei Steuerungseinträge sind definiert: $ORIGIN und $INCLUDE.

$ORIGIN :

  • Gefolgt von einem Domainnamen
  • Setzt den aktuellen Ursprung für relative Domainnamen auf den angegebenen Namen zurück
  • Beispiel: $ORIGIN example.com.

$INCLUDE :

  • Fügt die benannte Datei in die aktuelle Datei ein
  • Kann optional einen Domainnamen angeben, der den relativen Domainnamenursprung für die eingeschlossene Datei setzt
  • Kann auch einen Kommentar haben
  • Hinweis: Ein $INCLUDE-Eintrag ändert niemals den relativen Ursprung der übergeordneten Datei, unabhängig von Änderungen am relativen Ursprung innerhalb der eingeschlossenen Datei
  • Beispiel: $INCLUDE /var/named/example.com.hosts

Ressourceneintrag-Einträge​

Die letzten beiden Eintragsformen repräsentieren RRs:

Besitzerregeln :

  • Wenn ein Eintrag für einen RR mit einem Leerzeichen beginnt, wird angenommen, dass der RR dem zuletzt angegebenen Besitzer gehört
  • Wenn ein RR-Eintrag mit einem <domain-name> beginnt, wird der Besitzername zurückgesetzt

RR-Format :

Der Inhalt von <rr> nimmt eine der folgenden Formen an:

[<TTL>] [<class>] <type> <RDATA>

[<class>] [<TTL>] <type> <RDATA>

Feldbeschreibungen :

  • TTL : Optional, Dezimalzahl, die die Lebensdauer in Sekunden darstellt
  • Class : Optional, Standard-Mnemonik (z.B. IN)
  • Type : Erforderlich, Standard-Mnemonik (z.B. A, NS, MX)
  • RDATA : Erforderlich, dem Typ und der Klasse entsprechende Daten

Standardwerte :

  • Weggelassene Klassen- und TTL-Werte werden standardmäßig auf die zuletzt explizit angegebenen Werte gesetzt
  • Da Typ- und Klassenmnemonikel disjunkt sind, ist die Analyse eindeutig

5.2. Domain Names in Master Files (Domainnamen in Masterdateien)​

<domain-name> machen einen großen Anteil der Daten in der Masterdatei aus.

Labeldarstellung​

Grundformat :

  • Labels im Domainnamen werden als Zeichenketten ausgedrückt und durch Punkte getrennt
  • Zitierkonventionen ermöglichen es, beliebige Zeichen in Domainnamen zu speichern

Absolute vs. relative Namen :

  • Absolute Namen (Absolute Names) : Domainnamen, die mit einem Punkt enden, werden als absolut bezeichnet und als vollständig betrachtet

    • Beispiel: www.example.com.

  • Relative Namen (Relative Names) : Domainnamen, die nicht mit einem Punkt enden, werden als relativ bezeichnet

    • Der tatsächliche Domainname ist die Verkettung des relativen Teils mit einem in einem $ORIGIN, $INCLUDE oder als Argument zur Masterdatei-Laderoutine angegebenen Ursprung
    • Ein relativer Name ist ein Fehler, wenn kein Ursprung verfügbar ist
    • Beispiel: www mit Ursprung example.com. wird zu www.example.com.

Zeichenketten​

<character-string> wird auf eine von zwei Arten ausgedrückt:

  1. Ungequotet : Eine zusammenhängende Menge von Zeichen ohne innere Leerzeichen
  2. Gequotet : Eine Zeichenkette, die mit " beginnt und mit " endet
    • Innerhalb einer durch " begrenzten Zeichenkette kann jedes Zeichen auftreten, außer einem " selbst
    • Ein " muss mit \ (Backslash) gequotet werden

5.3. Special Encodings (Spezielle Kodierungen)​

Da Masterdateien Textdateien sind, sind mehrere spezielle Kodierungen erforderlich, um das Laden beliebiger Daten zu ermöglichen.

Spezielle Zeichen und Sequenzen​

. (Punkt) :

  • Ein allein stehender . bezeichnet die Wurzel
  • Beispiel: In example.com. bezeichnet der abschließende . die Wurzel

@ (At-Zeichen) :

  • Ein allein stehendes @ wird verwendet, um den aktuellen Ursprung zu bezeichnen
  • Beispiel: @ IN SOA ... bezieht sich auf den Zonenursprung

\X (Backslash-Escape) :

  • Wo X ein beliebiges Zeichen außer einer Ziffer (0-9) ist
  • Wird verwendet, um dieses Zeichen zu quoten, damit seine spezielle Bedeutung nicht gilt
  • Beispiele:
    • \. kann verwendet werden, um ein Punktzeichen in einem Label zu platzieren
    • \; kann verwendet werden, um ein Semikolon in einer Zeichenkette einzuschließen (nicht als Kommentar)
    • \\ repräsentiert ein Backslash-Zeichen

\DDD (Dezimal-Escape) :

  • Wo jedes D eine Ziffer ist
  • Repräsentiert das Oktett, das der durch DDD beschriebenen Dezimalzahl entspricht
  • Das resultierende Oktett wird als Text angenommen und nicht auf spezielle Bedeutung überprüft
  • Beispiel: \065 repräsentiert das Zeichen 'A' (ASCII 65)

( ) (Klammern) :

  • Klammern werden verwendet, um Daten zu gruppieren, die eine Zeilengrenze überschreiten
  • In der Tat werden Zeilenabschlüsse innerhalb von Klammern nicht erkannt
  • Nützlich für SOA-Einträge und andere mehrzeilige Einträge

; (Semikolon) :

  • Semikolon wird verwendet, um einen Kommentar zu beginnen
  • Der Rest der Zeile wird ignoriert

5.4. Use of Master Files to Define Zones (Verwendung von Masterdateien zur Definition von Zonen)​

Wenn eine Masterdatei zum Laden einer Zone verwendet wird, sollte (SHOULD) der Vorgang unterdrückt werden, wenn Fehler in der Masterdatei auftreten.

Begründung​

Die Begründung dafür ist, dass ein einzelner Fehler weitreichende Konsequenzen haben kann. Zum Beispiel:

  • Angenommen, die RRs, die eine Delegation definieren, haben Syntaxfehler
  • Dann wird der Server autoritative Namensfehler für alle Namen in der Subzone zurückgeben
  • (außer in dem Fall, dass die Subzone auch auf dem Server vorhanden ist)

Gültigkeitsprüfungen​

Mehrere Gültigkeitsprüfungen sollten (SHOULD) zusätzlich zur Sicherstellung durchgeführt werden, dass die Datei syntaktisch korrekt ist:

  1. Klassenkonsistenz : Alle RRs in der Datei sollten (SHOULD) dieselbe Klasse haben

  2. SOA-Anforderung : Genau ein SOA-RR sollte (SHOULD) an der Spitze der Zone vorhanden sein

  3. Glue-Informationen : Wenn Delegationen vorhanden sind und Glue-Informationen erforderlich sind, sollten (SHOULD) sie vorhanden sein

  4. Autoritative Daten : Informationen, die außerhalb der autoritativen Knoten in der Zone vorhanden sind, sollten (SHOULD) Glue-Informationen sein und nicht das Ergebnis eines Ursprungs- oder ähnlichen Fehlers

5.5. Master File Example (Masterdatei-Beispiel)​

Das Folgende ist eine Beispieldatei, die zur Definition der Zone ISI.EDU verwendet werden könnte und mit einem Ursprung von ISI.EDU geladen wird:

@   IN  SOA     VENERA      Action\.domains (
                                 20     ; SERIAL
                                 7200   ; REFRESH
                                 600    ; RETRY
                                 3600000; EXPIRE
                                 60)    ; MINIMUM

        NS      A.ISI.EDU.
        NS      VENERA
        NS      VAXA
        MX      10      VENERA
        MX      20      VAXA

A       A       26.3.0.103

VENERA  A       10.1.0.52
        A       128.9.0.32

VAXA    A       10.2.0.27
        A       128.9.0.33


$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT

Beispielanalyse​

SOA-Eintrag :

  • @ repräsentiert den Zonenursprung (ISI.EDU.)
  • VENERA ist der primäre Nameserver (relativer Name, wird zu VENERA.ISI.EDU.)
  • Action\.domains ist die Mailbox der verantwortlichen Person ([email protected])
    • Beachten Sie die Verwendung von \, um den Punkt in der E-Mail-Adresse zu escapen
  • Seriennummer: 20
  • Refresh: 7200 Sekunden (2 Stunden)
  • Retry: 600 Sekunden (10 Minuten)
  • Expire: 3600000 Sekunden (ca. 41,67 Tage)
  • Minimum: 60 Sekunden

NS-Einträge :

  • Drei Nameserver: A.ISI.EDU. (absolut), VENERA (relativ), VAXA (relativ)

MX-Einträge :

  • Primärer Mail-Austauscher: VENERA mit Präferenz 10
  • Sekundärer Mail-Austauscher: VAXA mit Präferenz 20

A-Einträge :

  • A.ISI.EDU. hat eine IPv4-Adresse
  • VENERA.ISI.EDU. hat zwei IPv4-Adressen (Multihoming)
  • VAXA.ISI.EDU. hat zwei IPv4-Adressen (Multihoming)

$INCLUDE-Direktive :

  • Schließt eine externe Datei mit Mailbox-Einträgen ein

5.6. Common Master File Patterns (Gängige Masterdatei-Muster)​

Muster 1: Einfache Zonendatei​

$ORIGIN example.com.
$TTL 86400

@   IN  SOA ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Minimum

    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.

ns1 IN  A   192.0.2.1
ns2 IN  A   192.0.2.2
www IN  A   192.0.2.10

5.7. Best Practices (Best Practices)​

  1. Immer absolute Namen für externe Referenzen verwenden : Namen außerhalb Ihrer Zone sollten mit einem Punkt enden

  2. $ORIGIN vorsichtig verwenden : Am Anfang festlegen und unnötige Änderungen vermeiden

  3. Seriennummern einbeziehen : Bei Änderungen immer die Seriennummer erhöhen

  4. Kommentare verwenden : Zonendatei mit Kommentaren dokumentieren

  5. Vor dem Deployment testen : Tools wie named-checkzone zur Syntaxvalidierung verwenden

  6. Konsistenz beibehalten : Konsistente Formatierung für Lesbarkeit beibehalten

  7. Backup : Immer Backups funktionierender Zonendateien vor Änderungen aufbewahren

Weiter : 6. Name Server Implementation (Nameserver-Implementierung)

Letztes Update am