Zusammenfassung

  • Die Industrial and Commercial Bank of China Limited betreibt mit .icbc eine eigene Marken-Top-Level-Domain – also den letzten Bestandteil einer Internetadresse rechts vom abschließenden Punkt
  • Für die Bank ist .icbc damit nicht bloß eine auffällige Endung für mögliche Webadressen

Die Industrial and Commercial Bank of China Limited betreibt mit .icbc eine eigene Marken-Top-Level-Domain – also den letzten Bestandteil einer Internetadresse rechts vom abschließenden Punkt. Für die Bank ist .icbc damit nicht bloß eine auffällige Endung für mögliche Webadressen. Es handelt sich um eine technische und organisatorische Kontrollebene für einen abgegrenzten Namensraum. Sie bestimmt, welche Namen unter .icbc existieren, an welche Nameserver sie delegiert werden und über welche öffentlichen Schnittstellen sich Registrierungsdaten prüfen lassen.

Diese Kontrolle ist gerade deshalb relevant, weil auch ein sehr kleiner Namensraum dauerhaft gepflegt werden muss. Im öffentlichen Monatsbericht für Januar 2026 erscheint für .icbc nur eine Domain. Dennoch müssen DNS-Daten, Sicherheitsinformationen, Registrierungsdatensätze, Kontakte und Notfallzuständigkeiten miteinander übereinstimmen. Software wird aktualisiert, Schlüssel laufen aus, Ansprechpartner wechseln und technische Dienstleistungsbeziehungen können sich verändern. Jede solche Änderung kann neue Abstimmungs- und Prüfkosten erzeugen.

Betroffen sind nicht nur technische Registry-Betreiber. Auch Risiko- und Sicherheitsteams der Bank, Registrare, die Änderungen einreichen, Verantwortliche für Markenführung und Recht, externe Prüfer sowie gegebenenfalls Nutzer einer .icbc-Adresse sind auf korrekte und widerspruchsfreie Einträge angewiesen. Aus den öffentlichen Unterlagen lässt sich weder ableiten, dass bei ICBC ein Ausfall eingetreten ist, noch dass konkrete Kundendienste von .icbc abhängen. Erkennbar ist jedoch, worauf Verantwortliche achten sollten: die Delegation in der DNS-Wurzel, die autoritativen Nameserver, die Konsistenz von WHOIS und RDAP, die DNSSEC-Sicherheitsdaten und die Rollenverteilung für Wartung und Wiederherstellung.

Hauptsitz der Industrial and Commercial Bank of China an der West Chang’an Avenue in Peking. Foto: Boubloub, CC0.

Das Bild zeigt ausschließlich den Hauptsitz des Unternehmens. Es zeigt weder die Infrastruktur der .icbc-Registry noch DNS- oder RDAP-Systeme, technische Dienstleister, Mitarbeiter im Betrieb, Leistungswerte, Störungen oder Auswirkungen auf Kunden.

Was geschehen ist

Die öffentlich zugänglichen Unterlagen ordnen .icbc eindeutig der Industrial and Commercial Bank of China Limited zu. Gemeint ist genau dieses Unternehmen und nicht die ICBC Financial Services LLC, die ICBC Standard Bank PLC oder eine andere Gesellschaft mit einem ähnlichen Namen. Die IANA führt die Bank als sponsernde Organisation der Endung. ICANN dokumentiert einen Registry-Vertrag vom 19. Februar 2015 und behandelt .icbc als Marken-Registry nach Specification 13.

Eine Registry ist die Stelle, die den maßgeblichen Bestand einer Domain-Endung verwaltet und die Regeln sowie Datensätze für deren Namen führt. Sie ist damit eine Art begrenztes Register: Sie hält fest, welche Namen eindeutig vergeben sind, welche technischen Daten dazugehören und über welche Wege Änderungen vorgenommen werden können. Sie entscheidet dadurch nicht souverän über das Internet insgesamt. Ihre Aufgabe besteht darin, einen klar abgegrenzten Datensatz zuverlässig mit dem globalen Namenssystem zu verbinden.

