Das Vertrauen der Nutzer im Mittelpunkt – Highlights des CSA E-Mail Summits 2024 in Köln

In Köln fand vom 22. bis 24. April der Certified Senders Alliance Summit zum Thema „Trust fuels the future » statt. Und es gab Grund zum Feiern: bereits seit 20 Jahren hat sich die Initiative das Thema sichere E-Mail auf die Fahnen geschrieben

Die Unternehmenskommunikation hat sich in den letzten 20 Jahren mit dem Aufstieg der sozialen Netzwerke stark verändert: Instagram hat heute monatlich insgesamt mehr als 2 Milliarden Nutzer, YouTube mehr als 2,5 Milliarden und Facebook mehr als 3 Milliarden. Obwohl diese Plattformen weitgehend in die Kommunikationsstrukturen der Unternehmen integriert sind, ist die Nutzung von E-Mails zur Kundenkommunikation nach wie vor von hoher Relevanz – unter anderem aufgrund der Vielfältigkeit ihrer Einsatzgebiete wie z.B. Versand von Mailings, Newslettern, Rechnungen oder auch Auftragsbestätigungen . Daten von Statista zeigen einen Anstieg des Gesamtvolumens an E-Mails um 4,3 % im Jahr 2023 im Vergleich zum Vorjahr mit fast 347,3 Milliarden E-Mails, die täglich weltweit verschickt werden. Ein weiterer Fakt ist, dass eine Person im Durchschnitt etwa 121 E-Mails pro Tag erhält; eines scheint sicher: Die E-Mail wird nicht so schnell verschwinden.

Gartner weist jedoch darauf hin, dass die Sorge um die Sicherheit von E-Mails zunimmt, da kaum ein Unternehmen von Sicherheitsvorfällen verschont bleibt. Phishing-Attacken durch bösartige Links oder Anhänge werden immer ausgefeilter und verursachen Daten- und Umsatzverluste. Ausgehend von dieser Feststellung bringt die CSA jedes Jahr Experten des E-Mail-Ökosystems zusammen, um sich über bewährte Verfahren und Lösungen auszutauschen, welche die Qualität des Kanals verbessern und so das Vertrauen auf Kundenseite in die E-Mail verbessern. Die Veranstaltung ist um eine Reihe von Workshops, Sessions, Konferenzen und Masterclasses herum organisiert.

Nameshield war als Gold-Sponsor auf der Jubiläumsausgabe des CSA Email Summits dabei. Im Rahmen ihres Workshops im DNS TRACK stellten unsere Experten Joëlle Samaké und Arnaud Witterheim heraus, dass es keine E-Mail-Sicherheit ohne sichere Domainnamen und eine robuste und leistungsfähige DNS-Infrastruktur gibt. Die Sicherheit von E-Mails hängt daher von der Wahl des Domainnamenanbieters und den Cybersicherheitslösungen ab, die er seinen Kunden anbieten kann. Dazu zählt der Einsatz des DMARC-Protokolls, das die Nutzer vor betrügerischen E-Mails schützt. Die personalisierten Marken-Top Level Domains, die sogenannten Dot Brands, sind ein weiterer Hebel, um im Hinblick auf die nächste Runde neuer generischer Domainendungen, die für April 2026 geplant ist, Vertrauen in die eigene Marke zu schaffen.

Für weitere Informationen zu unseren Lösungen wenden Sie sich bitte an Ihren Nameshield-Berater.

DNS und HTTP(S) Weiterleitungen – Wie arbeiten sie zusammen ?

In der Welt der Websites und Domainnamen kommt es häufig vor, dass man die Verwendung eines Domainnamens – etwa in der Adresszeile des Webbrowsers – auf einen anderen umleiten möchte, um auf eine Website zuzugreifen. Ein Beispiel:

  • a-great-website.com auf www.a-great-website.com weiterleiten.
  • www.to-be-redirected.com auf www.a-great-website.com weiterleiten.

Es ist jedoch nicht immer ganz einfach zu verstehen, wie das alles funktioniert und wie man beim Einrichten dieser Weiterleitungen vorgehen muss. Muss ich die Weiterleitung auf der Ebene der DNS-Zone einrichten? Auf der Ebene meines Webservers? Auf beiden? Wahlweise das eine oder das andere?

Dieser Artikel soll die Unterscheidung zwischen DNS- und HTTP-Weiterleitung näher erläutern und aufzeigen, wie diese beiden Protokolle zusammenarbeiten.

Anmerkung: Im Folgenden wird nicht zwischen HTTP und HTTPS (durch ein Zertifikat gesichertes HTTP-Protokoll) unterschieden. Für das Thema, das uns hier interessiert, macht dies keinen Unterschied.

Den Unterschied zwischen DNS und HTTP richtig verstehen

DNS und HTTP sind zwei Protokolle, die beide für das reibungslose Funktionieren des Internets unerlässlich sind, aber nicht die gleiche Rolle spielen.

