Zusammenfassung

  • RFC 8005 lässt einen HIP RR die öffentliche Host Identity, ihren HIT und optionale Rendezvous-Namen tragen. Das ist eine Entdeckungsquelle, kein Lebenszeichen.
  • DNSSEC validiert DNS-Daten in einer Vertrauenskette, der TTL begrenzt ihre Cache-Nutzung. Beide sehen weder die aktuelle HIT-Adress-Registrierung im RVS noch den Einsatz des privaten Schlüssels.
  • Ein belastbarer Status verbindet den gewählten RR mit RVS-Adresse, aktueller Registrierung, I1-Weiterleitung, HI-basierter Authentisierung, HIP-Assoziation und Anwendungsergebnis.

Eine Stunde Cache wurde zur Verfügbarkeitszusage

Um 9 Uhr erhält ein Resolver den HIP RR eines mobilen Knotens. HI, HIT und RVS-Name entsprechen der Erwartung, DNSSEC validiert, der TTL beträgt eine Stunde. Eine Kontrolloberfläche macht daraus „Identität bestätigt und erreichbar“.

Zwölf Minuten später wechselt der Knoten das Netz. Sein Update der neuen Adresse erreicht den RVS nicht. Der DNS-Datensatz bleibt korrekt: Der veröffentlichte Rendezvous-Name stimmt, die Signatur ist gültig, der Cache noch verwendbar. Um 9:20 Uhr sendet ein Initiator I1; der RVS leitet anhand der alten Registrierung weiter.

Das Beispiel ist konstruiert und behauptet keinen realen Vorfall. Es zeigt, wie zwei wahre Aussagen nebeneinanderstehen: Der DNS-Eintrag ist frisch. Der Laufzeitpfad ist es nicht. Erst die Zusammenfassung erzeugt den falschen Widerspruch.

Öffentliche Identität ist kein aktueller Besitznachweis

RFC 5205 führte 2008 als Experimental RFC den Typ 55 ein. RFC 8005 löste ihn 2016 auf der Standards Track ab. Der RR enthält die öffentliche HI, den daraus gebildeten HIT und gegebenenfalls RVS-Domainnamen.

Die HI ist der öffentliche Teil des Schlüsselpaares. Der HIT bezeichnet sie in verkürzter Hashform. Beides sind Eingaben für den späteren Austausch. In der DNS-Antwort steht weder der private Schlüssel noch ein aktueller Beweis seiner Verwendung.

RFC 8005 rät deshalb davon ab, einen Peer allein anhand eines aus DNS geholten HIT zu authentisieren. Stattdessen soll HI-basierte Authentisierung stattfinden. Einen veröffentlichten Identifikator zu finden und im aktuellen Protokolllauf die Schlüsselverwendung zu prüfen, sind verschiedene Ereignisse.

Setzt ein Inventar nach der Auflösung sofort authenticated=true, überspringt es den entscheidenden Beleg. Der private Schlüssel kann offline sein, während seine öffentlichen Daten ordnungsgemäß veröffentlicht bleiben.

DNSSEC ist stark, aber thematisch begrenzt

Ohne Schutz könnte ein Angreifer die HI austauschen oder I1 umleiten. RFC 8005 fordert daher einen sicheren Kanal mit Datenintegrität und Authentizität und nennt DNSSEC.

Der Text beschränkt die Auslegung ausdrücklich. DNSSEC schützt die Daten zwischen dem Server, der die Zone veröffentlicht, und dem HIP-Knoten. Es macht den Zonenherausgeber nicht automatisch vertrauenswürdig. Die RRSIG des HIP RRset darf nicht als Zertifikat verstanden werden, das HI oder HIT an den Eigentümernamen bindet.

secure ist somit eine starke Aussage über Bytes, Kette, Vertrauensanker, Zeitpunkt und Validierungsrichtlinie. Es ist keine Beobachtung des Schlüsselspeichers, der RVS-Tabelle, des IP-Pfads oder des Anwendungsprozesses.

Kryptografische Gewissheit und semantische Breite sind unabhängig. Eine perfekte Signatur kann eine enge Aussage perfekt schützen; sie ergänzt keine nicht signierten Tatsachen.

Der TTL gehört dem Cache

