In einer DNS-Zone werden alle relevanten Informationen einer Domain bzw. eines Teilbereiches einer Domain in sogenannten Resource Records gespeichert.
Jede DNS-Zone wird auf dem authoritativem Nameserver verwaltet und von diesem verbreitet.

Eine Zone ist in verschiedene Bereiche gegliedert.

SOA-Record
Der erste Bereich einer Zone ist der SOA (Start of Authority) und beschreibt die wichtigsten Daten einer Zone. Eine Zone ohne diesen Eintrag erfüllt nicht den DNS-Standard und kann z.B. nicht zwischen Nameservern transferiert werden.

Der SOA-Record ist wie folgt aufgebaut:

• Zonenname
  Der Name der Zone
• TTL
  Die Time-to-Live für den SOA-Records (optional)
• MNAME
  Der Primary Master Nameserver für diese Zone
• RNAME
  Emailadresse des Zuständigen für diese Zone
• SERIAL
  Seriennummer der Zone. (Wird bei jeder Änderung erhöht)
• REFRESH
  Sekundenabstand in den die Slave-Nameserver anfragen, ob sich etwas geändert hat
• RETRY
  Sekundenabstand in denen ein Slave wiederholt, falls sein Master nicht antwortet
• EXPIRE
  wenn der Master auf einen Zonentransfer-Request nicht reagiert, deaktiviert ein Slave nach dieser Zeitspanne in Sekunden die Zone
