Domain, Zone, Web- und Nameserver, Ägypten?

Was ist ein Nameserver?

Nameserver sind im Internet erreichbare Computer, die an der Namensauflösung beteiligt sind. Diese Rolle können die Rechner in verschiedenen Formen wahrnehmen:

Ein für eine Domain authoritativer Nameserver kann Anfragen für diese Domain authoritativ, also mit endgültiger Sicherheit, beantworten, weil er die Informationen für die Domain selbst vorliegen hat und sich hierbei nicht auf die Antworten anderer Nameserver verlassen muss.

Ein authoritativer Nameserver, der als Master (auch als “primary” bezeichnet) konfiguriert ist, ist ein Nameserver, der die Informationen für seine Domains von ausserhalb des Domain Name System erhält. Gängig sind hier beispielsweise Zonefiles oder Datenbanken. Ein Master, an den die Zone selbst nicht delegiert ist , wird als “hidden master” bezeichnet und kommt vor allen Dingen dort zum Einsatz, wenn der Domaininhaber zwar die Zone selbst unter eigener Kontrolle haben möchte, aber nicht hinreichend gut angebunden ist, um die Zone selbst zu sich delegieren zu lassen.

Ein authoritativer Nameserver, der als Slave konfiguriert ist, erhält die Informationen für seine Domains mit DNS-Mechanismen (Zone Transfer, AXFR oder neumodische IXFR) von einem als Master konfigurierten authoritativen Nameserver, der in der Konfiguration des Slaves festgelegt ist. Der Slave holt sich die aktuellen Daten für die Domain in regelmässigen Abständen oder auf explizite Anforderung vom Master und kann fortan auch dann für “seine” Domains authoritative Auskünfte erteilen, wenn der Master gerade nicht erreichbar ist. Wenn der konfigurierte Master für eine bestimmte Zeit nicht erreichbar war, stellt der Slave die Erteilung authoritativer Auskünfte für die betreffende Domain ein.

Erhalten die DNS-Server ihre Daten über andere Wege (z.B. über eine replizierte SQL-Datenbank), ist auch der Server, dessen DNS-Server auf einen SQL-Slave als Datenquelle zugreift, im DNS-Sinne ein Master.

An einen authoritativen Nameserver ist eine Zone delegiert, wenn dieser Nameserver in einem auf diese Zone zeigenden NS-Record in der “Parent Zone” auftaucht. Die in der Parent Zone eingetragenen NS-Records müssen mit denen in der Zone selbst übereinstimmen.

Ein Full Resolver oder auch Recursor ist ein Nameserver, der auch Anfragen entgegennimmt, für deren Domains er nicht authoritativ ist. Er bemüht sich dann, die benötigten Informationen aus dem DNS herbeizuschaffen und liefert eine nicht authoritative, “best effort” Antwort an den Anfragenden aus.

Die Nameserver, die ein Endbenutzer in seinem Rechner eintrögt oder (z.B. per PPP, DHCP oder DNSSD) zugewiesen bekommt, sind Full Resolver. Die von Endbenutzern beim Full Resolver ankommenden Anfragen sind sogenannte “rekursive” Anfragen.

Anstelle des Begriffs “Full Resolver” sind auch die Begriffe Full Service Resolver, Recursive Server, Recursive Resolver und Forwarder in Verwendung. Im Zusammenhang mit dynamischen Updates geniesst der Begriff Forwarder aber eine Sonderbedeutung, so dass dieser Begriff im Allgemeinen nicht korrekt verwendet wird.

Oft findet man bei kleineren Installationen die Funktionen eines authoritativen Nameservers und eines Full Resolvers auf einer Maschine vereint. Für die dort liegenden Zonen wird dem gesamten Internet authoritativ Auskunft erteilt, und zusätzlich werden rekursive Anfragen aus dem “eigenen” Netz beantwortet.

