In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

Domains und die Technik dahinter (DNS) sind Grundelemenete des Internets - ohne sie wäre TCP/IP eigentlich in der Praxis unbrauchbar.

Wir kennen TCP/IP inzwischen. Und auch, wie zwei Rechner mittels IP-Routing miteinander kommunizieren können. Aber nicht mal wir ITler haben Freude daran, im Browser IP-Adressen einzugeben. Nicht nur, dass man sich die nicht merken kann, wir haben auch zu wenig davon: Ein Server hat meist nur wenige IP-Adressen, aber betreibt vielleicht tausende Websiten und braucht den aufgerufenen Domainnamen, um zu erkennen, welche da aufgerufen werden soll.Dafür braucht man Domain-Namen und DNS.

Ein Hostname (also ein vollständiger Servername, z.B. www.vollzeitnerd.de, korrekt als FQDN full qualified domain name bezeichnet) besteht aus drei Bestandteilen:

• der TopLevel-Domain ("Domainendung"), in diesem Fall "de"
• Dem registrierten Domainnamen (vollzeitnerd.de)
• Und innerhalb der Zone dieses Domainnamens dann die Subdomain. Auch "www." ist eine Subdomain, auch wenn es gemeinhin nur mit "vollzeitnerd.de" gleichgesetzt wird.

Subdomains kann es in fast beliebigen Hierarchien geben (server17.muenchen.beispielfirma.de, ftp.server98.koeln.beispielfirma.de, ...).

Bei den TopLevel-Domains unterscheiden wir zwischen:

Bei den Domainendungen unterteilt man grob in

• CountryCode TLD (ccTLD), wie z.B. "de", die als Domainendung einem konkreten Land zugewiesen wurde (dazu gehört auch "eu" für die europäische Union), diese sind i.d.R. zweistellig und
• generische TLDs (generic TLD oder gTLD), die i.d.R. mindestens dreistellig sind

Bei den ccTLDs gibt es einige, die auch mal zweckentfremdet werden, z.B. ".it" (Italien / IT-Firmen) oder ".ag" (Antigua / Aktiengesellschaft), aber das ist dann eben einfach eine ausländische Registrierung (genauso wie auch jede ausländische Firma eine .de-Adresse registrieren kann). Trotzdem sind das Ländercodes. Und einige Ländercodes sind dann nochmal unterteilt (in UK z.B. haben kommerzielle Webseiten die Endung .co.uk, Behörden .gov.uk usw.)

Bei den gTLDs gibt es die klassischen (angefangen hat es mit CNOBI: .com, .net, .org, später dann noch .biz und .info), heute gibt es für jeden Unsinn eine gTLD. Zu den gTLDs gehören auch Endungen wie .berlin oder .koeln, die zwar regionalen Bezug haben, aber eben keine offizielle Länderzuteilung sind. 

Den Domain-Namen bekommt man über seinen Provider bei der zuständigen Registry (Vergabestelle), bei .de ist das die DENIC. Die verteilen die Domains (in der Regel nach dem Schema "first come first serve") an jeden, der die haben möchte.

Zu dem Domainnamen - z.B. vollzeitnerd.de - sind bei der DENIC folgende Angaben hinterlegt:

• Der Domain-Inhaber (owner-c), dem "gehört" die Domain. Er wird vertreten durch einen administrativen Ansprechpartner (admin-c), bei einer privaten Domain wie dieser hier sind die i.d.R. gleich; bei einer geschäftlichen Domain ist oftmals der Domaininhaber = die Firma (z.B. GmbH) und dann muss der admin-c eine natürliche Person sein. Beide sind einerseits im bestimmten Rahmen verantwortlich für Unsinn, der mit der Domain gemacht wird, aber auch bevollmächtigt, die Domain löschen/umschreiben/transferieren zu lassen.
• Ein technischer Ansprechpartner (tech-c) für die Server rund um diese Domain, und ein Zonenverwalter (zone-c) für die Nameserver, auf denen diese Domain liegt. Die sollen bei Störungen eine Kontaktaufnahme der Provider untereinander vereinfachen
• Die Nameserver, dazu gleich mehr, plus ggf. public keys für deren Signatur (DNSSEC)
• Das DENIC-Mitglied (=der Provider, ggf. auch der Großhändler eines Providers), über das die Abrechnung läuft

