Zusammenfassung

  • Am 3. September 2026 eröffnete die IESG die Gemeinschaftsprüfung eines vorgeschlagenen neuen DNSSD-Charters; Stellungnahmen sind bis 13. September möglich. Die Mitteilung hält ausdrücklich fest, dass noch keine Entscheidung getroffen wurde.
  • Der Entwurf umfasst die Veröffentlichung von SRP-registrierten Namen in mDNS und konkurrierende Aktualisierungen desselben Namens. draft-ietf-dnssd-tsr-03, für den im November ein Working Group Last Call geplant ist, ordnet Kopien redundanter Proxys nach Quelle und Empfangsalter. Daraus entstehen keine Authentisierung, Vertraulichkeit oder Dienstgarantie.

Ein Gerät registriert einen Dienst über Registrar A. Dieser arbeitet zugleich als Advertising Proxy und sendet den Datensatz auf einen mDNS-Link. Nach einer Partition erreicht das nächste SRP Update Registrar B. Der Dienst hat eine neue Adresse; Proxy A sendet die vorige weiter.

Für mDNS wirken beide RRsets wie konkurrierende Behauptungen unter demselben Owner Name. Normalerweise gewinnt der ältere Eintrag. Das schützt einen bereits sichtbaren Drucker oder eine Anwendung davor, dass ein später Teilnehmer denselben Namen übernimmt. In diesem Fall vertreten die Proxys aber keine zwei Eigentümer. Sie besitzen zwei Zeitstände derselben Quelle.

Damit wird Dauer zum Fehlerindikator: Der alte Datensatz gewinnt, weil seine Entfernung noch nicht angekommen ist.

Die IESG-Mitteilung vom 3. September bittet bis 13. September um Kommentare zum vorgeschlagenen DNSSD-Charter. Dieser nennt skalierbare Dienstsuche über einzelne und mehrere Links, die Veröffentlichung von SRP-Namen über mDNS sowie Konflikte zwischen Aktualisierungen desselben Namens.

Die IESG sagt zugleich, dass sie noch keine Bestimmung getroffen hat. Ein Recharter-Entwurf ist keine genehmigte Arbeitsordnung. Der geplante WGLC im November ist kein vorhandener Konsens. Der TSR-Datatracker führt Version 03 als aktiven Standards-Track-Internet-Draft, nicht als RFC. Auch der Wunsch nach einem EDNS-Code ist noch keine IANA-Zuteilung.

RFC 6762 erklärt die Ausgangslogik. Multicast DNS hat auf dem lokalen Link keinen einzelnen autoritativen Server. Anders als im delegierten DNS nach RFC 1034 muss mDNS durch Probes und Konfliktregeln entscheiden, welcher Name bestehen bleibt. RFC 6763 verwendet DNS-Datensätze zur Beschreibung von Diensttypen und Instanzen.

Spätere Bausteine überbrücken Namensräume. RFC 8766 beschreibt einen Discovery Proxy, der per mDNS gelernte Dienste über Unicast DNS bereitstellt. RFC 9665 definiert SRP, bei dem ein Requester ein an seinen Schlüssel gebundenes Update an einen Registrar schickt. Der Advertising-Proxy-Entwurf veröffentlicht SRP-Daten zurück in mDNS.

Nun spricht der sichtbare Sender nicht mehr für sich selbst. Der Requester ist Ursprung, der Registrar verwaltet, der Proxy projiziert. Wechselt der Requester nach einer Störung zum zweiten Registrar, kann die erste Projektion als veralteter Zustand zurückbleiben.

Der TSR-Text der Version 03 schlägt dafür eine Time-Since-Received-EDNS-Option pro Owner Name vor. Sie verweist auf die betroffenen Resource Records, enthält eine aus dem öffentlichen Requester-Schlüssel abgeleitete Prüfsumme und übermittelt die seit dem Empfang verstrichene Zeit. Der Empfänger berechnet daraus eine lokale absolute Vergleichszeit.