Nehmen wir als Beispiel einen Benutzer, der auf die Website blog.nameshield.com zugreifen möchte. Er gibt daher blog.nameshield.com in die Adresszeile seines bevorzugten Browsers ein.

Bevor der Browser eine Anfrage senden kann, um den Inhalt der Homepage der Website zu erhalten, muss er wissen, an welche IP-Adresse er diese Anfrage senden soll. Hier kommt das DNS ins Spiel. Der Browser sendet also eine DNS-Anfrage (unter Verwendung des DNS-Protokolls) an einen Resolver: „Gib mir die IP-Adresse, die mit blog.nameshield.com verknüpft ist“. Im Gegenzug erhält er eine IP-Adresse (81.92.84.102), die bei einem autoritären DNS-Server konfiguriert wurde. Man spricht von der Auflösung der Domain blog.nameshield.com.

Der Browser kann dann die HTTP-Request (unter Verwendung des HTTP-Protokolls) an den HTTP-Server (oder Webserver) senden, dessen IP-Adresse er soeben erhalten hat: „Gib mir den Inhalt der Webseite blog.nameshield.com„. Im Gegenzug erhält er den Inhalt der Seite, die er anzeigen soll.

Das DNS-Protokoll bietet Datensatztypen, die es ermöglichen, eine Domain auf eine andere „umzuleiten“: insbesondere den Typ CNAME. Auch wenn man leicht von DNS-„Umleitung“ spricht, ist der Begriff „Alias“ angemessener. Dieses leitet nicht im eigentlichen Sinne um, sondern zeigt an, dass die Domain, die man auflöst, ein Alias einer anderen Domain ist. Man muss dann diese andere Domain auflösen, um die gesuchte IP-Adresse zu erhalten.

Nehmen wir ein Beispiel: Man möchte eine Weiterleitung von www.to-be-redirected.com auf die Website www.a-great-website.com einrichten. Wenn wir die DNS-Zone von to-be-redirected.com mit einem CNAME-Eintrag wie diesem konfigurieren: www.to-be-redirected.com CNAME www.a-great-website.com, läuft das darauf hinaus, dass wir sagen: „Sie möchten die IP-Adresse wissen, die mit www.to-be-redirected.com verbunden ist ? Nun, suchen Sie die IP-Adresse, die mit www.a-great-website.com verbunden ist und Sie werden Ihre Antwort erhalten.“ Eine zweite DNS-Anfrage wird gesendet, um www.a-great-website.com aufzulösen und die IP-Adresse zu erhalten. Der Browser wird zwar über die IP-Adresse des HTTP-Servers verfügen, der uns interessiert (der Server, der die Webseite www.a-great-website.com hostet), aber das ändert nichts am Inhalt der vom Browser gesendeten HTTP-Anfrage: „Gib mir den Inhalt der Webseite www.to-be-redirected.com„.

Es ist wichtig zu beachten, dass die vom Browser gesendete HTTP-Anfrage den Namen der Website (oder Host – hier www.to-be-redirected.com) enthält, auf die man zugreifen möchte. Ein und derselbe Server (und damit eine IP-Adresse) kann nämlich Dutzende verschiedener Websites beherbergen. Er wird nur auf HTTP-Anfragen positiv reagieren, die einen Host enthalten, für den er konfiguriert ist. Es reicht also nicht aus, die IP-Adresse des Webservers zu kennen, Sie müssen ihm auch eine HTTP-Anfrage senden, auf die er antworten kann. Eine Anfrage http://www.to-be-redirected.com an einen Server zu senden, der nur für die Beantwortung von http://www.a-great-website.com konfiguriert ist, wird nicht funktionieren!

Auch das HTTP-Protokoll bietet ein System von Weiterleitungen (hier ist in der Tat von Weiterleitungen die Rede). Ein HTTP-Server kann so konfiguriert werden, dass er einen Host an einen anderen weiterleitet. Wenn er beispielsweise HTTP-Anfragen „Gib mir den Inhalt der Webseite www.to-be-redirected.com“ erhält, antwortet er „Diese Ressource wird an http://www.a-great-website.com weitergeleitet“. Dann nimmt der Browser die verschiedenen Schritte wieder auf:

  • DNS-Auflösung von www.a-great-website.com
  • Senden einer Anfrage http://www.a-great-website.com an die erhaltene IP-Adresse
  • Anzeige der erhaltenen Webseite

Wie können DNS und HTTP-Weiterleitungen gut zusammenarbeiten ?

Fassen wir noch einmal zusammen:

  • Das DNS dient dazu, einen Domainnamen aufzulösen, um eine IP-Adresse zu erhalten.
  • HTTP-Anfragen werden an eine IP-Adresse gesendet und enthalten den Host der Website, auf die man zugreifen möchte.
  • HTTP-Server können je nach Host in der Anfrage unterschiedliche Inhalte zurückliefern: eine von ihnen gehostete Webseite, eine Weiterleitung, für die sie konfiguriert wurden, oder einen Fehler, wenn ihnen der Host unbekannt ist.

