Printer Friendly Version
Credits
Marc Haber
24.09.2002 14:41
Damit eine Zone funktioniert, müssen bestimmte Einträge vorhanden sein. Die Zusammenhänge sind komplex, die Fehlerquellen reichhaltig. Deswegen versuche ich hier, eine einfache Erklärung für die wichtigsten Typen von Resource Records zu liefern.
Aus SOA-Records kann man die technischen Zuständigkeiten für die Zone ablesen. Ausserdem enthalten SOA-Records einige Steuerdaten für die Zusammenarbeit der zahlreichen Nameserver untereinander. SOA-Records sind weiter unten in diesem Artikel im Detail erklärt.
NS-Records verweisen auf die Nameserver, die für eine Zone authoritativ sind. Auf den "eigenen" Namen zeigende NS-Records dienen der Plausibilitätsprüfung; NS-Records für eine Subdomain weisen darauf hin, dass die Informationen für die Subdomain auf einem anderen Nameserver zu finden sind. Dies wird als Delegation bezeichnet.
A-Records verknüpfen einen Domainnamen mit einer IP-Adresse.
PTR-Records verknüpfen eine IP-Adresse "rückwärts" mit einem Domainnamen.
CNAME-Records definieren einen Domainnamen als "Alias" für einen anderen.
MX-Records definieren, bei welchen Rechnern Mail für eine Domain eingeliefert werden soll.
TXT-Records hinterlegen beliebige alphanumerische Informationen zu einem Domainnamen.
Jede Zone muss einen SOA-Record (Start of Authority) enthalten. Dort sind wichtige Informationen über die Zone abgelegt. Hier ein Beispiel:
$TTL 24h ; primary.master.server mailbox.of.responsible.person @ IN SOA ns1.example.com. hostmaster.example.com. ( 2002091801 ; serial 8h ; refresh 2h ; retry 7d ; expire 24h ) ; minimum
Das Semikolon leitet Kommentare ein, die natürlich nicht vorhanden sein müssen.
das erste Feld im SOA-Record benennt den primary master server. Dies ist der Server, der die endgültige Autorität über den Inhalt der Zone ist. Dort ist das Zonefile selbst abgelegt.
Bei hidden-master-Konfigurationen muss hier der "versteckte" Master eingetragen sein.
das zweite Feld des SOA-Records nennt die Mailbox der für die Zone verantwortlichen Person. Das @-Zeichen wird durch einen Punkt ersetzt. Links vom @ stehende Punkte müssen als \. notiert werden, um eine eindeutige Zuordnung für das @-Zeichen zu erreichen.
Es ist zu empfehlen, hier den durch RFC2142 vorgeschlagenen Namen hostmaster für die im SOA-Record genannte Mailadresse zu nehmen, die aber nicht notwendigerweise in derselben Domain liegen muss wie der Nameserver.
Die im SOA-Record genannte Adresse werden viele Internet-Teilnehmer nutzen, um auf Fehler in der DNS-Konfiguration hinzuweisen.
Die serial number spielt eine wichtige Rolle im Zusammenspiel zwischen Master und Slave: Slaves führen nur dann einen Zonentransfer durch, wenn die vom Master übermittelte serial größer ist als die der lokal gehaltenen Zone.
Ein sehr beliebter Fehler ist zu vergessen, die serial number zu erhöhen, nachdem man an der Zone Änderungen durchgeführt hat. Wir empfehlen, die serial nach dem Schema yyyymmddnn zu bilden: yyyy ist das vierstellige Jahr, mm der zweistellige Monat, dd der zweistellige Tag und nn die Nummer der Änderung des aktuellen Tags.
Ist die serial zu weit erhöht worden, zeigt RFC1912 einen Weg auf, um die serial verringern zu können.
Der refresh-Wert legt fest, wie häufig ein Slave beim Master nachfragt, ob sich die serial für die Zone verändert hat.
Der retry-Wert legt fest, wie häufig ein Slave den Zonentransfer wiederholt, wenn er einmal fehlgeschlagen ist.
Der expire-Wert legt fest, wie lange ein Slave seine Kopie einer Zone noch als gültig ansieht, wenn er den Master nicht erreichen kann.
Der minimum-Wert legt fest, wie lange eine negative Antwort vom Client zwischengespeichert werden darf. Er ist einer der beiden wichtigsten Timer in einem Zonefile, und ist deswegen weiter unten genauer beschrieben. Für die Bedeutung dieses Eintrags ist RFC2308 relevant.
Als letztes verbleibt noch der Eintrag in der $TTL-Zeile oberhalb des SOA-Records. Hiermit wird festgelegt, welche Lebensdauer die Resource Records des Zonefiles in den Caches nicht authoritativer Nameserver haben sollen. Auch dieser Timer ist lebenswichtig und ist deswegen unten genauer beschrieben. Auch hier ist wieder RFC2308 relevant.
Es wird empfohlen, den SOA-Record wie oben gezeigt zu formatieren. Die Formatierung ist jedoch für die Funktion des Nameservers irrelevant.
TTL ist die Abkürzung für Time to Live und bezeichnet die Lebenszeit von Daten in einem Zwischenspeicher.
Um die Last auf den für eine Zone authoritativen Nameservern zu verringern, speichern die von den Internetbenutzern verwendeten Forwarder die Auskünfte, die sie von den authoritativen Nameservern erhalten haben, für eine bestimmte Zeit zwischen. Der für die Zone zuständige Administrator kann das Caching der Forwarder in manchen Grenzen beeinflussen.
Wird eine Nameserver-Anfrage positiv beantwortet, übermittelt der authoritative Nameserver zusammen mit dem angefragten Resource Record die gewünschte Lebenszeit des Eintrags in Form der TTL. Ist im Zonefile für den Resource Record keine TTL angegeben, so übermittelt der authoritative Nameserver den mit $TTL im Zonefile gesetzten Defaultwert. Der authoritative Nameserver liest das Zonefile von oben nach unten und übermittelt immer den Wert des zuletzt gelesenen $TTL-Kommandos. Deswegen sollte $TTL immer so weit wie möglich am Anfang des Zonefiles gesetzt werden.
Wird eine Nameserver-Anfrage mit NXDOMAIN ("der angefragte Resource Record existiert nicht") beantwortet, so übermittelt der authoritative Nameserver zusammen mit der negativen Antwort die "minimum TTL" aus dem SOA-Record.
Der Forwarder übermittelt die Antwort weiter an die Quelle der Anfrage und speichert die Antwort für die übermittelte Zeitdauer zwischen, so dass weitere Anfragen nach dem gleichen Resource Record innerhalb dieser Zeitdauer ohne erneuten Zugriff auf den authoritativen Server beantwortet werden können.
Bevor man zeitkritische Änderungen an einer Zone vornimmt (z.B. Umzug eines Web- oder Mailservers auf eine andere IP-Adresse), ist zu empfehlen, zuerst einen oder beide TTL-Werte herunterzusetzen. Dies sollte mindestens einen TTL-Zeitraum vor der eigentlichen Änderung geschehen, damit die kürzere TTL sich herumgesprochen hat. Nachdem die Änderung erfolgreich durchgeführt wurde, kann die TTL wieder heraufgesetzt werden.
Wenn es sich bei der Änderung um Veränderung oder Löschung bereits existierender Resource Records handelt, genügt es, die im $TTL-Statement gesetzte default TTL zu verändern. Möchte man neue Resource Records eintragen, so muss die minimum TTL im SOA-Record verkürzt werden, damit die Sichtbarkeit der neuen Einträge nicht durch zwischengespeicherte negative Antworten verzögert wird.
Der Betreiber eines Forwarders kann konfigurieren, in welchem Rahmen die von authoritativen Nameservern übermittelten TTLs beachtet werden sollen. Dies dient hauptsächlich dazu, abstrus gesetzte Werte auszufiltern, um den Forwarder zu entlasten. Große ISPs nutzen diese Möglichkeit insbesondere bei den von dyndns gesetzten kurzen TTLs.
In einer Zone müssen die Nameserver, an die die Zone delegiert ist, genannt werden. In einer hidden-master-Konfiguration gibt es also keinen NS-Eintrag für den Master, sondern nur für die Slaves.
Auf der rechten Seite eines NS-Records muss _immer_ ein A-Record stehen. Es ist nicht erlaubt, hier direkt eine IP-Adresse einzutragen. Auf der rechten Seite eines NS-Records einen CNAME einzutragen, ist zwar streng genommen erlaubt, aber nicht zu empfehlen. Die zusätzlich notwendigen Abfragen erzeugen unnötige Last.
Soll eine Domain am Mailverkehr teilnehmen, so ist es notwendig, einen oder mehrere MX-Records in die Zone einzutragen. MX-Records haben zusätzlich zu ihrem Ziel eine Priorität. Wird eine Mail an die Domain zugestellt, so versucht der absendende Mailserver zuerst den MX niedrigster Priorität. Kann er die Mail dort nicht ausliefern, versucht er der Reihe nach die MXe höherer Priorität.
Gibt es für einen Domainnamen keinen MX-Record, sondern nur einen A-Record, wird die Mail an diesen zugestellt. Dieses Verhalten ist historisch bedingt und nicht mehr sinnvoll. Trotzdem wird es immer noch so gehandhabt. Soll ein Domainname nicht am Mailverkehr teilnehmen, so ist es sinnvoll, einen MX-Record auf ein System zu setzen, das für den Domainnamen eingehende Mail mit einem permanenten Fehler ablehnt.
Steht auf der rechten Seite eines MX-Records ein CNAME, zeigt manche ältere Software eigenwilliges Verhalten. Aus diesem Grund sollte man auch hier nur Namen eintragen, für die direkt ein A-Record auf die IP-Adresse verweist.
Diese Webseite wurde mit Hilfe eines PHP-Scripts erstellt, das aus einer einfach formatierten Quelltextdatei eine HTML-Seite erzeugt.
Zurück zu Zugschlus' manchmal nützlichen Antworten
Printer Friendly Version
Credits
Marc Haber
24.09.2002 14:41