Zusammenfassung

  • Am 18. August genehmigte die DNSSD-Arbeitsgruppe draft-ietf-dnssd-uld-00 und verknüpfte ihn als Nachfolger des individuellen Entwurfs. Der normalisierte technische Text blieb unverändert.
  • ULD bündelt SRP-Registrierung, autoritatives DNS und zwei Proxy-Funktionen auf einem bevorzugten Server im lokalen Link. Die Sicherheitsbetrachtung dafür besteht derzeit nur aus einem Platzhalter.

Bei Unicast Local Discovery ist der neue Dateiname selbst das Ereignis. Er verschiebt den Entwurf aus individueller Verantwortung in die formale Arbeit einer IETF-Gruppe.

Die Historie des Arbeitsgruppendokuments verzeichnet am 18. August um 16:22:50 UTC die Genehmigung von -00, die Bereitstellung der Version und die Ersetzung von draft-tlmk-infra-dnssd. Entfernt man Dokumentnamen, Datum, Ablaufzeit, Repository-Verweis und Seitenköpfe, sind Vorgänger und neue Fassung bytegleich. Daraus folgt keine neue technische Eigenschaft; es folgt eine neue öffentliche Zuständigkeit für denselben Vorschlag.

Der Weg dorthin wurde einmal korrigiert. In der Historie des Vorgängers hält der Vorsitzende fest, dass er den Entwurf nach einem Handzeichen in der Sitzung der IETF 126 zunächst als angenommen behandelt hatte. Weil zuvor ein Aufruf zur Annahme auf der Mailingliste nötig gewesen wäre, gab er das Dokument wieder frei. Der Aufruf folgte am 21. Juli, der endgültige Status „Adopted by a WG“ am 6. August. Nachvollziehbare Korrektur ist ein Zeichen für überprüfbares Verfahren, aber keine abschließende technische Prüfung.

Der ULD-Entwurf beschreibt zunächst die Kosten des heutigen Modells. Bei mDNS muss jedes veröffentlichende Gerät Multicast-Anfragen empfangen und beantworten. WLAN-Multicast wird auf der MAC-Schicht weder bestätigt noch erneut gesendet, für schlafende Stationen nicht am Access Point gepuffert und mit einer niedrigen Pflichtdatenrate übertragen. Batteriegeräte müssen häufig aufwachen oder Anfragen verpassen; zugleich verbraucht ein Multicast-Frame überproportional Funkzeit.

ULD setzt einen dauernd erreichbaren Dienst dazwischen. Ein Server vereint SRP-Registrar, autoritativen DNS-Server, Discovery Proxy und Advertising Proxy. Ein fähiger Client registriert seine Dienste dort und fragt .local per Unicast ab. Solange der Server funktioniert, soll der Client seine eigene mDNS-Teilnahme auf diesem Link einstellen. Die Proxys erhalten die Sichtbarkeit gegenüber Geräten, die nur Multicast beherrschen.

Zwei Bausteine sind bereits standardisiert. RFC 9665 definiert das Service Registration Protocol mit registrierten Diensten und Laufzeiten. RFC 8766 definiert einen Discovery Proxy, der Unicast-DNS-Anfragen mit Informationen aus mDNS-Links beantwortet. ULD beschreibt, wie diese Bausteine als lokaler Dienst angekündigt, ausgewählt, überwacht und gewechselt werden.

Der RFC 6762 für Multicast DNS bleibt Teil der Architektur. Der Entwurf würde ihn bei einer späteren Genehmigung aktualisieren, nicht abschaffen. Server werden weiter über DNS-SD auf mDNS bekannt gemacht, ältere Geräte werden weiter über Multicast erreicht, und Clients fallen auf mDNS zurück, wenn kein nutzbarer ULD-Server vorhanden ist. Das Ziel ist weniger routinemäßiger Multicast, nicht dessen sofortiges Ende.

Die Serverpräferenz verlagert Kontrolle. In einem verwalteten Netz muss der Betreiber den Infrastrukturserver ausdrücklich bestimmen. Auf einem Link darf höchstens ein Gerät die ULD-Option in Router Advertisements ankündigen. Ad-hoc-Server erhalten niedrigere Prioritäten. Clients suchen weiter nach einem besseren Kandidaten, erkennen anhaltende DNS-, Lease- oder Push-Fehler und registrieren nach einem Wechsel alle Dienste neu.

Diese Konvergenz soll Namenskonflikte begrenzen. Zwei unabhängige Server könnten denselben Namen für verschiedene Clients akzeptieren; der Konflikt würde erst im Multicast sichtbar und möglicherweise nicht korrekt an die Registrierenden zurückgemeldet. Statt eine Replikation zwischen allen Servern vorzuschreiben, lässt ULD die Clients deterministisch auf denselben Server zulaufen. Die Abhängigkeit liegt dann offen in Auswahl, Erreichbarkeit und Migration.

Für IPv6 erhält die Rollenbehauptung einen zweiten Kanal. Der Infrastrukturserver kündigt eine RA-Option an; Clients müssen sie zur Erkennung verwenden oder damit eine über DNS-SD gelernte Behauptung prüfen, damit RA Guard die Rolle schützen kann. Reine IPv4-Clients entdecken Server über mDNS. Bei IPv4 muss der Server vor der Bearbeitung einer .local-Anfrage prüfen, ob die Quelle in einem direkt angeschlossenen Subnetz liegt.

Gerade die Vertrauensfragen sind noch nicht beantwortet. Unter Security Considerations steht nur TODO. Der Abschnitt zu SNAC-Routern ist ebenfalls leer, und der gewünschte IANA-Dienstname ist ein Platzhalter. Der öffentliche Stand enthält keine unabhängigen Implementierungen, Interoperabilitätsergebnisse oder Messwerte zu Funkzeit, Energieverbrauch, Anfrageverlust und Umschaltzeit. Es bleibt ein Internet-Draft, kein RFC, und kann geändert, ersetzt oder aufgegeben werden.

Die DNSSD-Charta ordnet die Arbeit ein: mDNS ist auf einem lokalen Link nützlich, skaliert aber nicht von selbst über geroutete und mehrgliedrige Netze; ein größerer Erkennungsbereich wirft Sicherheits- und Datenschutzfragen auf. ULD bleibt zunächst im Link, doch der bevorzugte Server beeinflusst die Dienstesicht des Clients. Darum ist der fehlende Sicherheitsabschnitt kein redaktionelles Detail.

Die IETF hat somit eine überprüfbare Entwicklungsstrecke eröffnet. Sie hat weder einen RFC verabschiedet noch eine Wirkung im WLAN gemessen. Ob weniger Multicast die neue Serverabhängigkeit rechtfertigt, müssen überarbeiteter Text, unabhängiger Code und Fehlerdaten erst zeigen.

Quellen