Am 29. September tagte online der 15. Registration Operations Workshop. Am dringendsten war ein Zertifikatsproblem: Viele öffentliche Zertifizierungsstellen stellen Webserver-Zertifikate nicht mehr mit der Client-EKU aus, die manche EPP-Implementierungen verlangen. Dazu kamen Transfercodes aus der Registry, S/MIME für Streitbeilegungsverfahren sowie ein neuer Delegationstyp im DNS.
Den Workshop, kurz ROW, gibt es seit 2014. Er behandelt die Technik hinter der Domainregistrierung. Dazu gehören EPP, über das Registrare Domains bei der Registry anlegen, die Abfrage per RDAP und DNSSEC. Sponsoren sind Verisign, ICANN und die kanadische Registry CIRA. In vier Stunden gab es zehn Vorträge. Die Teilnehmerzahl lag in der Spitze bei rund 110 Personen, Vortragende eingeschlossen.
EPP hängt an einer Regel für Browser
Zaid AlBanna von Verisign stellte das dringendste Problem vor. EPP-Verbindungen zwischen Registrar und Registry werden mittels Mutual TLS abgesichert. Dabei weist sich auch der Registrar mit einem Zertifikat aus. Viele nutzen dafür Zertifikate öffentlicher Zertifizierungsstellen mit einem Merkmal für die Client-Authentifizierung, der sogenannten Client-EKU.
2025 kündigte Google an, die Zertifikatshierarchien im Chrome Root Store schrittweise auf die Serverauthentifizierung zu beschränken. Webserver-Zertifikate aus diesen Hierarchien, die ab dem 15. März 2027 ausgestellt werden, dürfen nur noch die Server-EKU enthalten. Auch im CA/Browser Forum wird über eine stärkere Trennung der Verwendungszwecke diskutiert. Laut AlBanna bieten die meisten Zertifizierungsstellen solche Zertifikate nicht mehr an. Manche Software, etwa Java-Bibliotheken, prüft das Merkmal jedoch. Fehlt es, scheitert die Verbindung.
Ein Entwurf von AlBanna, James Gould und Scott Hollenbeck beschreibt vier Auswege. Die IETF-Arbeitsgruppe REGEXT prüft, ob sie ihn übernimmt. Kurzfristig ist es am wahrscheinlichsten, dass Registries das Merkmal nicht mehr prüfen. Registrare könnten Zertifikate bei den wenigen Anbietern kaufen, die es noch gibt. Registries könnten eine eigene Zertifizierungsstelle betreiben. Wer das schon tut, ist nicht betroffen. Oder Registries akzeptieren selbstsignierte Zertifikate, gegebenenfalls zusätzlich durch TLSA-Einträge im DNS abgesichert. AlBanna rechnet mit einer Kombination in mehreren Schritten.
.se vergibt die Transfercodes selbst
Bei .se und .nu legt der Registrar den Code für einen Transfer nicht mehr selbst fest. Eric Skoglund vom schwedischen Internetstiftelsen nannte die Gründe. Manche Codes waren schwach, manche wurden mehrfach verwendet, andere wurden von Kunden selbst gesetzt. Die Codes liefen nie ab. Und die Registry wusste nicht, wie Registrare sie speichern.
Heute schickt der Registrar nur noch „auto“, die Registry erzeugt den Code. Er enthält Endung, Ablaufdatum, Registrar und eine Zufallskennung und gilt 14 Tage lang. Das System läuft seit zwei Jahren. Die Registrare hätten positiv reagiert, sagte Skoglund. Der Support erkennt auf einen Blick, ob ein Code abgelaufen ist oder ob er zu .nu statt zu .se gehört. Ähnlich arbeiten laut Skoglund bereits .dk, .be und .eu.
S/MIME soll PGP im URS ablösen
URS- und UDRP-Verfahren können zur Sperrung oder Übertragung von Domains führen. Die erforderlichen Anweisungen der Streitbeilegungsanbieter an Registries und Registrare werden per E-Mail übermittelt. Für das URS schreibt ICANN eine OpenPGP-Signatur vor. Für die UDRP gibt es keinen vergleichbaren Schutz. Gavin Brown von ICANN berichtete, dass OpenPGP von Haus aus kaum ein Mailprogramm beherrscht. Zudem will GnuPG den aktuellen Standard RFC 9580 nicht umsetzen.
ICANN testete deshalb von Juni bis August das S/MIME-Verfahren mit Registries, Registraren und Streitbeilegungsanbietern. Ergebnis: Es funktioniert, Zertifikate lassen sich in Minuten erhalten, und Mailprogramme zeigen die Signatur klar an. Brown nannte aber Grenzen. Manche Zertifizierungsstellen generieren den privaten Schlüssel selbst und senden ihn per E-Mail. S/MIME schützt die Betreffzeile nicht. Domainnamen gehören deshalb nicht hinein. SPF, DKIM und DMARC seien bei UDRP-Anbietern und Registraren sehr unterschiedlich umgesetzt.
ICANN plant, die technischen Vorgaben für das URS beim Übergang zu S/MIME zu ändern. Geprüft wird auch, ob sich das Verfahren für die UDRP eignet. Der Testbericht soll bald erscheinen.
Sieben Registrare nehmen die Hälfte des Neugeschäfts
Der Autor dieses Beitrags hat auf dem Workshop selbst einen Vortrag gehalten. Grundlage waren die monatlichen Transaktionsberichte, die ICANN für jede generische Endung veröffentlicht. Ausgewertet wurden acht Endungen von Januar 2023 bis Dezember 2024, darunter .com, .net und .org. Sie deckten im ersten Quartal 2025 rund 87 Prozent aller gTLD-Registrierungen ab. Die Akkreditierungen wurden auf 676 Betreiber zusammengefasst.
Sieben davon, also 1 Prozent, verarbeiteten 51,9 Prozent aller Neuregistrierungen und eingehenden Transfers. Die obersten zehn Prozent kamen auf 92,6 Prozent. 116 Betreiber verzeichneten in zwei Jahren jeweils weniger als zehn Zugänge und Abgänge. Die Hälfte der 466 Millionen Transaktionen waren Verlängerungen. Für 2025 stieg der Anteil der obersten zehn Prozent auf 94,7 Prozent. Die vier im Jahr 2025 neu erteilten Akkreditierungen ergaben insgesamt rund 300 Zugänge.
Die Pflichten aus ICANNs Registrarvertrag gelten weitgehend unabhängig von der Größe eines Registrars. Andere EU-Regelwerke kennen dagegen größen- oder risikobasierte Abstufungen, etwa der Digital Services Act. Die Studie ist in IEEE Access erschienen, Daten und Code sind frei verfügbar.
DELEG soll die NS-Einträge ergänzen
Duane Wessels von Verisign stellte DELEG vor, einen neuen Eintragstyp für Delegationen im DNS. Die heutigen NS-Einträge werden in der übergeordneten Zone nicht mit DNSSEC signiert. Sie stehen in zwei Zonen und können auseinanderlaufen. DELEG soll das beheben und lässt sich um weitere Angaben erweitern. Ein separater Entwurf sieht etwa Angaben zu verschlüsselten Verbindungen vor. Eine Delegation kann dann auch direkt auf IP-Adressen zeigen oder auf einen Eintrag beim DNS-Anbieter verweisen.
Der Kernentwurf wurde im Mai 2025 von der IETF-Arbeitsgruppe DELEG übernommen. Einen zweiten Working-Group-Last-Call erwartet Wessels Ende 2026. Erste Umsetzungen gibt es in BIND, Knot DNS und einem Akamai-Resolver. Die Erweiterungen für EPP und RDAP sind dagegen erst Entwürfe. Verisign bat, ihr Interesse zu melden.
Außerdem
- .lk stellte im Juli und August 2025 von RSASHA1 auf ECDSA um. Chathranga Wijekoon beschrieb, wie die Registry den Wechsel in einem Nachbau des DNS mit eigener Root probte. Zuerst stellte sie ihre tamilische Endung .இலங்கை um. Am 4. August 2025 wurde der DS-Eintrag in der Root-Zone geändert.
- Alternative Namenssysteme: Andrew Sullivan stellte den Bericht der Technical Study Group vor. Eine gTLD mit einem Namen außerhalb des DNS zu verknüpfen, könne sicher sein. Voraussetzung seien dieselbe Zeichenfolge und dieselbe Kontrolle in beiden Systemen. Zudem dürfe niemand sonst die Zeichenfolge in einem der Systeme nutzen. Sullivan zufolge soll am 5. Oktober eine weitere öffentliche Kommentierung beginnen.
- Fehlermeldungen im DNS: Willem Toorop von NLnet Labs und Scott Hollenbeck warben für RFC 9567. Resolver melden damit Fehler wie abgelaufene DNSSEC-Signaturen automatisch an einen Meldedienst, den der Nameserver angibt. BIND, Knot DNS und Unbound unterstützen das, NSD ab Version 4.15.4, die Mitte Oktober erscheinen soll.
- DNSSEC gegen Quantenrechner: Swapneel Sheth und Joseph Harvey von Verisign zeigten Merkle-Tree-Ladders. Eine quantensichere Signatur mit ML-DSA-44 ist 2.420 Byte groß, eine heutige ECDSA-Signatur 64 Byte. Mit dem Verfahren reicht eine einzige Signatur für viele Einträge. In Tests mit echten TLD-Zonen halbierte sich die Zonengröße gegenüber reinem ML-DSA-44 noch weiter. Das Signieren dauerte ein Viertel der Zeit.
- RPKI: Brad Gorman von ARIN meldete einen Meilenstein: Am 3. September waren erstmals eine Million Präfixe per RPKI gültig. Zuletzt lag der Anteil bei knapp 72 Prozent. Die nächste Stufe namens ASPA wollen alle fünf Regional Internet Registries bis Ende 2026 unterstützen.
Quellen
- Registration Operations: ROW15, 29. September 2026
- ROW15: Programm
- Google: Chrome Root Program Policy
- CA/Browser Forum: Minutes of the F2F Meeting 67, 11. März 2026, Discussion of clientAuth
- IETF: draft-albanna-regext-eku-mtls-in-epp, Extended Key Usage and Mutual TLS in EPP
- RFC 9154: EPP Secure Authorization Information for Transfer
- IETF: draft-ietf-deleg, Extensible Delegation for DNS
- IETF: draft-hoffman-deleg-secure-transports, DELEG Extensions for Secure Transports
- IETF: draft-brown-epp-deleg, EPP mapping for DELEG records
- IETF: draft-albanna-regext-rdap-deleg, RDAP Extension for DNS DELEG
- RFC 9567: DNS Error Reporting
- Verisign: MTL-Implementierungen auf GitHub
- Tobias Sattler: A Data-Driven Analysis of Structural Asymmetries in the gTLD Registrar Market, IEEE Access, Bd. 14, 2026