Nach den IANA-Unterlagen wurde .icbc am 9. April 2015 registriert. Der Eintrag nennt außerdem eine Aktualisierung vom 12. Dezember 2024. Vor der Aufnahme in die DNS-Wurzel wurden laut den veröffentlichten Delegations- und Bereitschaftsunterlagen unter anderem die Identität des Antragstellers, die technische Konformität und die Bestätigung von Kontakten geprüft.

Als Delegation bezeichnet man die veröffentlichte Zuordnung eines Namensbereichs zu den autoritativen Nameservern, die für ihn verbindliche Antworten liefern. Bei einer Top-Level-Domain geschieht diese Zuordnung in der Wurzel des Domain Name System. Das Domain Name System, kurz DNS, ist das verteilte Verzeichnissystem, das lesbare Domainnamen mit technischen Einträgen wie Nameservern oder IP-Adressen verbindet. Die Delegation sagt anderen DNS-Teilnehmern, an welche Server sie sich für verlässliche Informationen über .icbc wenden sollen.

Der IANA-Eintrag führt acht autoritative Nameserver mit ZDNS-gebrandeten Hostnamen auf. Außerdem nennt er whois.nic.icbc als WHOIS-Dienst. WHOIS ist ein älteres, textorientiertes Abfragesystem für Registrierungsdaten. Daneben ist eine RDAP-Basis veröffentlicht. RDAP, das Registration Data Access Protocol, ist eine strukturierte, HTTP-basierte Schnittstelle für Registrierungsinformationen und lässt sich besser maschinell verarbeiten als traditionelle WHOIS-Ausgaben.

Diese öffentlichen Merkmale belegen, dass ein delegierter Namensraum und mehrere von außen sichtbare Zugriffspunkte existieren. Sie zeigen jedoch nicht, wie die private Betriebsarchitektur aufgebaut ist, wer welche Systeme wartet, welche Verträge ICBC geschlossen hat oder wie Verantwortung zwischen Bank, Registry-Funktionen, Registrar und technischen Dienstleistern verteilt ist. Insbesondere sind ZDNS-gebrandete Nameservernamen lediglich beobachtbare Delegationsdaten. Sie erlauben keine belastbare Aussage über die interne Vertragslage, Personalstruktur, Sicherheitsorganisation oder Haftungsgrenzen.

Die öffentlichen ICBC-Seiten und die BTW-Verzeichniseinträge grenzen zusätzlich das betrachtete Unternehmen ab. Der Geschäftsbericht 2025 liefert einen allgemeinen Kontext zu Cyberrisiken, Technologie und operativer Widerstandsfähigkeit innerhalb der Bankengruppe. Er ist jedoch kein Betriebsbericht für .icbc. Aus ihm lassen sich weder DNS-Latenzen noch Registry-Verfügbarkeit, RDAP-Datenqualität, erfolgreiche Änderungen oder das Ergebnis möglicher Wiederherstellungsmaßnahmen ableiten.

Auch die ICANN-Monatsberichte müssen in ihrer jeweiligen Beweiskategorie bleiben. Für Januar 2026 melden die veröffentlichten Dateien eine Domain, sieben Nameserver und drei operative Registrare. Die Aktivitätsdatei nennt 199.814.952 empfangene DNS-Anfragen über UDP und ebenso viele gemeldete Antworten. Für DNS über TCP werden 1.814.759 empfangene Anfragen und dieselbe Zahl an Antworten aufgeführt. Außerdem erscheinen acht Host-Prüfungen, 22 Host-Erstellungen und null gemeldete RDAP-Abfragen.

Diese Zahlen sind vertragliche Berichtszähler. Sie dokumentieren, welche Werte in bestimmten Kategorien gemeldet wurden. Sie sind keine unabhängigen Messwerte für Verfügbarkeit, Geschwindigkeit, Erfolgsquote oder Servicequalität. Auch die Übereinstimmung der empfangenen und beantworteten DNS-Zähler im Januar 2026 darf nicht als Beleg für hundertprozentige Verfügbarkeit gelesen werden.