Bei anderen Domain-Endungen sind die Parteien u.U. andere, das Grundprinzip ist aber das gleiche.

Will man den Provider wechseln, macht man einen Domain-Transfer. Früher war der Ablauf komplett anders und hieß "Konnektivitäts-Koordination", aus der Zeit nutzen manche heute immer noch den Begriff KK-Antrag. Der aktuelle Ablauf ist aber folgender:

• Der Domain-Inhaber erfragt sich bei seinem Provider die sog. AuthInfo, auch AuthCode genannt. Das ist ein Provider-Wechsel-Passwort.und hat, nachdem es bei der DENIC angelegt wurde, eine Gültigkeit von 30 Tagen. 
• Jetzt beauftragt er beim neuen Provider den Transfer der Domain unter Vorlage der AuthInfo. Der neue Provider fragt das per Schnittstelle bei der DENIC an, und entweder das klappt, oder es klappt nicht (z.B. AuthInfo abgelaufen).
• Sofern das klappt, kann der Provider im nächsten Schritt (meist im gleichen Atemzug, aber technisch sind es getrennte Aufträge) auch die Daten per UPDATE ändern. Den owner-c/admin-c trägt er neu ein (idealerweise mit den gleichen Daten ... aber dank DSGVO kann der neue Provider die Daten nicht beim alten Provider oder der DENIC abrufen, also muss der Kunde sie ihm mitteilen und er setzt sie dann selbst neu). Als tech-c/zone-c trägt er sich in der Regel selbst ein. Und als Nameserver dann üblicherweise seine eigenen.
• Und sofern auch das geklappt hat, ist die Domain technisch umgezogen. Falls dieses UPDATE schief gelaufen ist (z.B. weil die DENIC die Nameserver als "nicht autoritativ" ablehnt, siehe unten), dann wäre die Domain kaufmännisch trotzdem umgezogen (wird also über den neuen Provider bezahlt), aber technisch noch vom alten Provider/dessen Nameserver abhängig.
• Die DNS-Änderung bei der DENIC kann noch ein paar Minuten dauern, außerdem ist DNS ja ohnehin träge, aber grundsätzlich sollte man am gleichen Tag noch den Umzug auch technisch bemerken.

Falls der Domain-Inhaber sich mit seinem Provider nicht verträgt, ihn nicht erreicht oder ihn nicht kennt, kann auch auch die AuthInfo2 beantragen. Diesen Antrag kann jedes beliebige DENIC-Mitglied auslösen (das kann der neue Provider sein, aber auch manche andere Provider bieten als Neben-Einnahme AuthInfo2 an), das kostet um die 15 Euro. Die DENIC schickt dann an den Domaininhaber (owner-c) per Brief die AuthInfo2 zu, der Rest bleibt gleich.

Das oben beschriebene Verfahren gilt so für .de-Domains. Bei anderen Domain-Endungen ist das Verfahren ähnlich, jedoch:

• Bei manchen Domain-Endungen muss der Domain-Inhaber (admin-c) noch in einer vollautomatischen Mail per Klick dem Transfer zustimmen
• Manche Domain-Endungen (bzw. deren Vergabestellen, die sog. Registries) haben de Möglichkeit, die Domain gegen (böswillen) Transfer zu sichern, die Domain hat dann sozusagen als Kindersicherung den Status "clientTransferProhibited". Sobald man bei seinem Provider die AuthInfo erfragt, sollte der diese Sicherung rausnehmen ... aber gerade bei kleineren Providern oder selteneren Domain-Endungen wird sowas immer mal wieder vergessen
• Manche Registry hat darüber hinaus noch systemseitige Regeln/Sperren (z.B. 60 Tage nach Registrierung oder Inhaberwechsel ist kein Domaintransfer erlaubt oder so). 

Kündigt ein Kunde irgendwo, ohne die Domain wegzuziehen (weil der den Transfer vergessen hat, der nicht geklappt hat, oder weil er gar nicht dran gedacht hat, was mit der Domain passieren soll), dann darf der Provider die ohne ausdrücklichen Auftrag des Kunden nicht löschen (denn die Registrierung selbst ist vertraglich eine Sache zwischen DENIC und Inhaber). Er will sie aber auch nicht mehr bezahlen, also klinkt er sich aus dem bisherige Dreiecks-Verhältnis DENIC-Provider-Inhaber aus und schickt die Domain in den Transit (sozusagen gibt er sie der DENIC zurück mit den Worten "hier, ist Euer Domaininhaber, klärt ihr das").