Um eine Umleitung (immer noch mit unserem Beispiel) korrekt zu betreiben, benötigen Sie also:

  • Einen DNS-Eintrag in der Zone to-be-redirected.com, um den Host www mit der IP-Adresse eines Webservers zu verknüpfen und
  • Einen Webserver, auf dem eine Weiterleitung von http://www.to-be-redirected.com nach http://www.a-great-website.com eingerichtet werden muss.

Wie Nameshield Sie unterstützen kann ?

Nameshield bietet einen Dienst für HTTP- (und HTTPS-) Weiterleitungen an, der die Einrichtung dieser Weiterleitungen vereinfacht und den Sie nutzen können, sobald sich Ihre ursprüngliche Domain in der technischen Verwaltung von Nameshield befindet. Gehen Sie einfach zur Schnittstelle für die technische Konfiguration Ihres Domainnamens und dann zur Registerkarte „HTTP-Weiterleitungen“. Dort können Sie eine neue Umleitung auf den Host Ihrer Wahl erstellen, indem Sie verschiedene Parameter angeben (z. B. die Weitergabe von Verzeichnissen und oder von Parametern der Anfrage). Unser System übernimmt dann automatisch die folgenden Aufgaben:

  • Die DNS-Zone zu ändern, um Datensätze (A/JJJJ oder CNAME, je nachdem, was zutrifft) hinzuzufügen, die auf die IP-Adresse des Nameshield-HTTP-Weiterleitungsservers verweisen. In der Konfigurationsoberfläche der Zone gibt es ein eigenes Symbol, mit dem diese automatisch hinzugefügten Datensätze leicht unterschieden werden können.
  • Richten Sie eine neue Weiterleitung auf unserem HTTP-Weiterleitungsserver (der über eine Anycast-Architektur verfügt, wenn Sie ein Premium-Angebot nutzen) gemäß den geforderten Parametern ein.

Danach ist Ihre Weiterleitung funktionsfähig und Sie müssen nichts weiter tun. Bei Ihrem Webhoster sind keine Änderungen erforderlich.

Wenn Sie das Ziel einer bestehenden HTTP-Weiterleitung ändern möchten, müssen Sie nur von derselben Schnittstelle aus die bestehende Weiterleitung ändern (Sie müssen sie nicht löschen, um eine neue Weiterleitung zu erstellen). Am DNS müssen keine Änderungen vorgenommen werden, da der Host bereits auf unseren HTTP-Weiterleitungsserver weiterleitet. Unser System wird sich darum kümmern, die Konfiguration des HTTP-Servers zu ändern und Ihre neue Weiterleitung wird innerhalb weniger Minuten wirksam.

Wenn Sie Fragen zu diesem Artikel haben, wenden Sie sich bitte an Ihre/n Kundenbetreuer/in.

Treffen Sie Nameshield bei der it-sa vom 10.-12. Oktober 2023 in Nürnberg

Treffen Sie Nameshield vom 10. bis 12. Oktober in Nürnberg bei einer neuen Ausgabe der it-sa, dem unumgänglichen Treffen der IT-Sicherheitsbranche!

Als „Home of IT Security“ steht die it-sa sowohl für ein umfassendes Informationsangebot als auch für Networking und Wissensaustausch zu den Themen Datenschutz und IT-Sicherheit.

Auf dem dreitägigen Programm stehen Vorträge, Workshops, Diskussionsrunden, One-to-One-Termine und Möglichkeiten zum Networking…

Treffen Sie uns vor Ort: Halle 7, Stand 7-214, in Kooperation mit eco, dem Verband für Internetwirtschaft.

Tauschen Sie sich mit unserem Team aus und finden Sie heraus, inwieweit unsere globalen Lösungen Ihre Anforderungen an die DNS-Sicherheit erfüllen. Entdecken Sie unser Produkt für eine Hochverfügbarkeit Ihrer strategischen Domains: „DNS Bastion„.

Weitere Informationen finden Sie auf der Website der Veranstaltung: https://www.itsa365.de/

DNS als vergessene Achillesferse des Internets

Das Internet ist aus der heutigen Welt nicht mehr wegzudenken und ist die Basis vielfältigster Anwendungen: Webseitenauftritte, E-Mail-Kommunikation, Messengerdienste, Take-Away-Food-Bestellungen und Home-Office sind da noch die offensichtlichsten, da der Anwender direkt mit ihnen zu tun hat.

Heutzutage kommunizieren aber auch Autos, Handys und IoT-Geräte über das Internet, sei es um Softwareupdates zu laden, Sensordaten zu melden oder auch automatisiert Ersatzteile nachzuordern.

Aus diesem Grund hat so gut wie jede Firma strategisch wichtige Domains, die von Kunden, Mitarbeitern oder Geräten zu gewissen Zwecken aufgerufen werden kann.