Historische Aktivitätsdateien für Dezember 2025, Januar 2025 und Januar 2024 zeigen, warum besondere Vorsicht nötig ist: In einzelnen Kategorien liegen gemeldete Antwortzähler geringfügig über den Zählern für empfangene Anfragen. Eine einfache Division von Antworten durch Anfragen könnte deshalb einen scheinbaren Wert von mehr als 100 Prozent erzeugen. Das ist ein deutlicher Hinweis darauf, dass die Zahlen nicht als vollständig gepaarte Einzelereignisse aus einem geschlossenen Messstrom behandelt werden dürfen.

Die öffentlichen Dateien erläutern nicht für jede Abweichung deren Ursache. Denkbar wären unterschiedliche Aggregationszeitpunkte, Erfassungsgrenzen, Wiederholungen, Kategorisierungen oder Definitionen der Berichtsfelder. Ohne die zugrunde liegende Messmethode, Rohdaten, Zeitgrenzen und Revisionsregeln bleibt jede konkrete Erklärung spekulativ. Belastbar ist nur die engere Aussage: Die Dateien enthalten vertragliche Monatszähler, nicht eine vollständige Leistungsanalyse des Livebetriebs.

Dass der Bericht null RDAP-Abfragen nennt, beweist ebenso wenig, dass der Dienst ungenutzt, unnötig, nicht erreichbar oder fehlerfrei war. Ein Zähler von null bedeutet zunächst nur, dass für die betreffende Berichtskategorie und den betreffenden Zeitraum null gemeldet wurde. Er sagt nichts darüber aus, ob alle Registrierungsdaten korrekt waren oder ob interne Kontrollen die Schnittstelle geprüft haben.

Der bisher öffentlich erkennbare Sachstand ist daher begrenzt, aber klar: Die Industrial and Commercial Bank of China Limited ist mit einer delegierten Marken-Top-Level-Domain, öffentlichen DNS- und Registrierungsdatenschnittstellen sowie vertraglichen Berichts- und Betriebspflichten verbunden. Diese Unterlagen belegen Registry-Fähigkeit. Sie belegen weder die dauerhafte Zuverlässigkeit eines Produkts oder Dienstes noch konkrete Ergebnisse für Kunden.

Warum das wichtig ist

Eine Marken-Top-Level-Domain kann nach außen wie ein Marketinginstrument wirken. Technisch ist sie jedoch eine Kontrollebene, die über Namen, Delegationsdaten, Kontakte, Sicherheitsinformationen und Änderungswege liegt. Selbst wenn unter einer Endung nur sehr wenige Domains registriert sind, nimmt die Registry am globalen DNS teil. Ihre Datensätze müssen eindeutig bleiben, und andere Systeme müssen zuverlässig erkennen können, welche Server und Sicherheitsdaten für den Namensraum maßgeblich sind.

Der öffentliche Bestand von einer Domain macht .icbc deshalb nicht zu einem trivialen System. Bestimmte Kosten entstehen unabhängig von der Zahl registrierter Namen. Die Delegation in der Wurzel muss gepflegt werden. Autoritative Nameserver müssen korrekt eingetragen sein. Sicherheitsinformationen in über- und untergeordneten Zonen müssen zueinander passen. WHOIS und RDAP müssen konsistente Registrierungsdaten darstellen. Registrarzugänge, Kontakte, Berichtspflichten, Datenhinterlegung und Übergangspläne bleiben erforderlich.

Bei einer Marken-Registry liegt der wirtschaftliche Zweck häufig stärker in der Kontrolle als im Verkaufsvolumen. Specification 13 bildet einen vertraglichen Rahmen für einen eingeschränkten, von einer Marke betriebenen Namensraum. Das kann die Komplexität eines offenen Endkundengeschäfts reduzieren, weil nicht beliebige Dritte Domains registrieren. Es ändert aber nichts an den technischen Grundlagen. DNS-Anfragen folgen denselben Mechanismen, Sicherheitsketten müssen weiterhin stimmen und Notfalländerungen benötigen weiterhin klar definierte Berechtigungen.

