Zusammenfassung

  • Bei Known-Answer Suppression führt ein mDNS-Fragender bereits gespeicherte Datensätze im Answer Section seiner Anfrage mit. Beträgt ihre Rest-TTL mindestens die Hälfte der korrekten TTL, muss der passende Responder die Wiederholung unterdrücken; unterhalb dieser Grenze muss er auffrischen.
  • Der mitgeführte Datensatz ist nicht autoritativ und darf von anderen Fragenden nicht in deren Cache übernommen werden. Schweigen ist daher nur mit Anfrage, beiden TTL-Werten, weiteren Interessenten und dem Ablaufpfad erklärbar; allein beweist es weder Abwesenheit noch Konsens.

Um 10:00 Uhr erscheint ein Drucker in der Diensteliste. Um 10:01 Uhr fragt der Rechner wieder, doch der Drucker antwortet nicht. Um 10:02 Uhr kommt eine neue Antwort. Dieselbe Beobachtung kann wie Unzuverlässigkeit wirken, obwohl alle drei Zeitpunkte einer einzigen Regel folgen.

Multicast DNS überträgt DNS-ähnliche Fragen und Antworten auf dem lokalen Link über UDP-Port 5353. Namen unter .local. haben linklokale Bedeutung. Es gibt nicht zwingend einen herkömmlichen Unicast-DNS-Server, der als einziger Adressat und einziger Entscheider auftritt. Viele Geräte hören dieselbe Frage, mehrere dürfen antworten.

Stuart Cheshire und Marc Krochmal sind die beiden Autoren von RFC 6762, Cheshire wird zuerst genannt. Ihr Mechanismus verteilt die Entscheidung: Der Fragende offenbart einen Teil seines Cache-Zustands, der Responder vergleicht Lebensdauern, und die Zeit entzieht einem alten Eintrag automatisch seine dämpfende Wirkung.

Das ist kein allgemeines Vertrauensmodell. Eine lokale Erinnerung erhält nur die Befugnis, eine konkrete Wiederholung kurzfristig zu verhindern. Sie darf weder den Ursprung vertreten noch Nachbarn überzeugen.

Fortlaufende Suche statt einmaliger Auflösung

Eine einmalige Namensfrage kann mit der ersten passenden Antwort enden. Ein Dienstbrowser soll dagegen auch einen Drucker anzeigen, der später hinzukommt, und einen verschwundenen Eintrag entfernen, solange die Ansicht offen bleibt.

RFC 6762 begrenzt die dadurch nötigen fortlaufenden Anfragen. Zwischen den ersten beiden muss mindestens eine Sekunde liegen; danach müssen sich die Intervalle mindestens verdoppeln. Sobald eine Stunde erreicht ist, darf es bei einer Anfrage pro Stunde bleiben. Vor der ersten Sendung verteilt eine zufällige Verzögerung von 20 bis 120 Millisekunden gleichzeitige Starts.

Das Backoff senkt die Zahl der Fragen. Es verhindert aber noch nicht, dass jeder bekannte Drucker auf jede Frage erneut antwortet. Genau dafür ist Known-Answer Suppression bei fortlaufenden Anfragen verpflichtend.

Der Browser fragt nach möglicherweise neuen oder zuvor verpassten Mitgliedern. Er verlangt nicht, dass jeder bereits sichtbare Dienst seine vollständige Beschreibung wiederholt. Die Anfrage muss also offen für Neues bleiben und zugleich Bekanntes benennen können.

Warum eine Frage ein Answer Section besitzt

Der Fragende schreibt die Datensätze, die er noch im Cache hält, in den Answer Section der Anfrage. Der Feldname ist leicht misszuverstehen. In diesem Nachrichtentyp sind die Einträge keine Antworten einer autoritativen Quelle, sondern eine Zustandsmeldung des Fragenden.

Ein Eintrag sagt sinngemäß: Für diesen Namen, Typ, diese Klasse und diese Daten besitze ich noch eine Kopie mit der angegebenen Restlaufzeit. Der mögliche Responder vergleicht sie mit dem Datensatz und der TTL, die er selbst ausgeben würde.

Besonders nützlich ist das bei Shared Records. Mehrere Geräte dürfen für denselben Namen, Typ und dieselbe Klasse unterschiedliche Daten liefern. Ein bekannter Drucker kann schweigen, während ein noch unbekannter Drucker weiterhin antwortet.

