Summary

  • RFC 5223 definiert DHCPv4-Option 137 und DHCPv6-Option 51 für genau einen nach RFC 1035 codierten LoST-FQDN. Der Name ist Eingabe für DNS/U-NAPTR, nicht Serveradresse, authentisierte Autorität, Abbildung oder Notdienstergebnis.
  • Erforderlich ist ein Beleg, der DHCP-Herkunft, Parsergebnis, Domäne, DNS-Sicht, U-NAPTR-Ausgabe, URI, Dienstidentität, LoST-Abbildung und Ergebnis getrennt verbindet.

Der Parser konnte Recht haben und die Auswahl trotzdem falsch sein

Die Option kam an, alle Längenfelder stimmten, und genau ein Wurzellabel schloss den Namen ab. Das System konnte zweifelsfrei feststellen, dass die Nutzlast einen zulässigen FQDN enthielt.

Es konnte daraus nicht ableiten, dass der DHCP-Absender diese Suchdomäne wählen durfte. Ebenso wenig wusste es, welche DNS-Sicht antworten, welcher U-NAPTR-Dienst ausgewählt oder welche Identität am Ende erscheinen würde.

RFC 5223 hält diese Aussage eng. Option 137 für IPv4 und Option 51 für IPv6 tragen einen Namen, der dem DNS-basierten Verfahren aus LoST und RFC 4848 übergeben wird. Weder IP-Adresse noch endgültige URI oder Autoritätsurteil stehen im Feld.

Jeder Verarbeitungsschritt wechselt den Prüfgegenstand

RFC 1035 liefert die Etikettencodierung, die Gesamtlänge bleibt auf 255 Oktette begrenzt, und die Option enthält nur einen wurzelterminierten Namen. Damit lässt sich die Syntax prüfen.

Danach zählt die Herkunft des DHCP-Austauschs. Der akzeptierte Name geht an einen Resolver, dessen Sicht, Cache und Zeitpunkt die Antwort beeinflussen. U-NAPTR wandelt den Namen in eine Dienstreferenz um. Die Verbindung erreicht eine Instanz, deren Identität und LoST-Schutz erneut geprüft werden müssen.

Erst anschließend beginnt die Abbildung nach RFC 5222. Verwendeter Ort, Quelle, Ablauf, Grenze und zurückgegebenes Ziel sind eigene Fakten. Ein Ziel beweist noch keine Antwort des Notdienstes. Die Stufen sind verkettet, aber kein Ergebnis erteilt der nächsten Stufe Vollmacht.

Lokale Bereitstellung verteilt Zuständigkeit

Das Zugangsnetz kann die Domäne eines eigenen nahen Servers oder eines bekannten Dritten mitteilen. Diese Flexibilität hilft bei der Konfiguration, schafft aber eine Delegationsentscheidung.

DHCP-Betrieb, Domäneninhaber, DNS-Verwalter, LoST-Betreiber und Notdienst können unterschiedlichen Organisationen gehören. Die DHCP-Stelle kann den Namen ändern, aber nicht unbedingt DNS-Einträge zurücknehmen. Eine gleichbleibende Domäne kann über U-NAPTR plötzlich eine andere Instanz auswählen.

Ein belastbarer Nachweis benennt Genehmiger, Zoneninhaber, Record-Herausgeber, erwartete Dienstidentität und Widerrufsrecht. Er erklärt auch unterschiedliche Namen in verschiedenen Zugangsnetzen. Nähe beschreibt Topologie, nicht eine einheitliche Autorität.

Der Angreifer kann den Anfang wählen

RFC 5223 warnt: Wer eine DHCP-Antwort verändert oder eine eigene einfügt, kann den Client zu einem bösartigen LoST-Server lenken oder eine ungültige Adresse liefern. Korrektes DNS für eine vom Angreifer gewählte Domäne behebt den Fehler nicht.

Authentisches DHCP bürgt umgekehrt nicht für DNS und Dienst. Herkunft, Resolverkonsistenz, U-NAPTR-Verarbeitung, Dienstauthentisierung, LoST-Sicherheit, Abbildungsalter und Enderreichbarkeit brauchen eigene Kontrollen.

Fehler müssen getrennt bleiben: fehlende Option, ungültige Codierung, unerwartete Domäne, leeres NAPTR-Ergebnis, ungültige URI, Identitätsfehler, stummer Dienst, fehlende Abbildung und unerreichbares Ziel. Eine Sammelmeldung verhindert die Zuordnung zum Reparaturverantwortlichen.

Nähe ist noch keine gemessene Widerstandsfähigkeit

Der RFC nennt die Platzierung nahe am Endgerät wünschenswert und erwartet Vorteile bei unterbrochener Verbindung in Katastrophen. Das ist eine Entwurfsbegründung, keine Messung eines benannten Netzes.

Auch eine nahe Instanz kann von fernem DNS, abgelaufener Delegation oder nicht erreichbarer Kartendatenquelle abhängen. Sie kann außerhalb der Kontrolle des Zugangsbetreibers liegen. Widerstandsfähigkeit entsteht erst durch Tests der gesamten Kette.

Zu prüfen sind Ausfall des DHCP-Servers, konkurrierende Angebote, Resolverausfall, alte Records, Identitätswechsel, Verlust der lokalen Instanz und manuelle Ersatzkonfiguration. Ohne solche Ergebnisse bleibt „lokal“ ein Versprechen.

Aussagegrenze

Die Quellen belegen keine heutige Verbreitung, keinen realen Angriff, Ausfall, Produktfehler oder gescheiterten Notruf. RFC 3315 war die historische DHCPv6-Grundlage und wurde durch RFC 8415 ersetzt; daraus folgt keine Nutzungsstatistik.

Auch der bereits vergebene RFC-5222-Gegenstand wird nicht wiederholt. Dieser Beitrag endet früher: Der DHCP-FQDN ist eine Eingabe zur Suche. Autorität, Abbildung und Dienstleistung folgen nur mit eigenen Belegen.

Den Suchweg rekonstruierbar machen

Zu sichern sind Zugangsnetz, DHCP-Version und beobachtbare Herkunft, Optionscode, Rohdaten-Hash, Parsergebnis, FQDN und Wurzel, Zeit und Lease, Resolver und Sicht, U-NAPTR-Records, TTL, URI und Adresse, LoST-Identitätsprüfung, Anfrage, Antwort, Abbildungsalter und Ergebnis.

Ebenso wichtig sind fehlende oder konkurrierende Optionen, falsche Labels, Domänenwechsel, verschiedene DNS-Sichten, Ablauf, Authentisierungsfehler, manuelle Rückfälle und Nichterreichbarkeit. Sie zeigen die wirkliche Grenze.

Lu Hengs Vorrang der laufenden Wirklichkeit trennt die Zeugen: Das Zugangsnetz belegt DHCP, der Zonenverwalter die Delegation, der LoST-Betreiber den Dienst und die Anwendung das Ergebnis. Führung verbindet die Belege, ohne sie auszutauschen.

Sources

Ergänzende Unterlagen

  1. RFC 5223 als Klartext
  2. Informationsseite zu RFC 5223
  3. RFC 5223 im Datatracker
  4. Errata zu RFC 5223