• MINIMUM
  Die erste Bedeutung ist die Standard Time-to-Live für die Zone (Gilt für alle Records, wo die TTL nicht explizit angegeben ist.
  Die zweite Bedeutung ist die Standard Negativ Time-to-Live (z.B. für Anfragen zu A-Records, die nicht existieren)

Somit könnte ein Beispiel-SOA fogendermassen aussehen.

In diesem Beispiel SOA-Record für die Zone musterman.de wird festgelegt, dass der Hostname des Primary Nameserver ns1.mustermann.de lautet.
Der Administrator der Zone ist unter der Emailadresse hostmaster@mustermann.de erreichbar (der 1. Punkt in der Email-Adresse muss durch ein @ ersetzt werden)

Die Seriennummer der Zone beträgt zur Zeit 200612011. Bei der nächsten Änderung wird sie (manuell) auf 200612012 erhöht werden.

Weiterhin wird definiert, dass sich ein Slave-Nameserver alle 12 Stunden mit seinem Master per Zonentransfer synchronisiert. Ist sein Master nicht erreichbar, so wird alle 2 Stunden ein neuer Versuch gestartet. Kann sein Master innerhalb 2 Wochen nicht kontaktiert werden, so erklärt der Slave-Nameserver die Zone als inaktiv und beantwortet keine diesbezüglichen DNS-Requests mehr. Als Standard (Default) Time To Live für Resource Records und fehlgeschlagene Request dieser Zone ist 1 Tag vorgegeben.

Abfragen des SOA:

Der geneigte Unix-Administrator benutzt zum Abfragen des SOA folgenden Befehl:

Der Windows-Mokel benutzt folgenden Befehl:

OK, nslookup gibts unter Unix auch, ist aber viel zu einfach zu lesen

NS-Record
In einem NS-Record werden alle authoritativen Nameserver einer Zone definiert.
Für jede Zone muss mindestens ein NS-Record vorhanden sein.

Ein NS-Record ist folgendermassen aufgebaut:

Beispiel:

Für die Zone mustermann.de existieren somit 2 authoritative Nameserver.
(ns1.mustermann.de und ns2.mustermann.de).
Die TTL der Records beträgt 1 Tag.
Welcher von beiden die Funktion des Primary Nameserer hat, ist hier nicht zu erkennen,
sondern wird nur im SOA-Record definiert.

Abfragen der Nameserver einer Zone:

Unix:

Windows:

MX-Record
MX-Record steht für Mail-Exchanger-Record und definiert die zuständigen Mailserver einer Zone.
D.H. anderen Mailservern wird über die MX-Records mitgeteilt, welche Mailserver zum zustellen einer Email kontaktiert werden können.
Zusätzlich wird über die Wertigkeitszahl des Records mitgeteilt,
welcher der angegebenen Mailserver zuerst kontaktiert werden sollte.
Je kleiner die Wertigkeitszahl ist, desto höher steht der Mailserver in der Reihenfolge.
(irgendwie unlogisch, ist aber so)

Also, Spammer aufgepasst! Der Server mit der niedrigsten Wertigkeits-Zahl ist der erste, nicht der mit der höchsten

Ist ein angegebener Mailserver nicht erreichbar, wird laut RFC der Mailserver mit der nächsthöheren Wertigkeitszahl kontaktiert.

Ein MX-Record ist folgendermassen aufgebaut:

Beispiel:

Für die Zone mustermann.de existieren somit 2 Mailserver.
(mail1.mustermann.de und mail2.mustermann.de).
Die TTL der Records beträgt 1 Tag.
Der 1. Mailserver der Zone ist mail1.mustermann.de (niedrigste Wertigkeitszahl).
Falls dieser nicht erreichbar ist, wird als nächstes der Server mail2.mustermann kontaktiert werden.

Abfragen der Mailserver einer Zone:

Unix:

Windows:

A-Record

Ein A-Record dient im DNS dazu, einen Hostnamen in eine IP-Adresse aufzulösen und ist der häufigste Record in einer DNS-Zone.
Da alle Server nur über IP-Adressen in einem TCP-IP Netzwerk angesprochen werden, diese aber schlecht zu merken sind, wird stellvertretend für die IP-Adresse ein Name im DNS gespeichert.
Dieses Mapping von Namen zu IP-Adressen wird in einem A-Record im DNS gespeichert.

Falls man also z.B. www.mustermann.de in seinen Browser eintippt, wird auf dem für die Zone
mustermann.de zuständigem Nameserver der A-Record www.mustermann.de abgefragt um die IP-Adresse des für die Webseite zuständigen Webservers zu ermitteln.

Obwohl www mitlerweile ein Synonym für eine Webseite einer Domain ist, könnte der Name aber auch völlig anders lauten. Im DNS stellt dieser Name nur einen ganz normalen A-Record dar. Eine Webseite könnte auch unter jedem anderen A-Record erreichbar sein.
(Vorrausgesetzt, der Webserver ist entsprechend konfiguriert.)

Ein A-Record ist folgendermassen aufgebaut:

Beispiel:

Die Webseite mit dem Namen www.mustermann.de wird also von einem Webserver mit der
IP-Adresse 212.126.218.163 verwaltet.
Die IP-Adresse des Hosts gate.mustermann.de lautet 212.126.218.164.

Abfragen eines A-Records:

Unix:

Windows:

Time to Live (TTL) und Nameservercache
Durch die TTL wird die Gültigkeitdauer eines Records definiert. Hierin ist somit auch die Trägheit von Änderungen an einer Zone begründet. Immer wenn ein Nameserver eine DNS-Anfrage eines Clients beantwortet (also einen Ressource-Record ausliefert), wandert diese Antwort automatisch in den Cache des Nameservers. Die TTL des Ressource-Records weist in dem Fall den Nameserver an, wie lange er mit den Daten aus dem Cache Anfragen beantworten darf, ohne erneut den authoritativen Nameserver nach den benötigten Informationen zu befragen.
Dieser Cache-Machanismus wird benutzt, um Bandbreite durch weniger Anfragen an den Authoritativen Nameserver zu sparen und die Antwortzeiten eines Nameservers klein zu halten.
Ein Nachteil dieses Verfahrens ist, das Änderungen einer Zone relativ lange brauchen (ca. 1- 1,5 Tage), um sich über alle Nameserver im Internet zu verbreiten.

DynDNS Adressen
DynDNS-Adressen sind prinzipiell nichts anderes als DNS-Records, deren TTL auf einen relativ geringen Wert eingestellt ist (ca. 5min)
Durch die geringe TTL verbreiten sich somit Änderungen einer DynDNS-Adresse relativ schnell im Internet.
Technisch umgesetzt wird die Aktualisierung einer DynDNS-Adresse durch einen DynDNS-Client, welcher sich mit einer Webseite eines DynDns-Providers verbindet. Der Client meldet sich dann mit den entsprechenden Zugangsdaten an und übermittelt danach seine aktuelle IP-Adresse.
Anhand der beim DynDNS-Provider hinterlegten Accountdaten werden dann die zugehörige DNS-Adressen in dem Nameserver des DynDNS-Providers aktualisiert.
Die Kommunikation des Clients mit dem DynDNS-Provider ist standardisiert und in dem DynDNS-Protokoll definiert.
DynDNS- Clients sind mittlerweile für viele Betriebssysteme erhältlich und zudem integrieren immer mehr Hardwarehersteller einen solchen Client in Ihre Produkte (z.B. DSL-Router).