Die Liste ist deshalb kein Votum darüber, was auf dem Link existiert. Sie grenzt nur die Wiederholungen ein, die für einen bestimmten Fragenden aktuell wenig Informationsgewinn hätten.

Zwei TTL-Werte entscheiden über ein Paket

Zeigt der bekannte Datensatz noch mindestens die Hälfte der korrekten TTL, muss der Responder seinen übereinstimmenden Datensatz unterdrücken. Liegt die Rest-TTL darunter, muss er antworten. Auch der Fragende sollte einen bereits unter die Hälfte gefallenen Eintrag nicht mehr als bekannte Antwort aufführen.

Bei einer korrekten TTL von 120 Sekunden reichen 70 verbleibende Sekunden für Schweigen. 50 Sekunden reichen nicht. Für eine spätere Erklärung müssen deshalb sowohl die in der Anfrage gemeldete Rest-TTL als auch die vom Responder verwendete korrekte TTL erhalten bleiben.

Die Regel wartet nicht bis unmittelbar vor dem Ablauf. Sie spart Wiederholungen in der jüngeren Hälfte und eröffnet in der älteren Hälfte eine Auffrischungsmöglichkeit. Damit kann der Cache die letzte sinnvolle Erneuerung nicht bis zum Ende blockieren.

„Hälfte“ ist keine Aussage über eine Wahrscheinlichkeit von 50 Prozent und kein Vertrauenswert. Es ist ein zeitlicher Schaltpunkt. Wer ihn als Konfidenz darstellt, vermischt Lebensdauer, Wahrheitsgehalt und Herkunft.

Nicht autoritativ heißt: nicht weiterlernen

Andere Fragende dürfen die bekannten Antworten in einer Anfrage nicht cachen. Der ursprüngliche Fragende könnte sie vor einer Änderung gelernt haben, der veröffentlichende Host könnte den Link verlassen haben oder die Beobachtung könnte von einer früheren Netztrennung stammen.

Dürfte ein Nachbar diesen Eintrag übernehmen, könnte sich ein veralteter Cache vervielfältigen, ohne dass die ursprüngliche Quelle erneut spricht. Aus einer Verkehrsoptimierung würde eine Kette selbstverlängernder Gerüchte.

Auch der stille Responder macht keine negative Aussage. Er sagt nicht, dass der Dienst fehlt. Er entscheidet nur, dass die konkrete Kopie dieses konkreten Fragenden noch jung genug ist, um eine weitere Übertragung zu vermeiden.

Wartet ein anderer Fragender noch auf denselben Datensatz, darf dessen Bedarf nicht verschwinden. Der Cache eines Hosts kann nicht stellvertretend für den Wissensstand des gesamten Links sprechen.

Mehrteilige bekannte Antworten und TC

Eine lange Liste bekannter Datensätze passt möglicherweise nicht in ein Paket. Der Fragende kann mit dem TC-Bit weitere Teile ankündigen. Würde der Responder sofort nach dem ersten Teil senden, könnte sein Datensatz erst im nächsten Teil auftauchen.

Bei einer Anfrage mit TC wartet der Responder daher zufällig 400 bis 500 Millisekunden und sammelt nachfolgende bekannte Antworten. Findet er eine passende Kopie mit ausreichender TTL, kann er die geplante Antwort streichen.

Das gilt nicht, wenn ein anderer Fragender weiterhin auf den Datensatz wartet. Die mehrteilige Liste beschreibt den Zustand ihres Absenders, nicht ein gemeinsames Gedächtnis aller Teilnehmer.

Ein ununterbrochener Strom von TC-Paketen könnte eine Antwort theoretisch lange verzögern. RFC 6762 erkennt diesen Randfall an und priorisiert bei Überlast den Kapazitätsschutz gegenüber sofortiger Reaktion. In Messdaten muss erkennbar bleiben, ob eine Antwort geplant verschoben oder unabsichtlich verloren wurde.

Auffrischung besitzt ein Ende