Da Domainnamen (z.B. „nameshield.de“) leichter zu merken sind als IP-Adressen (z.B. in diesem Fall „81.92.80.55“) wurde 1983 das Domain Name System (DNS) entworfen und kam ab 1984 zum Einsatz. Es ist vergleichbar mit einem verteilten Telefonbuch und übersetzt zwischen Domainnamen und IP-Adressen. Diesen Vorgang bezeichnet man als „Auflösung“, die IP-Adresse wird dann von einem befugten DNS-Server geliefert.

Im Jahr der Einführung waren aber lediglich 1.000 Rechner an das Netzwerk angeschlossen, die häufig mit wissenschaftlicher Motivation betrieben wurden. Entsprechend ging man beim Entwurf des DNS und des Internets von freundlich-gesonnenen Netzwerkteilnehmern aus. Das hat sich ein wenig geändert: Derzeit schätzt man eine Anzahl von mehr als 5 Milliarden „menschlichen“ Internetnutzern weltweit, zusätzlich kommen unzählige Geräte hinzu. Durch dieses Wachstum wurde die virtuelle Welt auch attraktiver für Betrüger, Aktivisten und Erpresser und die Anforderungen an das Internet und das dahinterliegende DNS haben sich geändert.

Neben Basisfunktionen sind von funktionaler Seite vor allem folgende Punkte wichtig:

1. Verfügbarkeit: Eine hohe Verfügbarkeit ist notwendig, damit Website, E-Mails, Apps, VPN, SSO und andere Schlüsselservices reibungslos erreichbar sind und funktionieren. Ein Ausfall des DNS-Servers mit seiner Übersetzungsfunktion führt zu Datenverlust, finanziellem Schaden, Kundenabgang, Handlungsunfähigkeit von Remote-Arbeitern und Imageverlust.

2. Latenzzeit: Egal von welchem Ort man auf eine Domain zugreift und eine Domainauflösung initiiert, soll dies heutzutage zügig geschehen. Hohe Latenzen führen zu starken Einschränkungen oder auch Fehlern in Anwendungen. Beispielsweise ist ein Telefonat mit deutlichen Verzögerung in der Leitung nicht mehr sinnvoll durchführbar. Ein anderes Beispiel ist das rund 6.000 Kilometer lange, auf dem Meeresboden verlegte, Kabel, das die Finanzplätze London und New York 5 Millisekunden schneller als sein Vorgänger kommunizieren lässt und somit zu erheblichen Vorteilen beim Börsenhandel führen.

Aus dem Blickwinkel der IT-Sicherheit ergeben sich zudem weitere Anforderungen:

3. Schutz gegenüber administrativen Risiken:
Sollte ein unbefugter Zugriff auf die Konfiguration des DNS-Servers stattfinden, können relevante Daten wie IP-Adressen oder MX-Records geändert werden. Dadurch kann ein Angreifer beispielsweise legitime Domainanfragen auf eine von ihm kontrollierte IP-Adresse umleiten und so Internetnutzer auf Betrugsseiten schicken.

4. Schutz gegenüber technischen Risiken:

  • DDoS-Attacken: Mithilfe von Botnetzen können „Distributed Denial of Service“-Attacken (kurz DDoS) ausgeführt werden. Hierbei schicken zeitgleich hunderte bis zehntausende Bots geschickt formulierte Anfragen, die den DNS-Server überlasten, der dann wiederum keine Antworten mehr an legitim anfragende Clients geben kann. Über eine geschickte „reflection attack“ kann sogar noch eine weitere Partei mit hineingezogen werden.
  • DNS cache poisoning: Auf dem Weg zum DNS-Server sind Resolver vorgeschaltet. Diese werden vom Endclient kontaktiert, um eine URL aufzulösen. Der Resolver besitzt einen temporären Speicher (cache), um Domaindaten zwischenzuspeichern und muss deshalb nicht unbedingt bei jeder Anfrage des Endclients eine Verbindung zum DNS-Server herstellen. Dies reduziert die benötigte Bandbreite, gerade wenn man bedenkt, wie häufig Domains wie beispielsweise „google.de“ aufgerufen werden. Beim DNS cache poisoning wird versucht, diesen temporären Speicher mit falschen DNS-Daten zu füllen, sodass bis zur nächsten Anfrage am DNS-Server (sobald der temporäre Speicher gelöscht ist) gefälschte Informationen hinterlegt werden. Dadurch können Clients wieder auf Betrugsseiten umgeleitet werden.
  • DNS-Spoofing: Das DNS-Protokoll sieht erstmal keine Verschlüsselung und keinen Integritätsschutz von Anfragen und Antworten vor. Das heißt, dass Dritte die Kommunikation mithören können. In einem weiteren Schritt können sie sich dann als DNS-Server ausgeben und gefälschte Antworten mit falschen Informationen senden, die dann wiederum auf eine Betrugsseite führen können.
  • DNS-tunneling: DNS-requests werden normalerweise ständig und in hoher Anzahl aus dem Firmennetzwerk verschickt. Dabei werden sie sehr selten durch eine Firewall blockiert. Hacker nutzen dies aus, um Daten aus dem Firmennetzwerk zu extrahieren, ohne zu viel Aufmerksamkeit auf sich zu ziehen. Dazu registrieren sie eine Domain (bspw. „hacker.com“) und lassen den infizierten Firmenrechner DNS-Abfragen an diese Domain schicken. Dabei werden in jeder DNS-Abfrage zu extrahierende Daten mitgeschickt. Sobald alle Daten per DNS-Request übermittelt wurden, müssen die Angreifer diese dann nur noch aus den verschiedenen Abfragen zusammensetzen.

