Wie ich beim Schreiben meiner Artikel gemerkt habe, ist es sinnvoll gewisse Grundlagen einmal abzuspalten, um darauf verweisen zu können. Ich werde daher immer einmal wieder den ein oder anderen Grundlagen-Artikel hier zusammenschreiben, der im ersten Moment vielleicht etwas aus dem Zusammenhang gerissen scheint, aber ggf. wertvolle Informationen für alle Einsteiger enthält oder auch dem ein oder anderen Erfahrenen als Auffrischung dienen kann. Ich versuche das möglichst prägnant und wo immer möglich an Beispielen zu beschreiben.

In diesem Artikel geht es im um das Domain Name System – das Konstrukt welches zu Arbeit am Rechner etwas leichter macht, da sich das menschliche Gehirn in der Regel Namen besser merken kann als Zahlenfolgen.

Der langjährige Standard für DNS-Server im Unix und Linux-Umfeld ist der BIND-Daemon und so ziemlich jeder der sich schon einmal mit DNS-Namen hat etwas eingehender beschäftigen dürfen (oder müssen), der weiß, dass die Syntax der Config-Files nicht gerade in die Kategorie „leicht verdaulich“ fällt. Zudem war BIND immer mal wieder ein Sorgenkind wenn es um Sicherheitslücken ging. Sehr verständlich, dass sich viele Website-Betreiber da lieber auf einen Hoster verlassen der das schon für sie regeln wird. Für mich auch lange ein valider Weg, aber eben auch einer mit Einschränkungen.

Jeder kennt bekannte Websites und deren Adresse wie etwas www.google.de oder www.amazon.com. Zudem gibt es mittlerweile die „Unsitte“ einfach die gewünschte Seite erst einmal in das Suchfenster des Browsers (oder der Suchmaschine) anstelle der Adresszeile einzugeben. Wichtig generell zu erkennen, dass es sich hierbei um eine Hierarchie handelt, zu lesen „von klein nach groß“ – die geringste Granularität steht also ganz links, die gröbste ganz  rechts. Nicht mit zum DNS gehören die Angaben vor und nach den „/“ Slashes drum herum. Davor steht das gewünschte Protokoll (heute in der Regel HTTPS) dahinter folgt die Ressourcen-Kennung auf dem Zielsystem. Optional und eher in Technikerkreisen bekannt sind Port-Angaben nach dem Doppelpunkt. So ergibt sich aus der Zeichenfolge https://www.meine-tolle-seite.org:8080/projekt/beschreibung/start.html“ dass man per verschlüsseltem HTTP-Protokoll mit einem Rechner Kontakt aufnehmen möchte der auf den Namen www.meine-tolle-seite.org hört, dazu soll der Browser den Port (entsprechend dem dortigen Serverprozess) 8080 ansprechen (gibt man diesen nicht an, so gilt bei HTTPS der Standard 443). Anschließend folgt noch die Bezeichnung der gewünschten Ressource innerhalb des Zielsystems (wie diese dann jeweils interpretiert wird, ist Aufgabe des dortigen Serverprozesses,wichtig ist dabei dass dieser daraus machen kann was immer er möchte, auch wenn es ursprünglich mal tatsächlich als Pfadangabe in einem Verzeichnisbaum gedacht war). Siehe hierzu auch die Beschreibung des Uniform Ressource Identifiers (URI) gemäß RFC 3986. Obwohl zwar mittlerweile der wohl häufigste Anwendungsfall, ist HTTP(S) bei Weitem nicht das einzige Protokoll, welches sich auf den Domain Name Service (DNS) verlässt um besser verständliche Namen als kryptische IP-Adressen (im IPv4-Bereich konnte man sich diese mit v.x.y.z ggf. noch halbwegs merken (32 Bit), aber spätestens bei IPv6 mit 128 Bit wirds langsam schwierig).

Kommen wir also zurück zur Namensausflösung bzw. dem Aufbau eines DNS-Namens. Ähnlich wie die URI ist auch diese nochmal in kleinere Teile unterteilt, damit es keine Überschneidungen gibt, sind die Trenner dort Punkte. Im Beispiel als www.meine-tolle-seite.org. Wir dröseln das einmal von groß nach klein auf: „.org“ ist eine sogenannte Top-Level-Domain, in der Regel sind diese 2-5-stellig, auch wenn es laut Spezifikation noch deutlich länger sein dürfte. Wie alt das System ist, sieht man unter anderem daran, dass es im Normalfall erst einmal nur ASCII-Zeichen ohne Unterscheidung von Groß- und Kleinschreibung zulässt. Diese Toplevel-Domains werden von der IANA vergeben, zuständig für so ziemlich alles was Nummern im Internet betrifft. Für die Verwaltung der einzelnen Topleveldomains ist dann jeweils eine Organisation zuständig (wie dies ausgestaltet wird ist der Organisation selbst überlassen, ebenso wie die Regeln für die nächsten Stufen in DNS, wozu wir gleich kommen). In Deutschland ist es es die DENIC, diese gemeinnützige Genossenschaft kümmert sich um alles was mit der Topleveldomain „.de“ zusammen hängt.