Diese Vereinigung von Aufgaben ist nach meiner Meinung nur in den seltensten Fällen sinnvoll, da sie nichts miteinander zu tun haben, die sachgerechte Konfiguration des Nameservers unnötig verkomplizieren und im Falle von Konfigurationsfehlern sehr leicht dazu führen können, dass die Benutzer des fehlkonfigurierten eigenen Nameservers eine andere Sicht auf das Internet haben als der Rest der Welt.

Was ist eine Domain, was ist eine Zone?

Der DNS ist eine verteilte, hierarchische Datenbank, in der die Namen und IP-Adressen aller im Internet sichtbaren Systeme hinterlegt sind. Ein Beispiel für die Hierarchie sieht man in der Abbildung.

Jeder Knoten im abgebildeten Baum ist eine Domain. Eine Domain, die im Baum unterhalb einer anderen Domain liegt, wird eine Subdomain genannt. Die Blläter des Baumes sind ebenfalls Domainnamen, wobei dieser Sonderfall auch als Hostname bezeichnet werden kann. mail.at.example.com ist also ein Hostname, eine Domain und eine Subdomain von at.example.com.

Die Wurzel des Baumes wird in der Literatur als “.” bezeichnet; die direkt darunter liegenden Domains (z.B. de, com, net, org) als “Top-Level-Domains” oder “First-Level-Domains”. Die “höchsten” Domains, die man als Unternehmen oder Privatmensch mit vertretbarem Aufwand selbst registrieren kann, sind die “Second-Level-Domains” wie zum Beispiel example.com.

Manche First-Level-Domains vergeben sogenannte "generische Second-Level-Domains". In diesen First-Level-Domains kann man dann erst Third-Level-Domains selbst registrieren lassen, die dann wie zum Beispiel in Grossbritannien unterhalb von co.uk oder or.uk liegen können.

Glücklicherweise ermöglicht der DNS, die Verteilung der Daten etwas von der Hierarchie unabhängig zu gestalten. Das ist insbesondere dann praktisch und wichtig, wenn Subdomains einer Domain unter unterschiedlicher Verwaltung stehen oder auch nur ihre Größe ungleichmäßig verteilt ist. Die Einheit für die Verteilung der Daten ist die Zone. Im Beispiel ist die Domain example.com und ihre Subdomains auf zwei Zonen verteilt. example.com ist an die im Beispiel rechts eingezeichnete Zone delegiert, die die Resource Records für www.example.com, at.example.com und die Domains unterhalb von at.example.com direkt selbst enthält. de.example.com ist an die im Beispiel links eingezeichnete Zone delegiert, die auf einem ganz anderen Nameserver liegen kann und von anderen zuständigen Personen verwaltet werden kann. Bei der weit verbreiteten Nameserver-Software bind liegen die Daten einer Zone stets in einer Datei, dem sogenannten Zone File.

Im Zone File werden schlussendlich die eigentlichen Einträge gemacht, die den DNS mit Leben füllen. Diese Einträge erfolgen in Form von Resource Records (RR), die einen Domainnamen mit Informationen verschiedenster Art verknüpfen. Wegen der Wichtigkeit dieses Stoffes wird es hierfür einen eigenen ZMNA-Artikel geben.

Der Weg vom Registrar zum Webserver

Eigentlich ist das alles ganz einfach. Gehen wir Schritt für Schritt vor für den üblichen Fall, dass K unter dem Namen www.example.com eine Webseite ins World Wide Web stellen möchte:

