Zusammenfassung

  • Der erste ULD-Entwurf der DNSSD-Arbeitsgruppe lässt Clients pro Link auf einen bevorzugten Server konvergieren. Wechselt ein Client, muss er sämtliche eigenen Dienste beim neuen Server erneut registrieren.
  • Ein erfolgreicher Auswahlvorgang ist kein Kontinuitätsbeweis. Ein belastbarer Übergabebeleg muss alten und neuen Server, Wechselgrund, erwarteten Bestand, Annahmen und Ablehnungen, Leases, Konflikte, Proxy-Sichtbarkeit sowie IPv4-, IPv6- und Fallback-Ergebnisse verbinden.

Eine fast vollständige Migration ist kein vollständiger Befund

Totalausfälle sind auffällig. DNS-Anfragen laufen wiederholt in Zeitüberschreitungen, SRP-Leases lassen sich nicht verlängern oder eine DNS-Push-Sitzung bricht ab. Schwieriger ist der Teilerfolg: Fünf Dienste werden neu angemeldet, der sechste kollidiert mit einem Namen, und die Oberfläche meldet trotzdem „Serverwechsel abgeschlossen“.

draft-ietf-dnssd-uld-00 ist ein aktiver Internet-Draft der IETF-Arbeitsgruppe DNSSD vom 18. August 2026. Unicast Local Discovery soll Diensteregistrierung und -suche auf einem lokalen Link über Unicast-SRP und DNS ermöglichen und zugleich mit mDNS-Geräten zusammenarbeiten. Der Entwurf zielt auf den Standards Track und würde RFC 6762 aktualisieren, falls er verabschiedet wird. Er ist noch kein RFC; die Abschnitte zu Sicherheit, SNAC-Routern und IANA enthalten offene Punkte.

Ein ULD-Dienst bündelt fünf logische Funktionen. Der SRP-Registrar schreibt Einträge in eine .local-Zone. Ein autoritativer DNS-Server beantwortet Unicast-Anfragen. Ein Discovery Proxy bringt mDNS-Anzeigen in diese Sicht ein, ein Advertising Proxy veröffentlicht SRP-Einträge zurück in Richtung mDNS. Bei gemeinsam genutzten Record-Sets soll die Antwort grundsätzlich Zone und Proxy-Sicht vereinigen.

Deshalb sagt die Erreichbarkeit des Servers wenig über Vollständigkeit. Ein Eintrag kann in der Zone fehlen, nur aus einem Cache stammen oder auf der mDNS-Seite nicht erscheinen. Auch IPv4- und IPv6-Clients können unterschiedliche Pfade benutzen. Die grüne Serveranzeige ist nur ein Teil des Zustands.

Die Rangfolge bestimmt das Ziel, nicht den übertragenen Inhalt

Jeder ULD-Server veröffentlicht einen numerischen pri-Wert. Niedrigere Werte gewinnen. Infrastrukturserver erhalten 0, nicht eingeschränkte Ad-hoc-Server auf Kabel 100, auf WLAN 200 und stärker eingeschränkte Geräte 1000 oder 65535. Bei Gleichstand entscheidet die numerisch niedrigste link-lokale IPv6-Adresse.

Ein Infrastrukturserver fügt außerdem den IPv6 Router Advertisements eine ULD-Option hinzu. IPv6-Clients müssen diese Option zur Erkennung nutzen oder damit eine über DNS-SD gelernte Infrastrukturrolle bestätigen. Der Entwurf verweist auf RA Guard, um diese Kennzeichnung zu schützen.

In einem verwalteten Netz muss der Betreiber die Infrastrukturrolle ausdrücklich konfigurieren und dafür sorgen, dass höchstens ein Router pro Link die ULD-RA-Option sendet. Im Heimnetz darf ein CE-Router die Rolle standardmäßig beanspruchen, wenn er bereits die faktische Infrastruktur bildet. Ein Gerät, das nicht erkennbar das primäre Gateway ist, darf dies ohne explizite Konfiguration nicht tun.

Clients suchen zuerst nach Infrastruktur, wählen andernfalls einen Ad-hoc-Server und fallen ohne brauchbaren Kandidaten auf mDNS zurück. Sobald ein Client ULD nutzt, soll er auf diesem Link nicht mehr selbst an mDNS teilnehmen, sondern .local dem gewählten Server überlassen.

Die Auswahl bleibt jedoch in Bewegung. Anhaltende DNS-Fehler, gescheiterte SRP-Lease-Verlängerungen oder der Verlust von DNS Push lösen eine neue Suche aus. Ad-hoc-Clients halten zugleich nach einem besser priorisierten Server Ausschau. Sowohl ein Ausfall als auch das Auftauchen eines besseren Kandidaten führen zum Wechsel. Danach muss der Client alle Dienste beim neuen Server neu registrieren.

Anhang C begründet die Konvergenzstrategie. Unabhängige SRP-Registrare könnten denselben Namen annehmen; der Konflikt würde erst später auf der mDNS-Ebene auftreten und den Clients möglicherweise nicht korrekt gemeldet. ULD führt daher alle Clients anhand einer deterministischen Regel zu einem Server, statt Serverreplikation vorzuschreiben.

Damit wird aber kein alter Zoneninhalt automatisch übergeben. Ein ausgelaufener Entwurf zur SRP-Replikation verfolgte genau eine andere Strategie: Zustand zwischen Partnern bewahren, Konflikte beim Wechsel vermeiden und manche Ausfälle vor dem Client verbergen. Diese Replikation gehört nicht zu ULD 00. Im aktuellen Modell trägt der Client den Wiederaufbau.

Ein angenommenes Update beweist keine vollständige Wiederherstellung