Den allermeisten Usern und Betreibern von Websites sind hingegen die Second-Level-Domains bekannt, häufig finden sich bei Firmen unter den entsprechenden Second-Level-Domains mit einer Landeskennung als Topleveldomain entsprechende Angebote für das jeweilige Land. So liefert google.de standardmäßig deutsche Inhalte aus, nimmt man hingegen google.fr erhält man eine französische Variante. Über die sogenannten Registrare (in Deutschland Mitglieder der DENIC) kann man eine Second-Level-Domain registrieren. Je nach Land sind hierzu ggf. bestimmte Nachweise erforderlich, unterhalb einiger Topleveldomains kann aber prinzipiell jeder eine Domain auf sich registrieren (so lange dies noch kein anderer getan hat). Sofern man nicht gerade selbst ein Registrar ist oder bei einem arbeitet muss man einen solchen mit der Registrierung der gewünschten Second-Level-Domain beauftragen. Recht häufig gibt es aber Angebote im Zusammenhang mit dem Betrieb eines Servers oder einer Website (Hosting), bei denen eine bestimmte Anzahl Second-Level-Domains bereits enthalten ist.

Unterhalb der Second-Level-Domains ist man dann in aller Regel recht frei was die Gestaltung und Nutzung betrifft, auch hier kommt es natürlich auf die exakten Verträge an – die einfachsten und günstigsten Hosting-Angebote umfassen in der Regel nur eine handvoll festgelegte und nicht änderbare Domainnamen in der Regel zum Betrieb von Websiten und Mailverkehr, daher trifft man häufig auf www,mail,imap,pop3,smtp oder ftp als dritte Ebene der Hostnamen. Komfortabler ist es natürlich wenn man bereits auf dieser Ebene selbst tätig werden kann, hier kann man in der Theorie auch beliebige weitere Ebenen einführen wenn man das möchte. Wichtig ist dabei, dass man weitere Subdomains und Namen auf der gleichen Ebene mischen darf. So kann www.meine-firma.de auf einen Rechner verweisen während berlin.meine-firma.de und hamburg.meine-firma.de Subdomains kennzeichnen unterhalb derer dann ggf. die einzelnen Rechner der Standorte aufgelistet werden (wenn man möchte evtl. dort nochmal nach Funktionen aufgeteilt – das Spiel kann man fast beliebig weit treiben, aber irgendwann wird es verdammt viel Arbeit beim Tippen.

Nicht zu vergessen, dass man vorsichtig sein sollte was man davon wirklich frei im Internet offen legen möchte. Ist man an einen Hoster gebunden, so gibt es in der Regel keine Möglichkeit die Sichtbarkeit zumindest auf der dritten Ebene einzustellen. Es besteht aber durchaus die Möglichkeit, dass man für den internen Gebrauch die Auflösung selbst in die Hand nimmt und dann je nach anfragendem System eine entsprechende Antwort gibt. geheim.intern.meine-firma.de gibt dann nach außen hin bekannt nichts zu kennen, aus dem internen Netz befragt wird dem anfragenden System hingegen eine Antwort gegeben. Das Stichwort hierzu ist Split-Zone-Betrieb, was wieder ein Thema für sich ist.

Der Vollständigkeit halber gehe ich noch kurz darauf ein, wie ein Client sich ggf. die IP-Adresse eines Namens ermitteln kann. Im Regelfall erfolgt die Konfiguration heute automatisch, so dass man seitens seines Internetanbieters (ISP) mit zwei möglichen IP-Adressen zur Abfrage von DNS-Namen genannt bekommt. Diese sind normalerweise nicht verpflichtend, man kann seine Anfragen auch an andere DNS-Server richten. In der Regel stehen diese aber heute nicht mehr ganz so offen zur Verfügung, da man mit diesen Mechanismen auch Unfug anstellen kann und somit andere Systeme angreifen bzw. lahmlegen kann. Zusätzlich merken sich verschiedene Knotenpunkte auch die bereits abgefragten Domain-Namensauflösugen – allen voran meist das eigene Betriebssystem, danach in der Regel der Router und auch der DNS-Server des Providers hat einen Cache der abgefragten Domains. So sind schnellere Antworten möglich. Meist gibt sich der angesprochene DNS-Server dann als Client auf die Suche nach den entsprechenden Antwort oder gibt dem anfragenden System immerhin einen Hinweis wo es weiter fragen soll.

Im schlechtesten Fall landet die Anfrage bei einem der weltweit 13 root-Server (in Wirklichkeit steckt da noch etwas Lastverteilung dazwischen aber das würde hier zu weit führen). Diese verweisen dann auf einen oder mehrere zuständige DNS-Server für eine Toplevel-Domain. So würde die Abfrage nach www.meine-firma.de an einen zuständigen Server bei der DENIC (siehe oben) verwiesen, der kann dann wiederrum sagen wer denn nun für meine-firma.de Antworten liefern kann. Mit dieser Information bekommt der Client (oder auch der zwischengeschaltete DNS-Server des Providers oder der eigene Router) mit welche IP-Adresse zu befragen ist um www.meine-firma.de aufzulösen. Für tiefere Ebenen kann dann auch wieder an einen anderen Nameserver verwiesen werden, prinzipiell kann ein Nameserver auch für beliebig viele Subdomains Auskunft geben, das ist dann wieder eine Sache der Konfiguration. Zur Sicherheit hat man in der Regel mindestens zwei DNS-Server am Laufen, vorzugsweise sogar in getrennten Netzsegmenten, damit man Ausfälle kompensieren kann. Wird der erste Server nicht erreicht, wird ggf. der zweite befragt und sofern vorhanden auch der dritte.

Ich habe es bis jetzt absichtlich recht einfach gehalten und nur den klassischen Fall der Auflösung eines Namens zu einer IPv4-Adresse betrachtet. Damit sind schon einmal 80% der Anwendungsfälle abgedeckt. Technisch handelt es sich hierbei um eine Abfrage nach einem sogenannten A-Record (Adress-Datensatz), für IPv6 hat man sich auf die Konvention des AAAA-Typs (Quad-A-Record) geeinigt. Es gibt aber noch einige weitere Typen denen man immer wieder einmal begegnet und die jeweils einem recht speziellen Zweck dienen. So etwa der SOA-Record (Start Of Authoritiy) – dieser beinhaltet die Verwaltungsinformationen zu einer sogenannten Zone (nicht zu verwechseln mit einer Domain, auch wenn das häufig synonym gebraucht wird). Unter anderem ist dort der technische Ansprechpartner, die Time-To-Live, eine Serienummer und der zuständige Nameserver eingetragen). Diese Angaben benötigt das System um sich selbst zu organisieren (zum Beispiel um zu wissen wann man mal wieder nachfragen sollte ob die einmal abgefragte IP-Adresse noch immer zu einer Domain gehört oder ob diese sich ggf. geändert hat). Ebenfalls recht bekannt ist der sogenannte MX-Record (MailExchange) – dieser definiert den oder die zuständigen Mailserver für eine Domain. Über diesen Weg ermitteln die Mailserver an welche IP eine e-mail gerichtet werden sollen. Zudem auch immer einmal wieder sind Einträge mit TXT zu finden, diese enthalten nahezu beliebigen Text, unter anderem werden diese auch zur Prüfung von Mails auf Plausibilität / Glaubwürdigkeit / Spam hin verwendet, so wird in diesen Einträgen z.B. hinterlegt welche Server überhaupt Mails für eine bestimmte Domain verschicken dürfen.