Um diese Funktionen und Sicherheitsanforderungen zu gewährleisten, sollte ein DNS-System durchdacht aufgesetzt werden. Beispielsweise gibt der IT-Grundschutz vor, dass DNS-Server redundant ausgelegt werden müssen und laufend überwacht werden müssen, um die Leistungskapazität der Hardware rechtzeitig anpassen zu können.

Auch Nameshield betreibt für seine Kunden DNS-Server, dabei geht das Produkt „DNS Bastion“ noch einen Schritt weiter, um die oben genannten Herausforderungen zu meistern. DNS Bastion ist vorgesehen für strategisch wichtige Domains und besteht aus fünf Säulen:

Integrität, Verfügbarkeit, Monitoring, Analyse und Alert

Eine kleine Beschreibung soll zeigen, was damit jeweils gemeint ist und wie damit die Anforderung abgedeckt werden können.

1. Integrität: Die Integrität soll vor allem gegenüber administrativen Risiken schützen. Beispielsweise beinhaltet DNS Bastion die Funktion „Registry Lock“, um unauthorisierte, ungewollte und unbeabsichtigte Änderungen der Domain zu verhindern. Weitere Funktionen beinhalten unter anderem Multifaktor-Authentifizierung und IP-Filterung, um nur mit valider Berechtigung und von einem bestimmten IP-Bereich Änderungen vornehmen zu können.

2. Verfügbarkeit: Durch ein Dual Anycast Netzwerk mit 80 Standorten und einem zweifachen DDoS-Schutz kann eine hohe Verfügbarkeit (99,999%), eine geringe Latenzzeit und ein Schutz vor DDoS-Attacken gewährleistet werden. Zusätzliche Funktionen wie DNSSEC und TSIG sind ein wirksames Mittel gegen DNS Spoofing und DNS Cache Poisoning. Mit DNSSEC kann die anfragende Partei verifizieren, dass die übermittelten DNS-Informationen identisch sind mit denen, die vom Ersteller der Zone autorisiert wurden. Dazu werden die DNS-Records digital signiert und damit Authentizität und Integrität der DNS-Antwort sichergestellt.

3. Monitoring: Kontinuierliches internes und externes Monitoring des Domainnamens sowie detaillierte Traffic-Statistiken ermöglichen eine umfangreiche Überwachung der Domain und des DNS. Zeitgleich steht ein Supportteam 24/365 bereit.

4. Analyse: Im monatlichen Intervall wird ein Bericht verschickt, in dem wichtige Daten und Parameter des DNS untersucht werden. Neben einer tiefgründigen DNS-Traffic-Analyse wird die Zonenkonfiguration bewertet. Zusätzlich werden die RFC-Compliance und ANSSI-Empfehlungen berücksichtigt. All diese Informationen unterstützen bei einer konformen Einrichtung und Betrieb von DNS und Domain.

5. Alert: Durch die vorher genannten Sicherheitsfunktionen kann die Attraktivität als Angriffsziel reduziert werden. Dennoch können Angreifer eine Attacke versuchen. Um dies schnellstmöglich festzustellen und handeln zu können, erkennt DNS Bastion Anomalien in DNS-Traffic sowie bei Zugriffsversuchen auf die Nameshield Schnittstelle. In diesem Fall wird automatisch ein Alert sowie ein Vorfallsbericht verschickt. Die zügige Erkennungs- und Warnfunktion hilft dabei handlungsfähig zu bleiben.

Gerne helfen wir bei der Identifikation der strategischen Domains und ihrem anschließenden Schutz.

ICANN76, Führungsstil der neuen Interimspräsidentin Sally Costerton prägend für die Neuausrichtung der ICANN?

Die Stadt Cancun, die sich im März 2020 und dann im März 2021 für die Ausrichtung des ICANN-Gipfels beworben hatte, musste schließlich bis zum März 2023 und dem Ende der COVID-Pandemie auf eine Veranstaltung in Präsenz warten. 2023 ist ein sehr wichtiges Jahr für die ICANN – sie feiert ihr 25-jähriges Jubiläum. Nach dem Rücktritt ihres Präsidenten am 22. Dezember 2022 allerdings unter einer Interimspräsidentschaft.

