Zusammenfassung

  • DHCPv4-Option 137 und DHCPv6-Option 51 transportieren jeweils genau einen FQDN. Sie sind weder eine IP-Adresse noch eine priorisierte Serverliste oder ein LoST-Mapping.
  • Auf den Namen folgen U-NAPTR, DNS, Endpunktauswahl, Verbindung und Dienstidentitätsprüfung. Jede Stufe hat einen eigenen Beweiswert und kann bei unverändert gültiger DHCP-Syntax scheitern.
  • Wer nur discovered=true speichert, vernichtet die wichtigste Information: welcher Akteur welche Entscheidung zu welchem Zeitpunkt tatsächlich getroffen hat.

Die Konfiguration war da, der Dienst noch nicht

Eine konstruierte Prüffolge beginnt um 08:14:00 mit dem Netzanschluss eines Endgeräts. Um 08:14:01 enthält DHCPACK die Option 137. Der Decoder liest lost.access.example, akzeptiert die DNS-Labels und findet genau ein Root-Label. Um 08:14:02 meldet die Betriebsansicht eine erfolgreiche LoST-Erkennung.

Zu diesem Zeitpunkt fehlt noch jedes U-NAPTR-Ergebnis. Es gibt keine DNS-Zieladresse, keinen Validierungsstatus, keinen verbundenen Peer, keine geprüfte TLS-Dienstidentität, keine LoST-XML-Antwort, kein Mapping und keine Kontakt-URI. Die Sequenz beschreibt ausdrücklich keinen realen Vorfall. Sie zeigt nur, wie früh ein syntaktischer Erfolg semantisch überladen werden kann.

RFC 5223 erlaubt einem Zugangsnetz, das selbst LoST bereitstellt oder einen Drittanbieter kennt, einen Domainnamen zu liefern. Dieser Name dient als Eingabe für das DNS-basierte LoST-Entdeckungsverfahren. Das Dokument macht den DHCP-Server nicht zur Mapping-Autorität und verspricht kein Ergebnis des späteren Notrufwegs.

Der präzise Status lautet daher: Der Client hat einen Discovery-Input erhalten. Alles Weitere bleibt eine offene Messung.

Genau ein FQDN, keine erfundene Rangfolge

OPTION_V4_LOST trägt den Code 137; OPTION_V6_LOST den Code 51. Beide kodieren DNS-Labels und enthalten jeweils einen vollständig qualifizierten Namen mit genau einem abschließenden Root-Label. Der Client kann die Option über den jeweiligen DHCP-Anforderungsmechanismus verlangen.

Der Inhalt ist keine IP-Adresse und keine URI. Er ist auch keine Liste bevorzugter LoST-Server. Wer aus der Option mehrere Failover-Ziele ableitet, ergänzt lokale Semantik. Diese kann sinnvoll sein, ist aber nicht durch RFC 5223 autorisiert und muss als eigene Entscheidung sichtbar bleiben.

Für die Nachweisführung gehören Optionscode, Länge, Rohbytes, dekodierter FQDN, Syntaxentscheidung und DHCP-Transaktion zusammen. Nur den Text zu speichern, verbirgt tolerant akzeptierte Fehlkodierung. Nur die Präsenz zu speichern, verbirgt Wertänderungen. Eine später aufgelöste IP in den DHCP-Beleg zurückzuschreiben, löscht die DNS-Entscheidung.

Auch die IANA-Zuweisung ist eine Koordinationsleistung. Sie schafft gemeinsames Verständnis des Feldes, aber keine Signatur für jeden Absender.

Ein DHCP-Wert lebt im Anschlusskontext

RFC 2131 beschreibt Auswahl, Bestätigung, Parameter und Lease in DHCPv4. RFC 8415 bildet die aktuelle DHCPv6-Grundlage. Ein ACK beweist, was ein bestimmter Konfigurationspfad in einer Transaktion geliefert hat.

Die DHCP-Serverkennung identifiziert diesen Teilnehmer. Sie sagt nicht, dass er den benannten LoST-Dienst betreibt oder für jede geografische Zuständigkeit autorisiert ist. RFC 3046 kann Relay-Informationen zum Zugangsweg hinzufügen. Topologieerklärung ist jedoch keine Dienstbescheinigung.

Bei Mobilität wird die Begrenzung praktisch. Ein Gerät wechselt Interface, WLAN, Provider oder Verwaltungsdomäne, während eine Anwendung den alten FQDN behält. Der Beleg muss daher Interface, Netzkontext, Transaktion, Server, Relay, Empfangszeit, Lease und Invalidierungsereignis verbinden.

Eine Implementierung sollte zeigen, ob Renew, Rebind, Linkwechsel oder Adresswechsel die erneute Entdeckung auslöst. Sonst wird ein lokaler Hinweis allein durch Speicherung zur dauerhaften Systempolitik.

Der Angreifer im DHCP-Pfad steht im Standard