Gerade ein wenig genutzter Namensraum kann besondere organisatorische Risiken erzeugen. Häufig ausgeführte Abläufe werden durch Routine ständig erprobt. Seltene Vorgänge – etwa eine Nameserveränderung, ein DNSSEC-Schlüsselwechsel, die Korrektur eines Kontakts oder eine Notfallübergabe – können dagegen nach langer Pause erstmals wieder präzise ausgeführt werden müssen. Dann zählen nicht nur technische Systeme, sondern auch institutionelles Wissen: Wer darf handeln? Wer genehmigt? Welche Daten gelten als Sollzustand? Welche Belege werden nach der Änderung geprüft?

Die monatlich gemeldeten drei operativen Registrare zeigen, dass Registrar-Beziehungen Teil des öffentlichen Betriebsrahmens sind. Ein Registrar ist die zugelassene Schnittstelle, über die Domainobjekte angelegt, geändert, verlängert oder außer Betrieb genommen werden können. Die Zahl drei sagt jedoch nicht, welcher Registrar tatsächlich welche Aufgaben übernimmt, wie häufig ein Zugang genutzt wird oder wie Ausnahmefälle behandelt werden.

Auch eine kleine Zahl von Registraren erzeugt Integrationskosten. Zugangsdaten müssen geschützt, Berechtigungen begrenzt, fehlgeschlagene Transaktionen nachvollzogen und Änderungen bestätigt werden. Wenn eine seltene Operation fehlschlägt, muss geklärt werden, ob die Ursache im Registrarweg, in der Registry-Plattform, in einer Freigabe, in einem Datenkonflikt oder in einer nachgelagerten DNS-Veröffentlichung liegt. Die öffentlichen Quellen weisen keinen solchen Fehler bei ICBC nach. Sie zeigen lediglich, warum ein kontrollierter Namensraum dennoch ein belastbares Verfahren für diese Fehlerklasse benötigt.

Für eine Bank kommt die Bedeutung der Marke hinzu. Nutzer könnten eine Adresse unter einer bankeigenen Endung als besonderes Authentizitätssignal verstehen, sofern solche Adressen eingesetzt werden. Die hier ausgewerteten Quellen belegen allerdings keine konkrete Kundennutzung und keine Abhängigkeit eines Bankdienstes von .icbc. Dennoch bedeutet schon die Möglichkeit einer solchen Wahrnehmung, dass technische und organisatorische Fehler reputationsrelevant sein können.

Dabei müssen drei Ebenen streng getrennt werden. Erstens belegen Delegation, Verträge und öffentliche Schnittstellen eine Registry-Fähigkeit. Zweitens wäre für Aussagen über die Zuverlässigkeit eines Produkts oder Dienstes eine andere Evidenz erforderlich, etwa unabhängige Verfügbarkeitsmessungen, Latenzdaten, Fehleranalysen, Änderungsprotokolle und Wiederherstellungstests. Drittens bräuchte man für Aussagen zu realen Kundenergebnissen konkrete Nachweise über eingesetzte Anwendungen, betroffene Nutzer und beobachtete Geschäftsauswirkungen.

Keine dieser Ebenen kann die andere ersetzen. Eine erreichbare RDAP-Adresse beweist nicht, dass alle Daten stets korrekt sind. Ein Vertrag beweist nicht die kontinuierliche Einhaltung jeder Pflicht. Ein hoher DNS-Zähler beweist nicht, dass ein Kunde eine Website erfolgreich erreicht hat. Eine geringe Domainzahl beweist weder geringe Bedeutung noch hohe Bedeutung für den Bankbetrieb.

