Neue Top-Level-Domain .self soll Self-Hosting salonfähig machen

34.050 US-Dollar Mindestgebühr, ein vollständiger DNS-Infrastrukturnachweis und eine monatelange Bewerbungsrunde: So teuer ist der Versuch, das Domain Name System für die Dezentralisierung zu öffnen. Die Human-Centered Computing Foundation (HCCF) hat diesen Weg eingeschlagen und bewirbt sich bei ICANN um die neue generische Top-Level-Domain .self — reserviert ausschließlich für selbstgehostete Dienste und persönliche Server.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Das Wichtigste in Kürze

• Die HCCF ist genehmigter Teilnehmer im ICANN Applicant Support Program (ASP) und damit formal der günstigste Kandidat für eine gTLD-Bewerbung.
• Technisch gibt es zwei Wege: .self als öffentliche ICANN-gTLD oder als Special-Use-Domain analog zu .onion — mit sehr unterschiedlichen Erreichbarkeits-Konsequenzen.
• DSGVO-Artikel 44 ff. und der US CLOUD Act machen Self-Hosting im DACH-Raum zur ernst zu nehmenden Compliance-Option.
• Der Vorschlag befindet sich in einem frühen Stadium: Eine eigene .self-Domain ist 2026 noch nicht verfügbar.

Was ICANN mit einer TLD-Bewerbung wirklich verlangt

Neue generische Top-Level-Domains entstehen nicht durch Petition, sondern durch ein formalisiertes ICANN-Bewerbungsverfahren. Die zweite offizielle Runde hat vom 30. April bis 12. August 2026 gelaufen und hat neben umfangreicher technisch-organisatorischer Dokumentation eine Grundgebühr von mindestens 34.050 USD verlangt — das ist der ASP-reduzierte Satz, den die HCCF als genehmigter Teilnehmer in Anspruch nehmen kann. Zusätzlich muss jeder Antragsteller als Registry-Betreiber volle DNS-Infrastruktur nachweisen. Kein bürokratisches Detail: Scheitert dieser Nachweis, ist die Bewerbung ungültig, unabhängig vom ideellen Konzept dahinter.

Technisch stehen der HCCF zwei Pfade offen. Entweder gelingt die Delegation von .self als echte gTLD im öffentlichen DNS-Root — dann ist die Domain global erreichbar, aber der Prozess dauert Jahre. Oder .self wird als Special-Use-Domain analog zu .onion per RFC-Prozess bei IANA reserviert, ohne im öffentlichen Root zu erscheinen. Dieser zweite Weg wäre schneller realisierbar, schränkt aber die globale Erreichbarkeit strukturell ein: Gängige Browser lösen solche Domains nur auf, wenn ein interner Resolver sie kennt.

Was .onion lehrt — und warum Community-TLDs fast immer scheitern

Das einzige erfolgreiche Vorbild ist .onion: RFC 7686 hat 2015 eine community-getriebene Pseudo-TLD nachträglich als Special-Use-Domain über das IETF standardisiert — gerade weil ICANN ab 2012 neue gTLDs kommerziell vergeben hat und informelle Pseudo-Domains dadurch kollisionsgefährdet wurden. Dieser Präzedenzfall zeigt den realistischeren Pfad für .self. Strukturähnliche Dezentralisierungsansätze existieren bereits: Die IndieWeb-Bewegung nutzt persönliche Domains als Identitätsanker, das Fediverse setzt auf konventionelle Domains ohne eigene TLD. Beide zeigen, dass Self-Hosting auch ohne eigene TLD skaliert — was gleichzeitig die Frage aufwirft, ob .self überhaupt notwendig ist oder primär ein Signal setzt.

Für die Erreichbarkeit ist Browser-Unterstützung entscheidend. HTTP-Clients lösen nur Domains auf, die im öffentlichen DNS-Root delegiert sind — oder für die ein lokaler Resolver konfiguriert wurde. Ohne diese Grundlage bleibt eine Special-Use-Domain ein Intranet-Konzept. Wer den Self-Hosting-Gedanken in der Praxis umsetzt, kommt an DNS-Konfiguration nicht vorbei, TLD hin oder her. Wie Betreiber heute schon die Kontrolle über Crawler und Sichtbarkeit behalten, zeigt etwa der Dr.-Web-Artikel zu robots.txt und KI-Scrapern — ein Thema, das Self-Hoster direkt betrifft.

Was DACH-Entscheider jetzt konkret tun können

DSGVO-Artikel 44 ff. verbietet die Übermittlung personenbezogener Daten in Drittstaaten ohne angemessenes Schutzniveau. Der US CLOUD Act erlaubt US-Behörden theoretisch den Zugriff auf Daten US-amerikanischer Cloud-Anbieter — unabhängig vom physischen Serverstandort. Beide Regelwerke zusammen erzeugen im DACH-Raum einen strukturellen Druck Richtung Self-Hosting, den Gaia-X als europäische Infrastrukturinitiative institutionell untermauert. Eine eigene .self-Domain braucht niemand dafür.

Drei Maßnahmen sind sofort umsetzbar: Zunächst eine SaaS-Substitutionsanalyse durchführen — Nextcloud statt Google Drive, Gitea statt GitHub, Vaultwarden statt LastPass sind DSGVO-konforme On-Premise-Alternativen mit überschaubarem Betriebsaufwand. Dann die ICANN-Bewerbungsliste für die 2026-Runde beobachten, um zu prüfen, ob .self oder vergleichbare Community-TLDs dort formal gelistet werden. Außerdem interne DNS-Resolver so konfigurieren, dass lokale Self-Hosting-Projekte bereits heute über interne Pseudo-Domains wie *.intern oder *.home erreichbar sind — unabhängig vom Ausgang des ICANN-Verfahrens.

Welche Hosting-Optionen dabei als Fundament taugen, zeigt der Dr.-Web-Webhosting-Vergleich. Für den breiteren Kontext, wie Datensouveränität und digitale Sichtbarkeit zusammenhängen, lohnt ein Blick auf die GEO-Analyse von Dr. Web und die SEO-Grundlagen. Wer verfolgt, wie KI-Systeme Inhalte indexieren und welche Stellschrauben Betreiber haben, findet im Artikel zu llms.txt und Google Lighthouse sowie zum Datenschutz bei Cloudflare Turnstile praktische Einordnungen. Auch die Entwicklung von Agentic Search und deren Konsequenzen für dezentrale Infrastruktur bleibt ein Thema, das Self-Hoster im Blick behalten sollten.

Der .self-Vorschlag ist heute vor allem ein Diskussionsbeitrag. Ob daraus eine TLD wird, entscheidet ICANN — und das dauert. Die Datensouveränitätsfrage stellt sich im DACH-Raum unabhängig davon bereits jetzt.

Mehr Newshunger?

• KI-Scraper stoppen mit robots.txt? So geht’s.
• WP Engine sperrt KI-Crawler: Kunden tappen im Dunkeln
• Google Lighthouse prüft llms.txt: Müssen Sie handeln?
• Wird Agentic Search zum Sargnagel klassischer SEO?
• Reicht lokale SEO in der KI-Suche noch aus?
• Google Preferred Sources: Klick-Verdoppler?
• Entscheidet das KI Ranking über Ihre Sichtbarkeit?