• K bittet seinen Provider P, für ihn die Domain example.com zu registrieren.
• P legt auf seinen Nameservern N1 und N2 eine Zone an, die die gewönschten Nameservice-Daten für die Domain example.com enthält.
• P sucht sich einen der für die von K gewählte Top-Level-Domain (hier: .com) zuständigen Registrare R heraus und registriert über diesen die Domain example.com.
• R trägt K als kaufmännischen Ansprechpartner (admin-c) und P als technischen Ansprechpartner (tech-c, zone-c) in der Domainregistrierungsdatenbank ein und sorgt dafür, dass in den für com zuständigen Nameservern die Zone für example.com an N1 und N2 delegiert wird.
• Somit ist P nun in der Lage, weltweit sichtbare Resource Records für die Domain example.com im DNS bekannt zu machen.
• P legt einen Webserver W für www.example.com an und gibt K die Möglichkeit, auf diesen Webserver die gewünschten Inhalte zu hinterlegen.
• P trägt in der Zone für example.com die passenden Resource Records (hier: einen A- oder einen CNAME-Record) an, damit die IP-Adresse von W mit dem Domainnamen www.example.com verknüpft sind.

Von der Idee bis zum benutzbaren Webserver führten also die folgenden Schritte:

• Registrierung der Domain.
• Vorbereitung der Nameserver.
• Delegation der Domain.
• Vorbereitung des Webservers
• Hinterlegung der Inhalte auf dem Webserver
• Eintragung des Hostnamens www auf dem Nameserver

Diese Schritte können in den verschiedenen Geschäftsmodellen auf unterschiedliche Beteiligte verteilt werden. Oben beschrieben ist eine der üblichsten Vorgehensweisen, bei der der Kunde sowohl die Domain selbst, den DNS und den Webserver beim gleichen Liferanten bestellt.

Was für Einträge brauche ich in meiner frisch delegierten Zone?

Die Antwort auf diese Frage ist wie so häufig “es kommt darauf an”, nämlich darauf, was man mit der Zone eigentlich machen möchte.

Eine Zone muss immer und zwingend mindestens zwei Einträge enthalten: Einen SOA- und mindestens einen NS-Eintrag. Die NS-Einträge müssen mit den Einträgen in der “Parent Zone” (z.B. .com für .example.com) übereinstimmen.

Weitere Einträge sind nur dann notwendig, wenn die Domain wirklich benutzt werden soll:

• Wenn die Domain im E-Mail-Verkehr verwendet werden soll, so sind MX-Records notwendig, die den Mailservern draussen im Internet bekannt geben, wo Mail an die Domain abzuliefern ist.

  Hier sind wiederum andere Dinge zu beachten:

  • Ein MX-Record sollte immer nur auf einen Rechnernamen zeigen, der wiederum als A-Record eingetragen sein muss. Insbesondere funktionieren hier keine IP-Adressen, und auf CNAMEs zeigende MX-Records sind mindestens umstritten.
  • Ein MX-Record ist mit einer Priorität versehen. Ein externer Mailserver wird zuerst versuchen, Mail für die Domain bei dem Rechner abzuliefern, auf den der MX-Record mit der kleinsten Priorität zeigt. Erst wenn dieser nicht erreichbar ist, kommen die mit höherer Priorität zum Zuge.
  • Ein Mailserver muss dafür konfiguriert sein, Mails für eine Domain anzunehmen. Blosses Eintragen eines MX-Records funktioniert in aller Regel nicht.
  • In vielen Fällen soll eine Domain nicht am Mailverkehr teilnehmen. In diesen Fällen ist es zweckmässig, den MX-Record einfach wegzulassen. Einen MX-Record auf 127.0.0.1 oder auf einen anderen beliebigen Host zu setzen, der keine Mail für die Domain annehmen kann, ist unhöflich und sollte unterbleiben.

  • Mail an einen Domainnamen, für den ein A-Record, aber kein MX-Record eingetragen ist, wird an die IP-Adresse zugestellt, die im A-Record genannt ist. Dieses Verhalten ist eine Altlast aus längst vergangenen Zeiten, in denen jeder Rechner sein eigenes unabhängiges Mailsystem hatte und ist heute in vielen Fällen ist dies unerwünscht.

    Besonders lästig ist es in dem Fall, in dem eine Domain nicht am Mailverkehr teilnehmen soll, aber ein Webserver ohne vorangestelltes www erreichbar sein soll. Somit werden nämlich Mails an die Domain beim Webserver zugestellt, was heutzutage in den meisten Fällen nicht sinnvoll ist. Dieses Problem ist wirklich befriedigend nicht zu lösen. Unter Umständen ist es ratsam, einen MX-Record auf einen Mailserver zu setzen, der Mails für den Domainnamen mit "550 no e-mail service for this recipient domain" ablehnt.