Die Prüfsumme trennt Quellen; die Zeit trennt Generationen derselben Quelle. Zwei Proxys mit demselben Schlüsselbezug können erkennen, dass die neuere SRP-Information keine fremde Namensübernahme ist. Das vermeidet unnötige Umbenennungen, Probes und Antworten. Es verhindert außerdem, dass der Rückzug eines Proxys per Goodbye eine Kopie löscht, die über einen anderen noch gültig ist.

Die Zeit ist trotzdem kein Eigentumsnachweis. Netzlatenz beeinflusst den Offset. Ein Neustart kann eine neue Beobachtungsepoche schaffen. Verliert ein System die Zuordnung zwischen Schlüssel und RRset, fehlt die Grundlage des Vergleichs. Primary- und Secondary-Rollen steuern redundante Antworten, nicht die organisationsweite Berechtigung am Namen.

RFC 6891 liefert das erweiterbare EDNS-Format. Ein gemeinsamer Drahtaufbau macht Implementierungen vergleichbar; er attestiert weder Uhr noch Cache noch Persistenz eines bestimmten Produkts.

Die Sicherheitsgrenze ist ausdrücklich eng. Laut TSR kann ein bösartiger Host auf demselben Link Konflikte beeinflussen. Auch ohne TSR kann er widersprüchliche Daten ankündigen und Probes beantworten, um einen Dienst zu stören. Protokolle dürfen mDNS nicht als sicher oder privat voraussetzen. Authentisierung, Autorisierung und Vertraulichkeit müssen auf Anwendungsebene oder gegebenenfalls durch DNSSEC-gestützte Suche entstehen.

RFC 8882 beschreibt, wie Dienstsuche Geräte, Angebote und Aktivität offenlegen kann. Eine Ausweitung über Links vergrößert den Kreis der Beobachter. Der frischeste Datensatz kann technisch richtig und politisch am falschen Ort sichtbar sein.

Eine belastbare Betriebsakte enthält Requester und Schlüssel, das ursprüngliche SRP Update, Registrar, Advertising Proxy, Owner Name, vollständiges RRset, Empfangszeit und Uhrbasis, Prüfsumme, TSR-Offset, Probe, Konflikt, Auswahl, Umbenennung und Goodbyes. Daran schließen sich die tatsächliche Client-Antwort, Zieladresse, Transportergebnis, Anwendungsauthentisierung und Nutzerwirkung an.

Die Annahme eines Updates beweist nicht, dass alte Proxys es zurückgezogen haben. Ein gewonnener TSR-Vergleich beweist nicht, dass das Ziel erreichbar ist. Eine Verbindung beweist keine Identität. Erfolgreiche Anwendungsauthentisierung beweist nicht, dass ein entfernter Cache die alte Adresse vergessen hat.

Auch die Außerbetriebnahme braucht Belege in Gegenrichtung: Registrierung entfernen, Registrar-Zustand prüfen, Proxy-Rückzüge beobachten, noch gültige Redundanz bewahren, TTLs ablaufen lassen und am ehemaligen Ziel kontrollieren, dass kein Verkehr mehr eintrifft. Ein leerer zentraler Eintrag genügt nicht.

Heng Lus Prinzip der minimalen Anfangsspezifikation unterstützt ein enges Austauschformat für die Koordination der Kopien. Die Realitätsebenen halten Alter, Herkunft, Identität und Ergebnis getrennt. Der Vorrang laufenden Codes verlangt schließlich die Beobachtung beim Client und in der Anwendung.

DNSSD muss daher nicht nur mehr Reichweite standardisieren. Es muss eine Autoritätsannahme korrigieren, die durch Vermittler falsch geworden ist. TSR kann das neueste Exemplar erkennen. Ob dessen Quelle berechtigt, dessen Veröffentlichung zulässig und dessen Dienst funktionsfähig ist, bleibt jeweils eine eigene Entscheidung.

Quellen