Der eigentliche Wert von .icbc liegt daher in der Fähigkeit, einen eindeutigen Namensraum unter der eigenen Marke zu kontrollieren. Der dazugehörige Preis besteht nicht nur aus Infrastruktur- oder Dienstleisterkosten. Hinzu kommen Überwachung, Integration, Wartung, Dokumentation, Berechtigungsmanagement und die Behandlung seltener Ausnahmen. Diese laufenden Kontrollkosten bleiben bestehen, auch wenn die Registry im Alltag kaum sichtbar ist.

Die technische Ebene

Die öffentliche DNS-Beobachtung nennt für .icbc acht autoritative Nameserver:

  • a.zdnscloud.cn.
  • b.zdnscloud.cn.
  • c.zdnscloud.cn.
  • d.zdnscloud.cn.
  • f.zdnscloud.cn.
  • i.zdnscloud.cn.
  • g.zdnscloud.com.
  • j.zdnscloud.com.

Autoritativ bedeutet, dass diese Server für den delegierten Namensraum verbindliche DNS-Antworten veröffentlichen. Die Liste beschreibt einen beobachtbaren Zustand. Sie ist kein Beleg für geografische Vielfalt, erfolgreiche Ausfallsicherung, eine bestimmte interne Architektur oder die Qualität des Dienstes. Auch die Markenbezeichnung in den Hostnamen darf nicht als Nachweis eines bestimmten privaten Vertrags oder einer bestimmten Verantwortungsverteilung interpretiert werden.

Für die Absicherung der DNS-Daten ist außerdem DNSSEC sichtbar. DNSSEC ist ein System digitaler Signaturen, mit dem prüfende Resolver erkennen können, ob DNS-Antworten kryptografisch zu der erwarteten Vertrauenskette passen. Die öffentliche Beobachtung enthält einen DS-Eintrag mit Key Tag 52120, Algorithmus 8 und Digest-Typ 2. Ein DS-Eintrag, kurz für Delegation Signer, ist der in der übergeordneten Zone veröffentlichte kryptografische Verweis auf das Schlüsselmaterial der untergeordneten Zone.

Dieser Eintrag ist wichtig, aber nicht hinreichend, um einen erfolgreichen Dauerbetrieb nachzuweisen. Für eine funktionierende Validierung müssen DS-Daten in der übergeordneten Zone und DNSKEY-Daten in der untergeordneten Zone korrekt aufeinander abgestimmt sein. Bei einem Schlüsselwechsel müssen alter und neuer Zustand in der richtigen Reihenfolge und für passende Zeiträume veröffentlicht werden. Ein Fehler in Zeitplanung, Freigabe oder Ausführung kann dazu führen, dass validierende Resolver Antworten nicht mehr akzeptieren.

Die Quellen berichten nicht, dass ein solcher Fehler bei .icbc eingetreten wäre. Das Szenario beschreibt lediglich eine allgemeine Fehlerart, die bei der Kontrolle einer signierten Zone berücksichtigt werden muss. Ein öffentlich sichtbarer DS-Eintrag belegt das Vorhandensein eines Sicherheitsankers zu einem bestimmten Zeitpunkt. Er belegt weder erfolgreiche frühere Schlüsselwechsel noch die Reife eines internen Rollback-Verfahrens.

Die Beobachtung nennt außerdem einen SOA-Eintrag. SOA steht für Start of Authority und bezeichnet einen zentralen Zonendatensatz, der unter anderem den primären Server sowie Zeitparameter für den Betrieb der Zone angibt. Für .icbc wird a.zdnscloud.com. als primärer Server genannt; als verantwortliche Mailbox erscheint td_dns_gtld.knet.cn.. Veröffentlicht sind außerdem die Seriennummer 1386050294 sowie die Werte 600 für Refresh, 3600 für Retry, 1209600 für Expire und 3600 für Minimum.