Der Inhaber bekommt dann ein Schreiben von der DENIC mit einem Passwort zum Transit-Portal, wo er

• dann online der Löschung zustimmen kann
• oder sich eine AuthInfo geben lassen kann für den Transfer der Domain

Ignoriert er dieses Schrieben, wird er automatisch Kunde bei "DENICdirekt" zu Preisen, die keiner bezahlen will (da die DENIC ja per Satzung gar kein Endkundengeschäft machen soll, sind die Preise entsprechend abschreckend), und die auch keiner bezahlen muss (sobald der Inhaber sich irgendwie um die Domain gekümmert hat, verzichtet die DENIC auch auf ihre Rechnung).

Etwas vergleichbares zum Transit gibt es bei anderen Domain-Endungen üblicherweise nicht.

Die technisch wichtigste Angabe bei der Domain sind die Nameserver (bei den meisten Registrys werden aus Redundanz-Gründen zwei verlangt). Die verwalten das Zonenfile dieser Domain. Wie das genau abläuft, ist im Kapitel DNS beschrieben, aber kurz gesagt: Die DENIC leitet alle Anfragen rund um diese Domain einfach an diese beiden Nameserver weiter, und die beauskunften dann die dahinterliegenden IP-Adressen.

Die DENIC prüft bei der Registrierung, als auch bei einem UPDATE (z.B. nach einem Providerwechsel), ob die (mindestens zwei) hinterlegten Nameserver diese Domain auch wirklich kennen und sich laut Antwort für zuständig halten und sich auch gegeseitig in ihrer Zuständigkeit bestätigen. Schlägt das fehl, wird das Update abgelehnt (s.o., beim Transfer wäre die Domain dann kaufmännisch, aber nicht technisch umgezogen), bzw. bei einer Neuregistrierung wäre die Domain dann "registriert, aber nicht konnektiert" (=vergeben, aber unbenutzbar) und man hat 30 Tage Zeit, die Domain "zu reparieren".

Zur Kontrolle, ob die DENIC sich mit der Antwort der eigenen Nameserver zufrieden gibt, gibt es das "Nameserver Predelegation Check Webinterface NAST".

Bei anderen Domain-Endungen gibt's sowas üblicherweise nicht, den meisten Registries ist völlig egal, was man hinterlegt.

Wo wir gerade bei Nameservern sind, noch zwei Besonderheiten:

1. Die DENIC erlaubt auch, statt zweier Nameserver eigene DNS-Einträge zu setzen (dann spart man sich den eigenen Nameserver und nutzt die der DENIC)
2. Die DENIC (und die meisten anderen Registrys auch) erlauben sog. glue-Records. Ein Glue-Record ist immer dann nötig, wenn Du z.B. als Provider bei der Domain "coolerprovider3000.de" als Nameserver den "dns01.coolerprovider3000.de" und den "dns02.coolerprovider3000.de" hinterlegen willst (weil das nun mal für alle Deine Domains die richtigen Nameserver sind). Wenn Du die Grundlagen von DNS schon kennst, dann ist klar: Man kann nicht als "Erreichbarkeitshilfe" für eine Domain einen Server innerhalb dieser Domain angeben. Wenn Du noch nie wusstest, wo ich wohne, dann bringt es Dir wenig, wenn ich als Wegbeschreibung "300m neben der alten Wohnung" sage, oder? Für diesen Fall kann man direkt die IP-Adresse von dns01.coolerprovider3000.de und dns02.coolerprovider3000.de im gleichen Atemzug mit angeben, damit man einen ersten Anhaltspunkt bei der Suche hat.

Wenn ich eine Domain registriere, in der ein Firmenname vorkommt, dann ist das evtl. ein Verstoß gegen das Markenrecht. Der DENIC ist das erstmal egal, das wird nicht geprüft. Wenn jetzt der Inhaber der Marke dagegen vorgehen will, kann er sich bei der DENIC meine Domain-Inhaberdaten geben lassen (die DSGVO verbietet das öffentliche sog. WHOIS, also die öffentliche Abfragemöglichkeit. Aber bei berechtigtem Interesse gibt die DENIC die Daten raus). Und dann kann er auf dem Rechtsweg gegen mich vorgehen.