• Die allermeisten Domains werden registriert, um einen Webserver anzubieten. Hierfür hat sich eingebürgert, den Hostnamen “www” in der registrierten Domain zu wählen, was zu Hostnamen wie “www.example.com” führt. Um dies zu erreichen, wird im Zonefile ein A-Record eingetragen, der den Hostnamen “www” mit der IP-Adresse des Webservers verknüpft. Die explizite Reservierung einer weiteren Domain ist hierfür nicht notwendig; der Inhaber einer Domain hat die Kontrolle über alle Domain- und Hostnamen unterhalb dieser Domain.

  Allerdings ist es nicht zwingend notwendig, für einen Webserver den Hostnamen “www” zu verwenden. Webserver können unter beliebigen Hostnamen angelegt werden, und es ist selbstverständlich auch möglich, innerhalb einer Domain oder innerhalb einer Zone mehrere Webserver anzulegen. Sie müssen nur unterschiedliche Namen haben, damit sie unterschieden werden können.

Die gängigsten Terminologiefehler im DNS

• "Lieber Provider, bitte registriere für mich die Domain www.example.com."

  Das kann der Provider nicht tun. Der Kunde will in diesem Fall die Domain example.com registriert haben, und in der Zone für diese Domain einen Eintrag “www”, für den der Provider zusätzlich zum Domainnamen auch noch eine IP-Adresse braucht.

• "Lieber Provider, ich möchte bitte die Zugangsdaten, um die Webseiten auf meine Domain www.example.com hochzuladen."

  Diese Anfrage ist Unsinn. Eine Domain ist ein Begriff aus dem DNS. Im DNS gibt es weder Webseiten noch Zugangsdaten. Was der Kunde möchte, sind die Zugangsdaten zu dem Webserver, der in der Domain example.com mit dem Hostnamen www eingetragen ist.

• “Lieber Provider, meine Domain www.example.com ist nicht erreichbar.”

  Auch hier meint der Kunde meist, dass anstelle der Domain sein Webserver nicht erreichbar ist. Das kann eine Störung im Netz, eine Störung im Webserver, oder wirklich eine Störung im Domain Name Service sein. Dies korrekt zu diagnostizieren, überfordert die meisten Netzteilnehmer, und führt den Support des Providers in die Irre, weil jeder, der täglich mit Internetsystemen zu tun hat, bei einer gemeldeten Domainstörung immer zuerst und sofort den Nameserver prüfen wird, wenn auch die häufigsten Ursachen für die hier besprochenen Störungen nicht dort zu finden sind.

• "Lieber Provider, bitte route die Domain www.example.com auf die IP-Adresse a.b.c.d"

  Diese Anfrage ist - wie so oft - aus der Verwechslung zwischen Domain und Webserver entstanden, gemischt mit dem Halbwissen, dass IP-Adressen geroutet werden. Das ist natürlich auch terminologisch falsch.

  Mit diese Anfrage möchte der Kunde dem Provider in aller Regel mitteilen, dass er auf der IP-Adresse a.b.c.d einen Webserver bereitgestellt hat, der in der Lage ist, http-Anfragen für Webseiten unter http://www.example.com/ zu beantworten. Der Provider soll nun, damit dieser Webserver auch über den Namen erreichbar wird, einen A-Record im DNS eintragen, der den Namen www.example.com mit der IP-Adresse a.b.c.d verknöpft.

  Das ganze hat mit Routing noch weniger zu tun als mit Domains.