Thema
DNS-Delegationsmacht
Innerhalb der Facette Thema verbindet die Themenanalyse DNS-Delegationsmacht Artikel, die ein gemeinsames Thema, einen Signalfokus oder ein Monitoring-Thema teilen. Die Seite bietet den Lesern einen umfassenderen Zugang zu verwandter Berichterstattung, Quellenbelegen, Marktakteuren und Infrastrukturfolgen – mit ausreichend Kontext, um zu verstehen, warum das Thema für Unternehmensaktivitäten, Governance-Entscheidungen, regionale Risikoexposition und operationelle Risiken relevant ist. Leser können wiederkehrende Signale, betroffene Organisationen, öffentliche Belege, Marktkontext, Servicekontinuität, Beschaffung, Wettbewerb, Compliance und strategische Planungsfragen hinter dem Thema vergleichen, statt bei einer dünnen Liste passender Artikel stehenzubleiben. Es erklärt, was das Thema abdeckt, welche Infrastrukturakteure oder -politiken beteiligt sind, welche Belege die Berichterstattung stützen und warum das Thema für Betreiber, Kunden, Investoren und politisch interessierte Leser von Bedeutung sein kann.
Berichte
RIPE NCC behielt die Prüfungen fehlerhafter Delegierungen bei und stoppte die E-Mails
2009 beendete RIPE NCC nicht die technische Beobachtung. Die regelmäßigen Prüfungen fehlerhafter DNS-Delegierungen liefen weiter, während die massenhaft versandten Warn-E-Mails eingestellt wurden. Der historische Fall zeigt, warum Erkennung, Zustellung, betriebliche…
ICANN
Der Hold von autistici.org hat einen Zeitstempel, aber keinen öffentlichen Entscheidungsbeleg
Das RDAP von PIR zeigt den `serverHold` und den exakten Änderungszeitpunkt. Nicht sichtbar ist, wer die US-Sanktionsentscheidung in eine registerweite Maßnahme übersetzte, auf welcher Grundlage dies geschah, warum die Maßnahme vor Ablauf der Abwicklungslizenz wirkte und welche…
ICANN
ICANNs Autoritätskette: Wie Regeln zu Pflichten werden – und was eine Anfechtung bewirken kann
ICANN koordiniert Internetkennungen nicht über ein einziges regulatorisches Mandat. Ihre praktische Autorität entsteht vielmehr aus einer Kette von Gründungs- und Verfassungsdokumenten, gemeinschaftlich entwickelten Policies, Verträgen mit Registries und Registraren…
Globale Cloud-Dienste
Genesis Cloud: Routing, Peering und DNS zeigen noch keine durchgängige Betriebskette
Die öffentlichen Spuren von Genesis Cloud lassen sich in mehrere technische Ebenen zerlegen: eine AS-Registrierung, beobachtbare Routen, deklarierte Peering-Beziehungen, DNS-Delegation sowie öffentlich erkennbare API- und Status-Endpunkte. Entscheidend ist jedoch die Lücke…
ICANN
ICANNs Autoritätskette: Instrumente, Verträge und Rechtsbehelfe
ICANNs operative Macht stammt nicht aus einem einzigen Mandat. Sie wird durch Gründungsdokumente, Satzungsregeln, Verfahren zur Entwicklung von Konsensrichtlinien, Verträge und unterschiedliche Rechenschaftsmechanismen verteilt. Für Betroffene ist deshalb entscheidend, zuerst die…
Berichte
APNICs Lauf mit zwei Nameservern hatte weniger Wiederholungen – für die Ursache fehlt noch der Reproduktionsbeleg
APNIC beobachtete in einem späteren Versuch mit zwei autoritativen Nameservern weniger DNS-Abfragen als zuvor mit einem. Der Unterschied ist in den veröffentlichten Summen klar; seine Ursache ist es nicht. Für eine belastbare Entscheidung müssen beide Varianten dieselbe…
Geschichte
RFC 2065: Der DNS-Server lieferte Daten, aber nicht das Urteil
RFC 2065 entwarf 1997 DNS-Sicherheit für eine ungleichzeitig modernisierte Welt. Ein gewöhnlicher Server konnte signierte Ressourcensätze weiterreichen, obwohl er ihre Kryptografie nicht verstand. Der sicherheitsbewusste Resolver prüfte selbst. Damit lag Vertrauen nicht mehr…
Berichte
AFRINICs Anycast-Knoten in Uganda vereint zwei Dienste, nicht nur einen
Die Analyse-Zusammenfassung zu AFRINICs Anycast-Knoten in Uganda vereint zwei Dienste, nicht nur einen erläutert die Entwicklung, die öffentlich zugänglichen Belege, die beteiligten Organisationen, den regionalen Kontext, die Marktexposition und die möglichen…
ICANN
ICANNs Integration alternativer Namenssysteme braucht eine überprüfbare Abschaltung
Der erste Bericht von ICANN verlangt für die Verbindung einer gTLD mit einem anderen Namenssystem einen verpflichtenden Abschaltplan. Das ist besonders wichtig, weil die zusätzliche Integration wohl nicht zum Notfallumfang von EBERO gehört. Ein Plan belegt jedoch noch nicht, dass…
Berichte
AFRINICs ccTLD-Test setzt einem Land keine IPv6-Grenze
Die Prüfung der Registry-Nameserver ist sinnvoll. Aus ihrem Ergebnis folgt aber nicht, dass sämtliche darunterliegenden Websites über IPv6 unerreichbar sind. Ein rekursiver Resolver kann einen anderen Transportweg nehmen.
IETF
DNS ANY sollte nach Zweck statt nur nach Abfragecode auslaufen
Ein DNS-Server kann eine mehrdeutige Abfrage in einer Veröffentlichung abweisen. Die Aufgaben, für die Clients sie verwendeten, verschwinden damit nicht. Ein belastbarer Rückzug braucht ausdrücklich benannte Zwecke, geprüfte Ersatzwege und befristete Ausnahmen mit…
IETF
Ein ULD-Serverwechsel muss den Fortbestand lokaler Dienste belegen
Nach einem Routertausch kann das Netz tadellos wirken: Internetzugang vorhanden, neuer Discovery-Server erreichbar, Clients umgeschaltet. Erst beim Drucken fällt auf, dass ein lokaler Dienst fehlt. Die Serverwahl war womöglich korrekt. Bewiesen ist damit aber nur die Wahl…
IETF
Die Zone antwortet noch, aber die Uhr läuft: DNSSEC nach dem Verlust eines privaten Schlüssels
Ein unbrauchbar gewordener DNSSEC-Privatschlüssel muss nicht sofort zu sichtbaren Ausfällen führen. Eine vollständig vorsignierte Zone kann weiterhin korrekte Antworten mit noch gültigen RRSIGs ausliefern. Gerade diese Ruhe ist gefährlich: Sie belegt weder die Wiederherstellung…
IETF
DANCE 14 führt vier TLSA-Ergebnisse in eine Serverentscheidung mit zwei Wegen
Ein abgebrochener TLS-Handshake verrät nicht, ob der Clientname fehlte, nur der TLSA-Typ fehlte, die Delegation ungesichert war oder die Validierung scheiterte. Revision 14 des DANCE-Entwurfs schreibt diese vier Eingänge erstmals ausdrücklich nebeneinander. Danach darf dieselbe…
IETF
EDE 33 kann eine NTA anzeigen, ohne ihre Wirkung auf die Antwort zu belegen
Für EDE 33 laufen zwei Uhren. IANA hat die Zahl bereits einer Negative Trust Anchor zugeordnet. DNSOP berät noch, ob die Arbeitsgruppe das erläuternde Dokument übernimmt. Im Paket selbst läuft eine dritte Uhr: Der Code beschreibt den Zustand beim Erzeugen der Antwort, aber nicht…
Berichte
Aus vier veralteten IPv6-Glue-Einträgen bei RIPE NCC wurden drei — denn die Root-Zone wird nicht im Paket repariert
Bei `.ps` stimmen Root-Glue und aktuelle Serveradresse inzwischen überein. Bei `.ne`, `.sd` und `.tj` bleibt die Abweichung bestehen. Das geteilte Ergebnis legt die tatsächliche Arbeitseinheit offen: Jede Delegation braucht eine eigene Autorisierung und einen eigenen Abschluss.
Geschichte
Gihan Dias und Sri Lankas zwei Namen in der Root-Zone
Ein Land kann technisch vernetzt sein und im Namensraum des Netzes dennoch nur unvollständig vorkommen. Gihan Dias’ Weg von sparsamem Wählleitungs-E-Mail bis zur Verantwortung für `.LK` zeigt, warum Sri Lanka nach der Verbindung noch zwei eigene Schriften in die DNS-Root bringen…
Berichte
LACNIC signiert 150 Reverse-DNS-Dateien – ein Batch-Manifest fehlt
Für jede Datei liegt ein eigener kryptografischer Umschlag bereit. Was dem öffentlichen LACNIC-Verzeichnis fehlt, ist ein signiertes Inhaltsverzeichnis, das aus 150 Einzelstücken einen nachvollziehbaren Veröffentlichungsstand macht.
Geschichte
Demi Getschko und der Ländercode, der vor Brasiliens TCP/IP kam
Am 18. April 1989 stand `.br` bereits in der DNS-Wurzel. Brasiliens Wissenschaftsnetze kommunizierten zu diesem Zeitpunkt über BITNET, HEPnet und andere Systeme; erst im Januar 1991 tauschte FAPESP den ersten internationalen TCP/IP-Verkehr des Landes aus. Demi Getschkos…
Berichte
AFRINICs ccTLD-Karte zählt 27. Drei brauchen den Adressabgleich.
Die veröffentlichte Summe hält einer Prüfung stand, doch eine Namenssuche reicht dafür nicht aus. Bei 24 Delegationen steht AFRINIC im Hostnamen. Bei .so, .ng und .ml wird die NS2-Beziehung erst sichtbar, wenn die Adressen mit den publizierten Anycast-Präfixen verbunden werden.