Zwei Frauen an der Spitze des Gremiums

Die Engländerin Sally Costerton, die seit 2012 als Vizepräsidentin des Global Stakeholder Engagement (GSE) für die Sensibilisierung von Interessengruppen hinsichtlich der Anliegen der ICANN und seine weltweite Mission zuständig war, wurde nach dem Ausscheiden von Goran Marby Ende 2022 zur Interims-Geschäftsführerin und Präsidentin von ICANN ernannt. An ihrer Seite steht Tripti Sinha, ihrerseits Vorsitzende des ICANN-Vorstands. Sie ist stellvertretende Vizepräsidentin und Direktorin für Technologie an der Universität von Maryland in der Abteilung für Informationstechnologie. Damit stehen zum ersten Mal in der Geschichte der ICANN zwei Frauen an der Führungsspitze, in gewisser Weise eine Referenz an das Gründungsjahr 1998, als die US-Regierung die ICANN mit der Verwaltung des DNS-Adressierungssystems beauftragte und mit Esther Dysons ebenfalls eine Frau den Vorstandsvorsitz innehatte.

Zwar sind Führungsinterims bei der ICANN selten, aber dieser Umstand führte zu einer besonderen Sitzung mit dem Titel „Die Zukunft der ICANN und der nächste Präsident und CEO“. Eine Sitzung, bei der man erwarten konnte, dass die Teilnehmer mit dem neuen Vorstand interagieren würden. Dem war jedoch nicht so, da diese Sitzung einer Art freiem Mikrofon ohne direkten Ansprechpartner glich, um die Erwartungen an die neue Führung der Organisation zum Ausdruck zu bringen.

Ein Interimsmanagement könnte für eine Governance-Organisation auch eine risikoreiche Zeit bedeuten, zumal es nicht an Themen mangelt, die angesprochen werden müssen, und der geopolitische Kontext zu einer stärkeren Fragmentierung tendiert. Sally Costerton machte zu Beginn des Gipfels ihr Verständnis von Führung mit den Worten „Ich weiß nicht alles, aber ich stütze mich auf Experten“ deutlich und stieß damit im Publikum auf große Zustimmung.

Transparenz auf dem Prüfstand der Erfahrung

Die ICANN ist prinzipiell eine gut eingespielte Organisation. In den letzten Jahren war der Trend zu beobachten, dass die Supporting Organisationen (SO) und die Advisory Committees (AC), aus denen sie sich zusammensetzt, transparenter wurden, indem sie alle ihre Sitzungen der Öffentlichkeit zugänglich machten. Die bedeutendste Veränderung ist beim GAC zu verzeichnen, dem Gremium, das die Regierungen vertritt, dessen Sitzungen viele Jahre lang im kleinen vertraulichen Kreis stattgefunden haben, bevor sie vollständig für alle Teilnehmer geöffnet wurden. Ein Trend, der Vertrauen schaffen kann, um den immer zahlreicher werdenden Kritikern des ICANN-Governance-Modus zu begegnen.

Dieser Trend kehrte sich jedoch auf dem Cancun-Gipfel um, da viele Sitzungen geschlossen waren, sogenannte „Closed Sessions“, zu denen selbst einige angemeldete Nutzer keinen Zugang hatten, weder im Präsenz- noch im Remotemodus. Dies wurde von den Teilnehmern auf dem traditionellen öffentlichen Forum, das die Sitzungswoche normalerweise abschließt, kritisiert.

Fortschritte im Eiltempo?

Der Konsensansatz, ein Markenzeichen der ICANN, ist einerseits ein Vorteil, um möglichst viele Akteure für die beschlossenen Verpflichtungen zu gewinnen, andererseits aber auch ein Manko, da er die Fortschritte bei wichtigen Arbeiten erheblich verlangsamt.

Ein prominentes Beispiel ist der Missbrauch des DNS. Die böswillige Nutzung ist in der Tat ein echtes Problem, wenn man bedenkt, welchen Schaden die betroffenen Internetnutzer erleiden. Der GAC hat dies in einer Sitzung, zu der auch externe Experten wie ein Vertreter des FBI eingeladen wurden, noch einmal hervorgehoben. Dieser berichtete, dass in den USA im Jahr 2022 mehr als 800.000 Domainnamen Gegenstand von Beschwerden waren, die Verluste von mehr als 10 Milliarden US-Dollar verursachten. Das Thema DNS-Missbrauch hat in den vergangenen Jahren bei jedem ICANN-Gipfel eine Rolle gespielt hat – hier scheint das Konsensprinzip an seine Grenzen zu stoßen. Die Interessenvertreter in der GNSO, dem Gremium, das sich mit der Politik für generische Namen befasst, konnten sich konnten sich nicht auf ein umfassendes einheitliches Vorgehen einigen. Eine Änderung der Verträge der Registries und Registrierungsstellen ist in Arbeit und soll im Juni vorgelegt und ab Oktober den betroffenen Parteien zur Abstimmung vorgelegt werden.  