Solche Werte können als Marker für einen beobachteten Sollzustand dienen. Wenn sich die Seriennummer, der primäre Server, die Kontaktangabe oder ein Timer verändert, ist die Änderung nicht automatisch problematisch. Entscheidend wäre, ob sie erwartet, genehmigt und nach der Veröffentlichung überprüft wurde. Das öffentliche DNS zeigt das sichtbare Ergebnis, aber nicht den Freigabeweg, die Tests oder die Entscheidung, eine Änderung bei Bedarf zurückzunehmen.

Für nic.icbc wurden sechs IPv4- und sechs IPv6-Adressen beobachtet. Auch diese Adresszahlen sind Momentaufnahmen. Sie beweisen nicht, dass jede Adresse jederzeit erreichbar ist, dass Verkehr gleichmäßig verteilt wird oder dass eine bestimmte Ausfallsicherungsstrategie erfolgreich funktioniert. Für eine solche Bewertung wären Messungen von verschiedenen Standorten, dokumentierte Fehlerzustände, Zeitreihen und Kenntnisse über die Systemarchitektur notwendig.

Neben der DNSSEC-Kette muss die Delegation insgesamt konsistent bleiben. Dazu gehören die Nameserverdaten in der übergeordneten Zone, die NS-Einträge in der untergeordneten Zone und gegebenenfalls sogenannte Glue-Daten – also Adressinformationen, die benötigt werden, um bestimmte Nameserver ohne zirkuläre Abhängigkeit zu finden. Abweichungen zwischen diesen Ebenen können zu inkonsistenter Namensauflösung führen. Die Quellen enthalten keinen Nachweis, dass eine solche Abweichung bei ICBC besteht.

Die Wartung dieser Ebene ist vor allem eine Koordinationsaufgabe. Verantwortliche müssen wissen, welcher Zustand erwartet wird, wer Änderungen beantragen darf, wie lange DNS-Caches alte Daten halten und welche Beobachtungen nach einer Änderung erforderlich sind. Bei DNSSEC kommen Schlüsselzeiträume, kryptografische Rollen und eine besonders sorgfältige Reihenfolge hinzu. Ein technisch richtiger Zielzustand reicht nicht, wenn der Übergang falsch geplant ist.

WHOIS und RDAP bilden eine zweite technische Kontrollfläche. WHOIS liefert traditionell unstrukturiertere Textantworten. RDAP verwendet definierte HTTP-Ressourcen und strukturierte Daten. Für .icbc sind ein RDAP-Hilfeendpunkt und ein Domainendpunkt für nic.icbc öffentlich erreichbar. Damit ist eine sichtbare Registrierungsdatenschnittstelle belegt.

Erreichbarkeit ist jedoch nicht gleich Datenqualität. Registrierungsstatus, Ereigniszeitpunkte, Registrarverweise, Kontakte und Hinweise könnten theoretisch zwischen WHOIS, RDAP und internen Systemen auseinanderlaufen. Das wäre nicht zwingend als DNS-Ausfall sichtbar, könnte aber Sicherheitsreaktionen, rechtliche Zuordnung oder technische Fehleranalyse erschweren. Auch hier weisen die Quellen keine konkrete Abweichung bei ICBC nach.

Für die Aufsicht ist deshalb entscheidend, ob beide öffentlichen Schnittstellen aus einem gemeinsamen maßgeblichen Datensatz erzeugt oder regelmäßig miteinander abgeglichen werden. Außerdem müsste klar sein, wer über Korrekturen entscheidet, wie Abweichungen dokumentiert werden und innerhalb welcher Frist sie behoben werden. Der öffentliche RDAP-Endpunkt beantwortet diese Governance-Fragen nicht.

Eine weitere Ebene betrifft die Datenhinterlegung und einen möglichen Notfallübergang. Vertragliche Registry-Pflichten können verlangen, dass Daten so hinterlegt werden, dass bei schwerwiegenden Betriebsproblemen ein Übergang unterstützt werden kann. Das Vorhandensein einer Pflicht ist aber noch kein getesteter Wiederherstellungsprozess. Für einen glaubwürdigen Übergang müssten Domainobjekte, Statuswerte, Kontakte, Hostobjekte, Registrarzuordnungen und Sicherheitsdaten vollständig und verständlich vorliegen.