Eine erfolgreiche SRP-Antwort gilt für das betreffende Update. Sie sagt nicht, wie viele weitere Einträge der Client hätte senden müssen. Auch die Zahl der Datensätze auf dem neuen Server hilft ohne zuvor festgelegten Sollbestand nicht weiter.

Der Übergabebeleg beginnt mit der Abgrenzung: Link, Schnittstelle, Adressfamilie und Beobachtungszeitraum. ULD verwaltet pro Link eine eigene Instanz und .local-Zone. Ein mehrfach angebundener Rechner kann auf einer Schnittstelle ULD und auf einer anderen mDNS verwenden. Ein globales Kennzeichen „Gerät migriert“ verwischt diese getrennten Vorgänge.

Dann folgen alter und neuer Server mit link-lokalen Adressen, pri, Infrastruktur- oder Ad-hoc-Klasse und dem verwendeten Tie-Break. Der Auslöser muss benannt werden: anhaltender Ausfall, verlorene Lease-Verlängerung, abgebrochene Push-Sitzung, besserer Kandidat oder bewusster Betreiberwechsel.

Auch die Herkunft der neuen Rolle ist relevant. Im verwalteten Netz verweist der Beleg auf die genehmigte Konfiguration. Im Heimnetz kann er die Gateway-Funktion dokumentieren. Beobachtete RA-Option und angewandte RA-Guard-Regel sind Belege für die Ankündigung, nicht für eine allgemeine Serverauthentisierung. Der Entwurf erlaubt selbstsignierte Zertifikate, rät Clients von deren Zurückweisung ab und erklärt Authentisierung ausdrücklich nicht zum Ziel dieses opportunistischen TLS.

Im Mittelpunkt steht die Bestandsabstimmung. Vor dem Wechsel bildet der Client einen Commit über die normalisierten Dienstebeschreibungen, die er erneut senden will. Danach vermerkt er für jedes Element Annahme, Ablehnung, Konflikt, Timeout, gewährtes Lease und Wiederholungsversuch. Der neue Server kann einen passenden Zonendigest liefern. Prüfungen vergleichen Unicast-Antwort, Discovery-Proxy-Zufluss und die mDNS-Ausgabe des Advertising Proxy.

IPv4 und IPv6 benötigen getrennte Tests. Die Infrastrukturerkennung per RA ist IPv6-spezifisch. Ein reiner IPv4-Client entdeckt Server über mDNS und kann dorthin zurückfallen, wenn das bevorzugte Ziel über IPv4 unerreichbar ist. Ein erfolgreicher Dual-Stack-Test repräsentiert diesen Randfall nicht automatisch.

Bewusst zurückgezogene Dienste, kollisionsbedingte Umbenennungen, ausstehende Registrierungen und Fallback sind verschiedene Ergebnisse. Sie können legitim sein, müssen aber als Ausnahme erscheinen statt in einer Erfolgsquote zu verschwinden.

Nachweis ja, dauerhaftes Geräteverzeichnis nein

Lokale Dienstnamen können Räume, Personen, Gerätetypen und Gewohnheiten verraten. Ein dauerhaft zentral gespeicherter Vollbestand wäre für die Kontinuitätsprüfung unverhältnismäßig.

Ein datensparsamer Beleg kann gesalzene Hashes normalisierter Beschreibungen, grobe Typenzahlen und Fehlercodes verwenden. Vollständige Vergleichsdaten und Salz verbleiben kurzzeitig beim Client oder in einem geschützten Betriebsbereich. Länger aufbewahrt werden Übergangskennung, Vorher-nachher-Zahlen, Abweichungen, Zeitwerte und ein kryptografischer Commit gegen nachträgliche Umschreibung.

Die Frist sollte Lease-Ablauf, Cache-Umschlag und verspätete Meldungen abdecken. Danach werden nicht mehr benötigte Namen entfernt. Es geht um die Rekonstruktion eines Übergangs, nicht um ein Archiv des lokalen Alltags.

Die belegbare Aussage bleibt eng

Der Entwurf belegt, dass Wahl und Neuregistrierung getrennte Handlungen sind. Den hier beschriebenen Übergabebeleg standardisiert er nicht; er ist eine Analyse von Daniel Kade. Öffentliche Messwerte zu Verlustquote, Wiederherstellungsdauer oder herstellerübergreifender Interoperabilität liegen im verwendeten Quellenpaket nicht vor.

RFC 7113 beschreibt Grenzen von RA Guard. SRP-Schlüssel und SIG(0) schützen die Verfügungsgewalt über eine Registrierung, nicht die Vollständigkeit eines Gesamtbestands zwischen zwei Servern. Die autoritative ULD-Rolle bleibt auf .local und den jeweiligen Link beschränkt; sie ist keine Delegation im öffentlichen DNS.

Der Wechsel ist deshalb nicht beendet, wenn der neue Server antwortet. Er endet, wenn jeder erwartete Dienst wieder sichtbar, bewusst zurückgezogen oder als überprüfbare Ausnahme erfasst ist.

Quellen

  1. Aktueller ULD-Arbeitsgruppenentwurf
  2. Dokumenthistorie
  3. Eingefrorene Revision 00, HTML
  4. Eingefrorene Revision 00, Text
  5. Datatracker-Dokument-API
  6. DNSSD-Arbeitsrepository
  7. ULD-Präsentation auf der IETF 126
  8. DNSSD-Arbeitsgruppenauftrag
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — Umsetzungshinweise zu RA Guard
  17. RFC 4861 — IPv6 Neighbor Discovery
  18. Advertising-Proxy-Entwurf
  19. Time-Since-Received-Entwurf
  20. Ausgelaufener SRP-Replikationsentwurf