Die GNSO beabsichtigt, auf der Dynamik einer weiteren Vertragsänderung aufzubauen, über die die Interessengruppen abstimmen sollen: eine „RDAP“-Änderung. RDAP ist ein alternatives Protokoll zu Whois, mit dem die Registrierungsdaten von Domainnamen abgerufen werden können. Der Ausgang der Abstimmungen und damit die Annahme der Vertragsänderungen blieb am Ende des ICANN-Gipfels ungewiss, da verschiedene Schwellenwerte für die Teilnahme und die Anzahl der Ja-Stimmen erreicht werden müssen.

Teilweise Zustimmung zu den Empfehlungen für spätere Runden neuer gTLDs

Ein weiteres Thema, das einige gerne schneller vorangetrieben sehen würden, sind die nächsten Runden neuer generischer TLDs. Das letzte Bewerbungsfenster für generische Erweiterungen fand im Januar 2012 statt. Seitdem wurde seit 2015 ein Politikentwicklungsprozess durchgeführt, der eine Reihe von Empfehlungen für die Durchführung neuer Bewerbungsfenster enthält. Der Abschlussbericht dieses Prozesses wurde dem ICANN-Vorstand im Februar 2021 vorgelegt. Im Herbst 2021 überraschte die ICANN die Community mit der Ankündigung einer sogenannten ODP (Operational Design Phase), die schließlich bis Anfang dieses Jahres dauerte. Der Vorstand hatte wohl noch nicht über das letztendliche Vorgehen entschieden. Die Position der neuen Interimspräsidentin der ICANN wurde also auch zu diesem Thema mit Spannung erwartet.

Sie warnte, dass die Zeit auch in dieser Frage reif sei: „Sie werden sehen, dass die Dinge geklärt werden“ (Anm. d. Red.: in Bezug auf die nächsten Runden), sagte sie während einer Sitzung unter der Woche. Am Ende der Woche wurden auf einer Vorstandssitzung 98 Empfehlungen aus dem Prozess der Politikentwicklung angenommen, 38 weitere wurden zunächst zurück gestellt, da sie weitere Ausarbeitungen benötigten. Ein Umsetzungsplan wird ebenfalls erwartet und soll im August vorliegen. Der Schwerpunkt liegt dabei auf internationalisierten Namen und Erweiterungen, welche die ICANN in den Vordergrund stellen möchte. Weiterhin muss geklärt werden, ob geschlossene generische Erweiterungen angeboten werden können.

Beobachtungen von NAMESHIELD

Es ist zu bedauern, dass die Entscheidungsfindung bei ICANN76 mit nicht weniger als 25 geschlossenen Sitzungen zu einer gewissen Intransparenz zurückgekehrt ist. Einziger Vorteil: Fortschritte bei Themen, die bisher nur schwer vorangekommen sind, wie der Vorbeugung vom Missbrauch des DNS, ein Thema, das für NAMESHIELD sehr wichtig ist, da wir unseren Partnern mehrere Lösungen zur Verfügung stellen, um Ihre Online-Assets zu verteidigen. Interessant ist aus unserer Sicht ebenfalls die Durchführung einer nächsten Runde neuer Erweiterungen, bei der die Experten von NAMESHIELD Sie ebenfalls begleiten können.

Wie wird die neue Interimspräsidentin von ICANN, Sally Costerton, ihre neue Rolle in einer für die ICANN riskanten Zeit ausfüllen, in der die ICANN zunehmend von Staaten, internationalen Organisationen und sogar technologischen Alternativen herausgefordert wird? Die neue Präsidentin wirkte in diesem Punkt proaktiv und ließ ihren Worten Taten folgen, wie beispielsweise bei der Frage nach weiteren Runden neuer generischer Endungen. Sally Costerton scheint sich bereits darauf vorzubereiten, die Rolle des CEO für eine volle Amtszeit der Organisation zu übernehmen.

Bildquelle: ICANN-Website

SVCB / HTTPS: Zwei neue DNS-Eintragstypen

SVCB / HTTPS: Zwei neue DNS-Eintragstypen

Das DNS, das Domain Name System, ist ein wichtiger Dienst für das Funktionieren des Internets. Es wird oft als ein Verzeichnis beschrieben, in dem Domainnamen mit IP-Adressen verknüpft werden können, doch das stellt nur einen Bruchteil seiner Funktionen dar.

DNS-Einträge der Typen A und AAAA ermöglichen es, IP-Adressen hinter einem Domainnamen zu konfigurieren. Daneben gibt es aber Dutzende weiterer DNS-Eintragstypen, die für verschiedene Anwendungsfälle nützlich sind.

Dienste vereinfachen und Latenzen reduzieren

Typ SVCB