Fehlerhafte oder veraltete Hinterlegungsdaten könnten eine Übergabe erschweren, selbst wenn formal regelmäßig Dateien erzeugt werden. Nicht erreichbare Kontakte könnten Berechtigungsentscheidungen verzögern. Unklare Zuständigkeiten für DNSSEC-Schlüssel könnten eine Wiederherstellung riskanter machen. Die öffentlichen Quellen belegen weder solche Probleme bei .icbc noch einen erfolgreich getesteten Übergang. Sie zeigen lediglich, dass Kontinuität mehr verlangt als eine laufende DNS-Antwort.

Auch Zertifikate, Schlüssel, Zugangsdaten und Betriebskontakte haben Lebenszyklen. Ein abgelaufenes Zertifikat, ein nicht mehr verfügbares Konto oder eine veraltete Kontaktadresse kann eine ansonsten korrekte technische Plattform in einem Ausnahmefall blockieren. Deshalb gehört zur Wartung nicht nur die Kontrolle von Live-Datensätzen, sondern auch die regelmäßige Prüfung der Mittel, mit denen diese Datensätze geändert werden können.

Die monatlichen Berichtszähler bilden schließlich eine eigene technische und organisatorische Schnittstelle. Sie müssen erfasst, zugeordnet, geprüft und eingereicht werden. Wenn ein Antwortzähler über einem Empfangszähler liegt, sollte die erste Reaktion nicht die Berechnung einer Erfolgsquote sein, sondern die Frage nach Definitionen und Erfassungsgrenzen. Eine Berichtsanomalie ist nicht automatisch eine Dienststörung; umgekehrt kann ein plausibler Bericht eine Störung nicht ausschließen.

Eine belastbare interne Kontrolle würde deshalb zwischen Mess- und Berichtssystem unterscheiden. Sie würde klären, welche Daten für die Vertragserfüllung aggregiert werden, welche Daten für operative Alarmierung dienen und welche externen Messungen die tatsächliche Erreichbarkeit beobachten. Die öffentlichen Dateien geben Einblick in die erste Kategorie, nicht in die vollständige operative Überwachung.

Sources

  1. https://btw.media/en/directory/industrial-and-commercial-bank-of-china-limited
  2. https://btw.media/zh/directory/industrial-and-commercial-bank-of-china-limited
  3. https://www.iana.org/domains/root/db/icbc.html
  4. https://www.iana.org/reports/c.2.9.2.d/20150511-icbc
  5. https://www.iana.org/reports/tld-transfers/gtld-readiness-1-1010-74163.pdf
  6. https://www.icann.org/en/registry-agreements/details/icbc
  7. https://itp.cdn.icann.org/en/files/registry-agreements/icbc/icbc-spec13-19feb15-en.pdf
  8. https://itp.cdn.icann.org/en/files/registry-agreements/specification-13-global-amendment-07-08-2023-en.html
  9. https://www.icann.org/resources/pages/icbc-2015-09-01-en
  10. https://www.icann.org/sites/default/files/mrr/icbc/icbc-transactions-202601-en.csv
  11. https://www.icann.org/sites/default/files/mrr/icbc/icbc-activity-202601-en.csv
  12. https://www.icann.org/sites/default/files/mrr/icbc/icbc-activity-202512-en.csv
  13. https://www.icann.org/sites/default/files/mrr/icbc/icbc-activity-202501-en.csv
  14. https://www.icann.org/sites/default/files/mrr/icbc/icbc-activity-202401-en.csv
  15. http://www.icbc.com.cn/ICBC/%E5%9F%9F%E5%90%8D%E6%B3%A8%E5%86%8C%E5%B1%80/default.htm
  16. https://rdap.zdnsgtld.com/icbc/help
  17. https://rdap.zdnsgtld.com/icbc/domain/nic.icbc
  18. https://v.icbc.com.cn/userfiles/resources/icbcltd/download/2026/2025AnnualReport.pdf