Wenn ein aktiver Client einen Datensatz weiter verwendet, sieht die RFC Auffrischungsversuche bei ungefähr 80, 85, 90 und 95 Prozent der Lebensdauer vor, jeweils mit zwei Prozent Zufallsabweichung. Kommt bis 100 Prozent keine neue Antwort, wird der Eintrag gelöscht.

Ohne aktiven Client soll ein Datensatz nicht nur deshalb erneuert werden, damit er im Cache bleibt. Das begrenzt sowohl die Speicherbehauptung als auch den Verkehr für Informationen, an denen niemand mehr interessiert ist.

Die aktive Auffrischung und die Halb-TTL-Suppression teilen eine Uhr. Früh im Lebenszyklus lohnt sich eine Wiederholung selten. Später wird Bestätigung nötig. Am Ende setzt sich das Verfallsdatum durch.

Eine sichtbare Dienstliste beweist daher nicht, dass die Kette funktioniert. Erst die Abfolge aus bekannten Antworten, Schwellenentscheidung, Auffrischung und Löschung trennt lebendige Entdeckung von einem festsitzenden Cache.

Die Verbindung zu DNS-SD

RFC 6763 beschreibt DNS-Based Service Discovery mit DNS-Datensätzen wie PTR, SRV und TXT. Damit lassen sich Instanzen aufzählen und Verbindungsinformationen ermitteln. mDNS ist ein wichtiger lokaler Transport dafür, doch Dienstentdeckung und Multicast-Transport bleiben unterschiedliche Funktionen.

Ein geöffneter Dienstbrowser erzeugt das aktive Interesse, das fortlaufende Anfragen und Auffrischungen rechtfertigt. Known-Answer Suppression hält dabei bereits gelistete Instanzen ruhig, ohne eine neue Instanz zum Schweigen zu bringen.

Eine gefundene Instanz ist noch keine authentisierte Instanz. Name, Port und Attribute gewähren auch keine Berechtigung. Nach der Entdeckung müssen Verbindung, Identität und Zugriff von ihren eigenen Kontrollen entschieden werden.

Laufender Code als Nachweisfläche

Apples öffentliches mDNSResponder-Repository beschreibt Daemon, Werkzeuge und Bibliotheken für DNS Service Discovery. Laut README beobachtet der Daemon unter anderem Multicast-Verkehr auf Port 5353 und löst .local. mit mDNS auf.

Das schafft eine prüfbare Implementierungsfläche. Es beweist nicht, dass jede Betriebssystemversion, jedes Gerät, jede Herstellerabzweigung, WLAN-Optimierung, VLAN-Brücke oder Proxy-Konfiguration die Halb-TTL-Regel korrekt ausführt.

Die RFC liefert die minimale interoperable Verpflichtung. Code, Konfiguration und der konkrete Link entscheiden, ob sie tatsächlich erfüllt wird. Running-Code Primacy bedeutet hier, die geschriebene Zusage anhand realer Pakete und Zustände zu prüfen, nicht die Zusage zu verwerfen.

Eine belastbare Untersuchung rekonstruiert Anfrage, bekannte Liste, beide TTLs, Suppressionsentscheidung, TC-Wartezeit, andere Interessenten und den Ablauf. Eine funktionierende Benutzeroberfläche ersetzt diese Belege nicht.

Was sich Stuart Cheshire zurechnen lässt

Stuart Cheshire wird in RFC 6762 und RFC 6763 vor Marc Krochmal als Autor genannt. Das belegt seine maßgebliche Beteiligung an der gemeinschaftlichen Standardisierung von Multicast DNS und DNS-Based Service Discovery.

Bei der Prüfung am 30. August 2026 führte sein öffentliches IETF-Datatracker-Profil 28 RFCs und eine aktuelle Rolle als Delegierter der Congestion Control Working Group auf. Rolle und Zahl sind zeitgebunden und können sich ändern.

Sie belegen weder eine alleinige Erfindung noch Eigentum an einem Produkt, Kontrolle über jede Implementierung oder Verantwortung für fremde lokale Netze. Eine Autorenzeile ist ein Nachweis für einen abgegrenzten Beitrag, keine unbeschränkte Vollmacht.

Diese Zurückhaltung folgt demselben Prinzip wie die Suppression: Ein Beleg soll die Wirkung erhalten, die er tragen kann, aber nicht zur Autorität für Aussagen werden, die er nie gemacht hat.

Quellen