Unser Unternehmen freut sich darauf, ein eigenes öffentliches DNS bereitzustellen und zu verwalten. Ich skizziere die Bereitstellungsaktivität, bin mir aber nicht ganz im Klaren, wo ich meinen Firmendomänennamen registrieren und wie ich mein öffentliches DNS zuordnen soll. Kann mir bitte jemand den Verkehrsfluss erklären?
Antwort1
Ich habe früher für ein Domänenregister gearbeitet und war Teil der DNS-Arbeitsgruppen der IETF. Daher gebe ich Ihnen eine Einführung.
Das Domain Name System ist hierarchisch aufgebaut. Wenn Sie die Daten für einen Domänennamen nachschlagen, gehen Sie im Allgemeinen ganz nach oben und arbeiten sich dann nach unten vor.
Ganz oben steht die Root. Die Root-Nameserver sind eine Anzahl von Servern, die über die ganze Welt verteilt sind und bei denen jede Frage immer beginnt – es sei denn, die Daten werden zwischengespeichert, aber dazu kommen wir später. Als normaler Benutzer werden Sie sie in einem Domänennamen nicht sehen, aber sie sind da.
Als nächstes kommen die Top Level Domains. Sie werden in generische Top Level Domains (wie .com, .net oder .movie) und länderspezifische Top Level Domains (wie .us für die USA, .no für Norwegen oder .cn für China) unterteilt.
Danach kommen die Second-Level-Domains. Diese kaufen Sie normalerweise als Endkunde. Wenn Sie beispielsweise example.com besitzen möchten, gehen Sie zu einem Registrar, prüfen, ob example.com verfügbar ist, und legen Sie es in diesem Fall in den Warenkorb und klicken Sie auf „Bezahlen“. Dann lassen Sie entweder den Registrar oder ein anderes Hosting-Unternehmen Ihr DNS für Sie verwalten, oder Sie richten Ihre eigenen DNS-Server ein und lassen sich die Domain vom Registrar delegieren. Delegierung bedeutet, dass sie Daten registrieren, die besagen, dass Ihre DNS-Server für diese Domain verantwortlich sind.
Sobald Sie Ihre Domain besitzen, können Sie auch Third-Level-Domains oder Subdomains einrichten. Dadurch wird den DNS-Servern eine weitere Hierarchie hinzugefügt. Sie können auch Hostnamen einrichten, die für den durchschnittlichen Benutzer genau gleich aussehen.
Sehen wir uns also eine durchschnittliche DNS-Suche an.
Nehmen wir an, Sie möchten zuwww.beispiel.com. Als Erstes sucht Ihr DNS-Server bei den Stammservern nach, wer für .com zuständig ist. Die Adressen der Stammserver sind bereits in Ihrem DNS-Server integriert, sodass Sie diese normalerweise nicht nachschlagen müssen. Stattdessen suchen wir nach den Informationen für .com.
Ich werde hier das Programm „dig“ verwenden, bin aber wegen der Lesbarkeit der Ausgabe dankbar.
Zuerst fragen wir nach den Nameservern (ns) für com. Wir fragen dies direkt vom Server a.root-servers.net ab, der einer der Root-Server für das DNS-System ist.
$ dig ns com. @a.root-servers.net.
Die Ausgabe lautet wie folgt (erneut gekürzt):
;; QUESTION SECTION:
;com. IN NS
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
Der FRAGENABSCHNITT zeigt uns, wonach wir fragen, in diesem Fall die NS-Datensätze für com.
Der AUTHORITY-ABSCHNITT zeigt uns, dass der Root-Server nicht für .com verantwortlich ist, sagt uns aber, wer es ist. In diesem Fall sagt er uns, dass a.gtld-servers.net verantwortlich ist.
Es gibt uns auch einen ZUSÄTZLICHEN ABSCHNITT, der Adressdatensätze (A für IPv4 und AAAA für IPv6) für a.gtld-servers.net enthält. Diese Adresse wird als „Glue“ bezeichnet und gilt nicht als autoritative Antwort, sondern als Hinweis, dass dies die Adresse ist, die im System aufgeführt wurde. „Glue“-Datensätze werden benötigt, wenn Sie die IP-Adresse eines Servers benötigen, den Sie sonst nur durch eine DNS-Suche erreichen können, für die Sie die IP-Adresse des Nameservers benötigen. Das Ganze ist ein bisschen rekursiv.
Wie dem auch sei, lassen Sie uns weitermachen und die Nameserver für example.com nachschlagen. Dies wird sich ein wenig von dem unterscheiden, was Ihnen der echte DNS sagt, aber dies ist ein Beispiel, also verwenden wir Beispieldaten.
$ dig ns example.com. @192.5.6.30
Wir fragen nach der IP-Adresse von a.gtld-servers.net, die wir oben erhalten haben. Sie sind maßgebend für die .com-Domäne und sollten uns daher mitteilen können, welche Nameserver example.com hat.
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS ns2.example.com.
example.com. 172800 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns2.example.com. 172800 IN A 192.0.2.4
ns1.example.com. 172800 IN A 192.0.2.5
Und nun erfahren Sie, warum dieser Kleber wichtig ist. Da die Nameserver von example.com unter example.com liegen, werden sie von den Nameservern unter example.com verwaltet. Im Wesentlichen werden Sie aufgefordert, Bob anzurufen, um seine Telefonnummer zu erfahren, da nur Bob Bobs Telefonnummer kennt. Der Kleber ist ein Hinweis. Bob hat möglicherweise seine Nummer geändert, aber das wissen die Nameserver für .com.
Nachdem wir nun die Adresse der example.com-Nameserver kennen, können wir endlich nach dem Hostnamen fragen.
$ dig a www.example.com. @192.0.2.4
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
Wir haben endlich den Adressdatensatz für diewww.beispiel.comHostname. Beachten Sie, dass hier kein ZUSÄTZLICHER ABSCHNITT vorhanden ist, da für diese Abfrage kein solcher Abschnitt erforderlich ist. Wir stellen eine direkte Frage und erhalten eine präzise Antwort von einem Server, der für die Domäne maßgebend ist.
Diese ständige Suche ist eine Verschwendung von Zeit und Ressourcen, daher wird Ihr lokaler DNS-Server normalerweise als Cache verwendet. Ist Ihnen aufgefallen, wie alle DNS-Einträge aussehen? Die Felder in einem DNS-Eintrag lauten wie folgt: Domäne, Time To Live (TTL), Klasse (in unserem Fall IN für Internet), Typ (A für Adresse, NS für Nameserver usw.) und Daten (zum Beispiel eine IP-Adresse für einen A-Eintrag).
Die TTL im DNS-Eintrag gibt an, wie lange ein Cache die Daten speichern darf. Einträge, von denen erwartet wird, dass sie sich nicht oder nur sehr selten ändern, haben lange TTLs. Zum Beispiel die 172800 Sekunden TTL in den ersten paar Einträgen, die wir uns angesehen haben. Einträge, die kurzfristig aktualisiert werden können, haben niedrige TTLs, wie zum Beispiel die 300 Sekunden TTL fürwww.beispiel.com.
Wenn wir eine DNS-Suche durchführen, müssen wir nicht den ganzen Weg zu den Stammservern zurücklegen, wenn die Daten, nach denen wir bereits suchen, zwischengespeichert sind. Normalerweise greifen wir ständig auf .com-Domänen zu, sodass die Daten fast immer auf unserem lokalen DNS-Server zwischengespeichert sind. Dies bedeutet jedoch, dass es eine Weile dauern kann, bis die Änderungen wirksam werden, wenn Sie DNS-Daten ändern. In der Praxis bedeutet dies, dass Sie entweder die TTLs im Voraus ändern oder Ihrem Chef mitteilen müssen, dass es einige Zeit dauern wird, bis die Änderungen vollständig wirksam werden.
Um Ihre Domain zu registrieren, müssen Sie normalerweise zu einem Registrar für die Top-Level-Domain gehen, unter der Sie sich registrieren möchten. Die meisten Hosting-Unternehmen und Domain-Registrare können Domains unter einer Reihe verschiedener Top-Level-Domains registrieren, sodass Sie praktisch jede davon auswählen können.
Die Registrare sind Wiederverkäufer für das Register. Das Register ist das Unternehmen oder die Organisation, die die betreffende Top-Level-Domain tatsächlich betreibt. Als Endbenutzer haben Sie es jedoch nur mit dem Registrar oder sogar nur mit Ihrem Hosting-Unternehmen zu tun.
Die meisten Registrare verfügen über Weboberflächen, die viele der technischen Details der Delegation und der DNS-Einträge verarbeiten. Dennoch wird Ihnen das Leben erheblich leichter fallen, wenn Sie die DNS-Grundlagen verstehen, selbst wenn Sie sich auf die Weboberfläche Ihres Registrars verlassen.
Wenn Sie mehr über DNS erfahren möchten und in der IT arbeiten, sollten Sie unbedingt wissen, wie DNS funktioniert, da es die Quelle vieler potenzieller Probleme ist. Ich empfehle das Buch „DNS and Bind“ von O'Reilly. Es ist sehr umfassend und macht Sie zum DNS-Experten. Wenn Sie Ihre eigenen DNS-Server betreiben möchten, empfehle ich Ihnen dringend, dieses Buch zu lesen. Es behandelt zwar die Bind-DNS-Serversoftware, aber die gleichen Prinzipien gelten für jede andere DNS-Serversoftware auf dem Markt.