Der SVCB-Typ, der für SerViCe Binding steht, soll nützliche Informationen über die mit einem Domainnamen verfügbaren Dienste angeben. Das Format des SVCB-Datensatzes besteht aus einer Priorität, einem Ziel und einer optionalen Parameterliste. Beispielsweise kann damit angegeben werden, dass für einen definierten Dienst ein Domainname tatsächlich mit einem anderen Namen mit einer bestimmten Konfiguration verknüpft ist.

SVCB [SvcPriority] [TargetName] ([SvcParams]…)

SVCB-Datensätze unterscheiden sich von SRVs in mehreren Punkten:

  • SRV-Datensätze sind in der Regel obligatorisch, damit ein Dienst funktioniert dies ist bei SVCB nicht der Fall
  • SVCB-Datensätze können mehr Informationen angeben als SRVs, z. B. eine zu verwendende Protokollversion
  • Der SVCB-Typ ist im Gegensatz zu SRVs erweiterbar, so dass verschiedene zukünftige Entwicklungen und Verwendungen denkbar sind

Typ HTTPS

Der Typ HTTPS ist ein von SVCB abgeleiteter Typ. Im Gegensatz zum SVCB-Typ, der generisch ist, ist der HTTPS-Typ spezifisch für das HTTPS-Protokoll.

Um eine HTTPS-Verbindung zu initiieren, muss der Client in der Regel zuerst eine HTTP-Verbindung aufbauen, um verschiedene Informationen abzurufen, z. B. welche Version er verwenden soll, dies erzeugt Latenz.

Der DNS-Eintrag vom Typ HTTPS ermöglicht es insbesondere, dem Client verschiedene Parameter anzugeben, um die Verbindung zum Server zu erleichtern und so die Latenz zu verringern. Er hat die gleiche Form wie ein SVCB-Eintrag:

HTTPS [SvcPriority] [TargetName] ([SvcParams]…)

Alias-Modus

SVCB/HTTPS-Registrierungen bieten zwei Betriebsmodi. Einen Alias-Modus und einen Service-Modus.

Der Alias-Modus wird aktiviert, wenn die Priorität auf 0 gesetzt ist. Er ermöglicht die Umleitung eines Domainnamens auf einen anderen Namen und löst insbesondere das bekannte Problem des CNAME-at-apex.

Mit dem CNAME-Eintrag können Sie angeben, dass eine Subdomain auf einen anderen Domainnamen verweist. Er ist sehr nützlich, um einen Dienst zu delegieren: z. B. um den Namen www.beispiel.de auf die bei meinedomain.testhost.de  gehostete Website verweisen zu lassen.

www CNAME meinedomain.testhost.de

Das Problem mit dem CNAME-Datensatz ist, dass er nicht im Stamm eines Namens definiert werden kann. Um dieses Problem zu umgehen, werden nicht-standardmäßige Lösungen wie ALIAS- oder ANAME-Einträge angeboten, aber diese Typen werden nicht von allen DNS-Betreibern unterstützt. Der Alias-Modus der SVCB/HTTPS-Einträge ist eine Lösung für dieses Problem.

SVCB 0 nameshield.net.

HTTPS 0 nameshield.net.

Service Modus

Der Service Modus der SVCB/HTTPS-Einträge ermöglicht es, anzugeben, welche Dienste hinter einem Domainnamen konfiguriert sind. Bei der Diensterkennung liefert dies dem Client eine Reihe von Parametern, die in einem einzigen DNS-Eintrag zusammengefasst sind. Ziel ist es, die Nutzung von Diensten zu erleichtern und die Latenz zu verringern.

Zum Beispiel kann es einen HTTPS-Eintrag geben, der besagt, dass der Client mit dem HTTP/2- oder HTTP/3-Protokoll (alpn) eine Verbindung zu den definierten IPv4- und IPv6-Adressen (ipv4hint, ipv6hint) auf Port 8061 (port) herstellen kann.

HTTPS 1 . alpn=”h3,h2” ipv4hint=”192.168.0.1” ipv6hint=”2001:db8::1” port=8061

Deployment läuft

SVCB/HTTPS-Registrierungen bieten mehrere Funktionen, um die Webleistung zu verbessern und das Root-CNAME-Problem anzugehen. Die Tatsache, dass sie generisch und skalierbar sind, ermöglicht es, den Umfang der Anwendungsfälle zu erweitern.

Obwohl sie noch nicht durch einen RFC standardisiert sind, werden diese neuen Arten von Datensätzen bereits verwendet. Einige DNS-Software und Webbrowser unterstützen diese Datensätze und Player wie Apple, Google, Cloudflare und Nameshield implementieren sie bereits.

Heute müssen Dienste, die mit SVCB/HTTPS-Registrierungen arbeiten, in Zweifelsfall jedoch auch darauf verzichten können, da die Einführung noch nicht flächendeckend erfolgt ist. Dies ist ein Stadium, der mehrere Monate dauern kann, bis die meisten Betreiber aufgerüstet haben.


Bildquelle: TheDigitalArtist via Pixabay