Sobald ich merke, dass der Markeninhaber das tut, könnte ich die Domain auf meinen Bruder umschreiben (in dem ich meinen Provider einfach bitte, die Inhaberdaten zu ändern). Und dann schreibe ich dem Markeninhaber einfach "sorry, ich weiß nicht, was Du von mir willst, die Domain gehört mir gar nicht mehr", und er muss von vorne anfangen. Und dieses Spielchen können mein Bruder und ich beliebig oft wiederholen.

Und da kommt jetzt der DISPUTE-Eintrag ins Spiel: Der Markeninhaber beantragt für diese Domain bei der DENIC einen DISPUTE-Status. Die DENIC prüft oberflächlich, ob der Markeninhaber Recht haben könnte (ein endgültiges Urteil ist Aufgabe der Gerichte). Und danach sperrt sie die Domain erstmal eine Jahr lang (der DISPUTE-Eintrag kann dann erneuert werden, wenn der Markeninhaber nachweist, dass er die Sache juristisch zu klären versucht) gegen Inhaberwechsel. Ich kann mit der Domain also technisch alles machen, nur mich nicht meiner Verantwortung entziehen. (Und falls ich die Domain lösche, fällt sie automatisch dem Markeninhaber zu).

Wenn ich meine Domain lösche, dann ist sie frei verfügbar. In den Anfängen des Internets kamen böse Domaingrabber auf die Idee, freiwerdende Domains direkt weg-zu-registrieren. Auch, wenn der Domaininhaber sie unwissentlich hat frei werden lassen (bei anderen Domain-Endungen genügt dafür u.U. eine unbezahlte Rechnung - bei .de nicht, siehe TRANSIT) oder wenn er sich der Tragweite einer Fehlentscheidung nicht bewusst war. Und gehörte die Domain danach erstmal jemand anderes, wurde der Rückkauf teuer.

Um das zu unterbinden, haben einige Registries - seit einigen Jahren auch die DENIC - die sog. Redemption Period eingeführt. Wird eine Domain gelöscht (CLOSE), landet sie danach 30 Tage lang in einer Limbus, in dem sie nicht mehr genutzt werden kann, aber noch auf den Inhaber eingetragen ist. Und innerhalb dieser Zeit könnte der Inhaber sie über seinen Provider wiederherstellen lassen. Erst danach wird sie frei verfügbar.

In den Anfängen des Internets hat sich niemand über Umlaute Gedanken gemacht. Und irgendwann war die Technik "fertig", und es wäre unmöglich gewesen, Domain namen mit einem ü zu schalten. DNS, E-Mail, WWW, überall hätte man Millionen von Serverkomponenten aktualisieren müssen, wenn irgendwelche Sonderzeichen erlaubt wären, die früher keiner kannte.

Darum wurden 2003 die "IDN-Domains" eingeführt, seit dem 01.03.2004 ist das bei .de-Domains z.B. möglich. IDN ist eine "optische Täuschung",  die auf einem extra dafür entwickelten internationalen Standard basiert:

Die Punycode-Schreibweise

Die Domain "müller.de" z.B. gibt es in Wahrheit gar nicht - Sie werden im Internet keinen Name-, Mail- oder Web-Server finden, der mit "müller.de" etwas anfangen kann. Statt dessen gibt es zu "müller.de" eine festgelegte Übersetzung in sog. ACE-(Punycode-)Schreibweise, nämlich "xn--mller-kva.de". Dass es sich hierbei um die Übersetzung einer IDN-Domain handelt, erkennt man an den beiden Bindestrichen an dritter und vierter Stelle - diese waren nämlich aus genau diesem Grunde bereits einige Zeit vorher schon nicht mehr bei "normalen" Domains erlaubt, um diesen Raum für übersetzte IDN-Domains freizuhalten. Einfach gesagt enthält der mittlere Teil (mller) den Teil des Domainnamens, der keine Umlaute enthält, und in dem vorderen und hinteren Teil (xn und kva) ist codiert eingearbeitet, an welche Stelle welcher Umlaut gehört.