RFC 5223 warnt ausdrücklich: Wer eine DHCP-Antwort verändert oder eine eigene einschleust, kann den Client zu einem vom Angreifer kontrollierten LoST-Server oder zu einer ungültigen Adresse führen. RFC 5069 behandelt verwandte Gefahren für Notrufkennzeichnung und -mapping.

RFC 3118 spezifiziert Authentisierung und Replay-bezogene Sicherung von DHCP-Nachrichten. Daraus folgt eine getrennte Prüffrage nach Herkunft, Integrität und Aktualität. Daraus folgt nicht, dass diese Mechanismen überall eingesetzt werden. Der Betriebsbeleg muss den tatsächlich ausgeführten Test festhalten.

Eine authentisierte Nachricht kann dennoch veraltet oder falsch konfiguriert sein. Berechtigung zur Verwaltung des Zugangsnetzes ist nicht automatisch Zuständigkeit für alle LoST-Regionen. Identität des Sprechers und Wahrheit jeder Aussage bleiben verschiedene Größen.

Heng Lus Vorrang des laufenden Codes verlangt lokale Belege: Welche Eingabe wurde konsumiert, welche Prüfung durchgeführt, welcher Zustand erzeugt? Ein DHCP-Client kann seine Annahme belegen, nicht die Entscheidung des Resolvers, die Mapping-Quelle oder die spätere Dienstannahme.

Der Name öffnet erst die DNS-Kette

Der FQDN wird in das mit RFC 5222 verbundene U-NAPTR/DNS-Verfahren eingespeist. Ein passender Dienstsatz muss gefunden, ein Ziel gewählt, eine Adresse aufgelöst und eine Verbindung aufgebaut werden.

Ein formal gültiger Name kann keinen passenden Dienstsatz besitzen. DNS kann ausfallen, ein Ziel unerreichbar sein oder die präsentierte Identität nicht zum erwarteten Dienst passen. RFC 8446 schützt TLS; RFC 9525 präzisiert Dienstidentität. Verschlüsselung zu einem falsch ausgewählten Peer bleibt eine geschützte Verbindung zum falschen Peer.

Deshalb gehören U-NAPTR-Frage und Auswahl, DNS-Antwort und TTL, Validierungszustand, Adressmenge, gewähltes Ziel und Identitätsentscheidung in getrennte Felder. „DNS erfolgreich“ ist ohne diese Einzelheiten ebenfalls zu grob.

RFC 8917 weist dem LoST-Validierungsdienst einen eigenen S-NAPTR-Anwendungsdienst-Tag zu. Die Rolle kann im Discovery-Prozess benannt werden; der Rollenname garantiert nicht die richtige Ausführung.

Backend-Vertrauen ersetzt den Clientpfad nicht

Nach erfolgreicher Verbindung muss eine LoST-Anfrage noch beantwortet werden. Fehler, Warnungen, Weiterleitungen und Mappings besitzen eigene Herkunfts-, Zeit- und Geltungsbedingungen.

Der bestehende RFC-5222-Beitrag behandelt die spätere Grenze zwischen Mapping und erbrachter Notfallleistung. Dieser Beitrag bleibt davor: Ein DHCP-Name kann nicht vorwegnehmen, ob das spätere Mapping korrekt ist.

RFC 6739 stärkt Provenienz und Synchronisierung zwischen LoST-Servern. Ein signiertes Backend authentisiert nicht rückwirkend das DHCP-Paket oder die DNS-Sicht des Clients. RFC 6881 ordnet Discovery in die gesamte Notrufpraxis ein, ohne die Beweisgrenzen zwischen Konfiguration, Mapping, Signalisierung und Annahme aufzuheben.

Der kürzeste ehrliche Nachweis

Er enthält Anschlusskontext, DHCP-Transaktion, Server und Relay, Nachrichtenschutz, Rohoption und FQDN, Lease und Invalidierung, U-NAPTR, DNS, TLS-Identität, LoST-Antwort, Mapping-Eignung, Sitzungsaufbau und Dienstannahme. Jede Zeile kann auf die nächste verweisen, aber keine darf sie ersetzen.

Eine Managementansicht darf diese Kette zusammenfassen. Sie muss nur ermöglichen, vom Ergebnis zu den engen Originalbelegen zurückzukehren.

Quellen

  1. RFC 5223
  2. RFC 5223 im IETF Datatracker
  3. RFC-5223-Status
  4. RFC-5223-Historie
  5. RFC-5223-Errata
  6. RFC 2131
  7. RFC 2132
  8. RFC 8415
  9. RFC 3118
  10. RFC 3046
  11. RFC 5222
  12. RFC 5069
  13. RFC 6881
  14. RFC 8917
  15. RFC 6739
  16. RFC 8446
  17. RFC 9525
  18. Heng Lu — Vorrang laufenden Codes
  19. Heng Lu — minimale Anfangsspezifikation und freiwillige Übernahme