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.
IETF
Ein Löschbefehl kann die Domain eines anderen beschädigen: RFC 9874 und die Kontrolle von EPP-Abhängigkeiten
Eine zerstörerische Änderung im Lebenszyklus eines EPP-Objekts bleibt nicht zwangsläufig auf den anfordernden Kunden beschränkt. Ist ein untergeordneter Host noch mit Domains verknüpft, die von anderen Kunden gesponsert werden, kann seine Löschung DNS-Abhängigkeiten verändern…
Fallakte
Beklagte waren sechzig Domainnamen; den Anspruch bestimmte weiter das Gesetz: Harrods v Sixty Internet Domain Names
Die Überschrift des Verfahrens kehrte das gewohnte Bild um: Beklagte waren keine Personen, sondern sechzig Domainnamen. Das *in-rem*-Verfahren des ACPA eröffnete einen Weg zum Gericht, als gegenüber dem Registranten keine persönliche Gerichtsbarkeit begründet werden konnte. Es…
IETF
ZONEMD lässt den Secondary die Zone nach Abschluss der Übertragung prüfen
Eine abgeschlossene Zonenübertragung beweist, dass der Lieferprozess beendet wurde. Sie beweist für sich allein nicht, dass der Empfänger genau jene vollständige Zone zusammengesetzt hat, die der Herausgeber veröffentlichen wollte. ZONEMD ergänzt einen Digest über die gesamte…
ICANN
Ein Anbieter, zwei Namensprüfungen: ICANN trennt die Gebühren
Analysys Mason übernimmt die Panels für geografische und reservierte Namen. Für Antragsteller bleibt entscheidend, welche Leistung die Grundgebühr deckt und welche Prüfung zusätzlich berechnet wird.
IETF
Ein negativer Vertrauensanker lässt den Resolver DNSSEC aussetzen, ohne die Zone zu ändern
Wenn eine signierte Zone fehlerhaft ist, kann ein validierender Resolver den Ausfall bestehen lassen oder eine eng begrenzte lokale Ausnahme öffnen. Ein negativer Vertrauensanker stellt die Erreichbarkeit wieder her, ohne die Zone zu reparieren. Dafür erhält der…
ICANN
ccNSO trennt begründete IDN-Nachfragen von laufender Kontrolle
Die im Juli beschlossene Antwort erlaubt gezielte Rückfragen bei einem vernünftigen Anlass. Sie soll ICANN keine dauernde Compliance-Aufsicht übertragen. Im September steht der nächste Schritt für ccPDP4 auf der Agenda des Boards.
ICANN
Eine ISO-Änderung kann den Ausstieg eines IDN-ccTLD auslösen. Sie gibt ICANN kein Territorialurteil.
Ein Koordinierungssystem darf externe Tatsachen verwenden, ohne zu ihrem Richter zu werden. Gerade bei Länder- und Gebietsbezeichnungen ist diese Grenze entscheidend: Ein späterer Betriebsvorgang darf nicht so erscheinen, als habe der Betreiber die politische Tatsache selbst…
Fallakte
Die Kennung wurde aufgelöst. Das Luftfahrzeug wurde nicht geortet: RFC 9886
RFC 9886 macht einen DRIP Entität Tag im DNS auffindbar. Die Antwort stammt jedoch aus einem Kennungsregister, nicht von einem Luftlage-Sensor. Ein geprüftes HHIT-Zertifikat und BRID-Endorsements belegen Registrierung; Standort, aktuelle Schlüsselkontrolle, privater…
Geschichte
Die Codes passten zusammen. Die Verbindung brauchte weiterhin Erlaubnis: RFC 1394
Ein Verzeichnis konnte Telefonvorwahl, Telex-Code, Answerback und Internet-Domain eines Landes zusammenführen. Es konnte keinen einzigen Übertragungsweg öffnen. RFC 1394 machte diese Trennung ungewöhnlich deutlich: Die Zuordnung half bei der Suche, während Richtigkeit…
ICANN
ICANNs Plan für diakritische Zeichen bindet auch den Anbieterwechsel
Bestimmte ASCII-Endungen und ihre Schreibweisen mit lateinischen diakritischen Zeichen sollen gemeinsam betrieben werden können. Der Abschlussbericht des GNSO verbindet diese Ausnahme mit dauerhaft gekoppelten Übergängen. Für Registerbetreiber wird damit nicht nur der Einstieg…
Geschichte
Der Domain-Eintrag verwies auf die Organisation, war aber nicht die Organisation: RFC 1279
Zwei Kopien derselben Telefonnummer schaffen zwei Uhren. Sobald nur eine aktualisiert wird, sehen beide Werte noch korrekt aus, aber nur einer beschreibt die Gegenwart. RFC 1279 begegnete diesem Problem beim Versuch, DNS-Domains und Organisationsdaten in X.500 zusammenzuführen.…
IETF
Wes Hardaker und der DNS-Server, der zwei TTLs überleben musste
Ein alter Nameserver kann betrieblich noch gebraucht werden, obwohl fast niemand ihn mehr fragt. Entscheidend ist nicht der ruhige Graph, sondern ob irgendwo noch ein gültiger Cacheeintrag auf ihn zeigt.
Geschichte
Der Name war lokal. Die Nummer brauchte dennoch einen Eintrag: Die DNS-Zuordnungsgrenze von RFC 1101
1989 verteilte das DNS bereits Hostinformationen, doch es gab noch keinen standardisierten Weg, von einer Netznummer nach dem Namen des Netzes zu fragen. RFC 1101 schlug eine kleine Antwort vor: PTR-Einträge, Host-null-Namen in `IN-ADDR.ARPA` und bei Bedarf Masken. Die bleibende…
IETF
Tobias Fiebig und die vier DNS-Erreichbarkeitsnachweise
Bei einer Normprüfung entscheidet oft ein einziges Verb. RFC 10001 sagt nicht nur, eine Zone solle Adressen für beide Familien veröffentlichen. Sie muss von mindestens zwei über IPv4 und zwei über IPv6 erreichbaren autoritativen Servern bedient werden. Aus dem Konfigurationsaudit…
Geschichte
Der Namensdienst war fast ein Verhandler: Wie RFC 830 Domänen und Fähigkeiten trennte
RFC 830 wollte die internen Datenbanken nicht vereinheitlichen, beschrieb aber die Gespräche zwischen Anwendung, AIP und DNS bis auf typisierte Felder. Das wirkt verkehrt, wenn Standardisierung mit identischer Speicherung gleichgesetzt wird. Tatsächlich lag die gemeinsame Grenze…
IETF
David Lawrence und die DNS-Antwort, die ihren TTL überlebte
Der TTL einer DNS-Antwort ist abgelaufen, doch der autoritative Pfad liefert nicht rechtzeitig einen brauchbaren Ersatz. RFC 8767 erlaubt dem rekursiven Resolver eine eng begrenzte Überbrückung: zuerst ehrlich aktualisieren, den Fehlschlag bestimmen, die alte Kopie kurz ausgeben…
IETF
Steve Sheng und die Sperre, die die DNSSEC-Wartung nicht stoppte
Ein Domain-Portal kann „gesperrt“ anzeigen, während sich der DS-Satz in der übergeordneten Zone rechtmäßig ändert. RFC 10026 löst den scheinbaren Widerspruch auf, indem er nach dem tatsächlichen Geltungsbereich fragt: Wer setzte die Sperre, wessen Befehl weist sie zurück, und…
IETF
Peter Thomassen und das Update, das jeden autoritativen Server brauchte
Eine DNS-Antwort kann technisch einwandfrei und trotzdem keine ausreichende Grundlage für eine Änderung im Parent sein. Peter Thomassens RFC 9975 verlangt deshalb nicht die schnellste Antwort, sondern ein plausibel einheitliches Bild des gesamten delegierten autoritativen…
Fallakte
Im DNS stand „zu verkaufen“. Die Verfügungsbefugnis stand dort nicht
RFC 10023 macht die Verhandlungsbereitschaft eines Domaininhabers auffindbar, ohne den laufenden Namen stillzulegen. Das Signal ist ein guter Ausgangspunkt — solange es nicht als Eigentumsnachweis, Vollmacht oder vollzogener Verkauf ausgegeben wird.
Fallakte
Die Richtlinie verlangte zwei Wege. Der Betrieb bewies nur einen: RFC 10001 und DNS-Kontinuität
RFC 10001 kann eine technische Mindestanforderung formulieren. Es kann nicht beweisen, dass ein bestimmter Registrar sie prüft, ein Anbieter sie umgesetzt hat oder ein Resolver beide Pfade tatsächlich erreicht. Diese Trennung zwischen Norm, Verfahren und laufendem Ergebnis ist…