Primäre Domain
DNS
Innerhalb der Facette Primäre Domain bündelt DNS die Berichterstattung nach primärem Themenbereich, sodass Leser einen fokussierten Bereich der Internetinfrastruktur, Governance, Konnektivitätsmärkte oder des digitalen Kapitals verfolgen können. Die Seite führt verwandte Artikel, öffentliche Belege, Institutionen, Unternehmen, Personen, regionale Verflechtungen, operative Abhängigkeiten und Marktkontext zusammen, die sonst über verschiedene Kategorieseiten verstreut wären. Sie erläutert den Themenbereich, die wahrscheinliche Akteursgruppe, den Markt- oder Governance-Kontext und das Quellenmaterial, das Leser beim Vergleich von Signalen heranziehen sollten. Betreiber, Analysten und mit Governance befasste Leser können erkennen, wie derselbe Themenbereich in Ereignissen, Profilen, Marktveränderungen, Belegen aus öffentlichen Quellen, regionalen Abhängigkeiten und langfristigen Infrastrukturentscheidungen immer wieder auftaucht.
IETF
Eine Nummer ist noch keine Vertrauenskette
RFC 9563 gibt SM2-Signaturen und SM3-Digests eindeutige DNSSEC-Kennungen. Damit ist das Format benennbar. IETF-Konsens, kryptografische Eignung, Validator-Unterstützung und eine authentifizierte Namensauflösung folgen daraus nicht.
IETF
Der Ersatzserver antwortete. Der Cache kannte seinen Schlüssel nicht: RFC 8901
Ein zweiter autoritativer DNS-Anbieter kann nach dem Ausfall des ersten weiter antworten und trotzdem keine für validierende Resolver brauchbare Antwort liefern. RFC 8901 beschreibt DNSSEC-Redundanz als Synchronisationsvertrag zwischen Signierern, nicht als Zahl von Nameservern.
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…
Fallakte
Wenn ein BIND-Fix noch keine belastbare Reparatur ist
ISC veröffentlicht für schwerwiegende BIND-Schwachstellen Abhilfe. Die offene Frage beginnt danach: Können Betreiber ihre Betroffenheit nachweisen, den Fix tatsächlich ausrollen und die wiederhergestellte Resolver-Resilienz unter realer Belastung überprüfen?
IETF
James Gould und das Schwärzungssignal, das keine Richtlinie beweist
Wenn in einer RDAP-Antwort ein Feld fehlt, sieht das Ergebnis eindeutig aus: Dort steht nichts. Die Entstehungsgeschichte bleibt jedoch offen. Vielleicht gab es nie einen Wert; vielleicht hält der Server ihn nur für diesen Client zurück. RFC 9537, mitverfasst von James Gould…
Fallakte
Wer darf die nächste interne Zone anlegen?
Eine öffentliche DNS-Zone kann eine interne Namensauflösung bestätigen, ohne das interne Namensverzeichnis offenzulegen. RFC 9704 macht daraus eine präzise technische Vereinbarung. Wie weit diese Vereinbarung reicht, entscheidet aber darüber, welche Änderungen später noch eine…
IETF
Suzanne Woolf und das Serveretikett, das keine Maschinenidentität ist
Liefert eine DNS-Antwort eine Serverkennung mit, wirkt die Identitätsfrage zunächst gelöst. In Anycast-Netzen, hinter Lastverteilern und bei frei gewählten Betreiberwerten wäre diese Schlussfolgerung jedoch zu groß. Der von Suzanne Woolf mitverfasste RFC 4892 legt eine…
IETF
Sara Dickinson und das Resolver-Versprechen, das Verschlüsselung nicht belegen kann
Ein verschlüsselter DNS-Kanal schließt Beobachter auf dem Weg aus. Am Ende des Kanals steht jedoch ein Resolver, der die Frage lesen muss. RFC 8932, an dem Sara Dickinson mitgewirkt hat, lenkt den Blick auf diesen Moment: Welche Daten werden gespeichert, zusammengeführt…
ICANN
Allison Mankin und die Namenskollisions-Stichprobe, die ihre Ursache nicht bewies
Eine Root-Messung kann Name, Query-Typ und Zeitpunkt exakt festhalten. Sie kennt deshalb noch nicht die Anwendung, den verantwortlichen Betreiber oder den Schaden einer späteren Delegation. Der von Allison Mankin mitverfasste RFC 8023 macht aus dieser Lücke eine überprüfbare…
Fallakte
Der Schlüssel war bekannt, aber noch nicht vertrauenswürdig
Ein selbst signiertes DNS-Update bringt dem Elternbereich einen neuen Schlüssel und zugleich den Auftrag, den alten zu löschen. Die Signatur belegt Besitz des neuen privaten Schlüssels. Sie belegt nicht das Recht, die Delegation des Kindes zu ändern. Am angekündigten Ende des…
Fallakte
Der letzte Punkt verschwand – und die Vertrauensgrenze wanderte
Für das DNS können `example.co.uk` und `example.co.uk.` zum selben Knoten führen. In einer Anwendung können beide Schreibweisen dennoch unterschiedliche Sicherheitsentscheidungen auslösen. Zum Ende des DNSOP Working Group Last Call am 7. September macht eine aktuelle…
IETF
QNAME-Minimierung ist eine Abfragesequenz, kein Datenschutzschalter
Ein Resolver kann QNAME-Minimierung melden und dennoch je nach Cachezustand unterschiedliche Namen, Kosten und Fehler nach außen geben. Der belastbare Gegenstand ist keine Ja-Nein-Funktion, sondern die begrenzte Abfragefolge aus bekanntem Delegationswissen, negativen Antworten…
Fallakte
DNS erhielt den Hinweis. Der Parent musste dennoch entscheiden: Die Delegationsgrenze von RFC 9859
RFC 9859 kann die Prüfung einer Delegationspflege vorziehen. Aus einer Benachrichtigung macht sie weder eine Entscheidung des Parent noch aus einer Antwort einen Nachweis einer veröffentlichten DS-Änderung.