Wenn man jetzt also "müller.de" registrieren will, registriert man in Wirklichkeit xn--mller-kva.de. Wenn man "müller.de" im Kundenmenü eines Providers konfiguriert, konfiguriert man in Wirklichkeit xn--mller-kva.de - und wenn jemand www.müller.de aufruft oder eine Mail an peter@müller.de schickt, rufen er in Wirklichkeit www.xn--mller-kva.de auf bzw. schickt an peter@xn--mller-kva.de. Bei der Domainregistrierung sorgt dann das Registrierungssystem dafür, dass man glaubt, man würde müller.de registrieren, bei der Konfiguration im Kundenmenü seines Providers wird die Schreibweise "müller.de" angezeigt (obwohl es im Hintergrund etwas anderes ist) und wenn man die Adresse www.müller.de im Browser eintippt, übersetzt dieser das in xn-mller-kva.de und bringt einen zur richtigen Webseite.

Damit diese "optische Täuschung" funktioniert, müssen alle Systeme, die mit der Schreibweise müller.de konfrontiert werden, diese auch übersetzen können - d.h. auch peter@müller.de anzeigen, obwohl die Mail in Wirklichkeit den Absender peter@xn--mller-kva.de hat, und www.xn--mller-kva.de aufrufen, obwohl man in Wirklichkeit www.müller.de eingetippt habt.

Im Bereich WWW, wofür es primär entwickelt wurde, funktioniert das sehr gut, alle aktuellen Browser und so ziemlich jeder Hosting-Provider und jedes Control-Panel kommt damit klar.

Sonderfall: ß

Neben der vorgenannten Erklärung gibt es rund um den Buchstaben ß noch einen Sonderfall, hier wurde der entsprechende Standard nachträglich erweitert.

• Von März 2004 bis September 2010 war bei der DENIC die Registrierung von Umlaut-Domains mit dem Buchstaben ß nicht möglich. Statt dessen wurde der Domainname bei der Eingabe im Browser normalisiert, aus dem ß wurde ein ss. Gibt man www.fußball.de in seinen Browser ein, macht dieser daraus www.fussball.de und ruft die passende Domain direkt auf.
• Seit Oktober 2010 erlaubt die DENIC entsprechend dem überarbeiteten Standard auch Domains mit einem ß. fußball.de ist daher eine eigenständige Domain und hat nichts mit fussball.de zu tun.
• Aber: Neben der DENIC müssen natürlich auch die Browser dem überarbeiteten Standard folgen. Inzwischen dürfte das wohl der Fall sein.
• Generell gilt: Registrieren sollte man eine Domains immer in allen denkbaren Schreibweisen. Wer auf eine Marke mit ä Wert legt, registriert sich am besten auch die ae-Schreibweise, bei Domains mit ß auch die ss-Schreibweise usw.!

IDN-Domains und Mails

Während es auf dem Browsermarkt eigentlich mit allen großen Browsern kein Problem ist, IDN-Websites zu besuchen, sieht die Sache bei Mails ganz anders aus:

Erstes Problem ist ein großer Irrtum: Die Punycode-Schreibweise betrifft nur den Domainnamen, nicht den Benutzernamen (also den Teil vor dem @). peter@müller.de kann also seinen Namen in Zukunft mit Umlaut schreiben, seine Frau Bärbel muss aber bei baerbel@müller.de bleiben, denn vor dem @ sind weiterhin keine Sonderzeichen erlaubt.

Zweites Problem ist die mangelnde Unterstützung: IDN-fähige Mail-Programme sind noch vergleichsweise selten - und während man normalerweise nur einen Browser benutzt (d.h. es kein großes Problem wäre, diesen auf eine neue IDN-fähige Version upzudaten), ist Mail viel verbreiteter: WebMail, Smartphone, Software mit automatischem Mail-Versand.

Drittes Problem ist die Script-Unterstützung: Auf wie vielen Webseiten haben Sie schon Ihre Mail-Adresse eingegeben - zum Versand von Grußkarten, zur Anmeldung mit Zusendung Ihres Passwortes u.v.a.m. - auch diese müssten alle (sofern Sie nicht peter@xn--mller-kva.de als Mail-Adresse eintragen wollen) auf IDN-Fähigkeit umgeschrieben werden.

Insgesamt sind IDN-Domains für Mail-Verkehr also nicht geeignet.