RFC 8005 verlangt, den RR nach Überschreiten des TTL seit Abruf als ungültig zu löschen. Wird er für einen Kommunikationsbeginn benötigt, ist eine neue Abfrage erforderlich.

Diese Regel bestimmt die Wiederverwendung der Veröffentlichung. Sie reserviert keinen RVS-Eintrag, hält keinen Locator fest und verpflichtet den Endpunkt nicht, seinen Schlüssel für die gesamte Zeit verfügbar zu halten.

Auch eine neue Abfrage kann denselben frisch signierten RR liefern, während die dynamische Registrierung unverändert falsch ist. Eine erneuerte DNS-Quittung erneuert nur die DNS-Aussage.

Automatisierung verwechselt beides, weil sich der TTL lokal und billig berechnen lässt. cacheAge < ttl erlaubt die Nutzung der DNS-Daten; es erlaubt nicht endpointLive=true.

RVS-Name und RVS-Zustand liegen in getrennten Systemen

Für Mobilität veröffentlicht der Knoten relativ stabile RVS-Namen und hält den Server separat über aktuelle IP-Adressen auf dem Laufenden. RFC 8004 beschreibt die laufende Registrierung, die der RVS vor der I1-Weiterleitung prüft.

Der Name kann korrekt aufgelöst werden, obwohl für den HIT kein aktueller Eintrag existiert. Der Server kann erreichbar sein, aber einen alten Locator speichern. Selbst eine Weiterleitung beweist noch nicht den Empfang beim Endpunkt.

Eine ehrliche Beweiskette lautet:

HIP RR veröffentlicht → DNSSEC validiert → TTL gültig → RVS gewählt → Registrierung aktuell → I1 weitergeleitet → HI authentisiert → Assoziation fertig → Wirkung beobachtet.

Jeder Pfeil überschreitet eine Zuständigkeit. Fehlt die nächste Quittung, lautet der Zustand „unbekannt“ und erbt nicht das Grün der vorherigen Spalte.

Mehrere RR verlangen Herkunftstreue

Unter einem Namen dürfen mehrere HIP RR stehen. RFC 8005 legt ihre Auswahl nicht fest. RVS-Angaben können variieren; bei mehreren Möglichkeiten muss der Host prüfen, dass der benutzte RVS zur benutzten HI gehört.

Wer alle HI und alle RVS in getrennte Mengen normalisiert, kann Kombinationen erzeugen, die nie veröffentlicht wurden. Bei Schlüsselrotation stehen alte und neue Einträge nebeneinander; eine verlorene Zuordnung koppelt leicht den neuen Schlüssel an den alten Weg.

Der Betriebsbeleg muss jeden RR als Einheit halten: Algorithmus, HI, HIT, RVS, TTL, Antwortfingerabdruck und Auswahlgrund. Nur dann lässt sich eine Störung dem tatsächlich konsumierten Datensatz zuordnen.

Der Beleg für Erreichbarkeit

Er beginnt mit Abfragename, Resolver, autoritativem Server, Zeiten und Paketfingerabdruck; enthält das vollständige RRset, DNSSEC-Anker und Richtlinie, Abrufzeit, Cache-Alter, TTL und erneute Abfrage. Die A/AAAA-Antworten des RVS haben eigene Zeiten und Validierungen.

Zur Laufzeit gehören Registrierungs-ID, HIT, Locator, Refresh, Ablauf, Widerruf und Konfigurationsepoche. I1-Versand, RVS-Eingang, Tabellenabfrage, Weiterleitung und Empfang werden verbunden. Danach folgen HI-Authentisierung, Zustände beider Peers und separat Nutzdatenpfad und Anwendungsergebnis.

RFC 8005 ergänzte ECDSA, TTL-Neuabfrage, Mehrfach-RR und Formatdetails. Seine Veröffentlichung beweist keine Migration eines laufenden Builds. Version, Binärstand, Konfiguration und Pakete bleiben nötig.

Die Begrenzung macht den HIP RR nicht schwächer. Eine präzise Anzeige würde melden: „RR sicher; TTL aktuell; RVS-Registrierung unbestätigt; Erreichbarkeit unbekannt.“ Sie weist auf das fehlende Mobilitätsupdate, statt eine korrekt arbeitende Zone zu verdächtigen.

Quellen