Auch immer wieder im Zusammenhang mit DNS fällt das Stichwort DynDNS. Wie der Name schon sagt, hat das was mit DNS zu tun, allerdings eher mit einer Auswirkung auf das System denn direkt mit diesem. Normalerweise ändern sich die IP-Adressen einer Website eher selten, z.B. bei umfassenden Restrukturierungen / Modernisierungen oder beim Umzug zu einem anderen Hosting-Provider. Ganz anders sieht die Sache aus, wenn man an mobile Geräte denkt oder an Geräte deren IP sich häufig ändert oder ändern kann, der Klassiker bei einer Consumer-Internet-Anbindung – dort verteilt der Internet-Service-Provider bei jeder Neueinwahl auch eine neue IPv4 und wenn man Glück hat auch eine IPv6-Adresse (in diesem Fall in der Regel ein ganzes Subnetz). DynDNS beschreibt nunmehr ein Verfahren, dass es ermöglicht die geänderte IP-Adresse automatisch mitzuteilen und die Namensauflösung umzustellen. Anbieter sind hier unter anderem no-ip.com oder dyndns.org.

Insgesamt könnte ich hier wohl noch einige weitere Seiten Text zum DNS herunter schreiben, das Thema ist recht vielschichtig, fürs erste sollte dieser Überblick aber einmal ausreichen. Sollte der Wunsch bestehen, das ein oder andere Thema nochmals tiefergehend zu beschreiben, einfach einen Kommentar hinterlassen, dann schaue ich mal was ich machen kann.