Zusammenfassung

  • Ein DET liegt in 2001:30::/28 und ist eine gültige, aber nicht routbare IPv6-Adresse. Seine Adressform trägt eine Kennungshierarchie, kein Paketziel und keine Koordinate.
  • HHIT RR Typ 67 enthält Registrierungsmetadaten und das kanonische Registrierungszertifikat; BRID RR Typ 68 hält statische Broadcast-RID-Informationen und Endorsements.
  • DNSSEC validiert die DNS-Antwort, während Live-Position, gegenwärtiger Schlüsselbesitz, privater Zugriff, Betriebszustand und rechtliche Befugnis getrennt belegt werden müssen.

Die Leitstelle hat keinen Funkkontakt und keine Sichtmeldung. Trotzdem zeigt das System eine vollständige grüne Kette: Die umgekehrte Kennung antwortet, HHIT und BRID sind vorhanden, DNSSEC ist gültig, Zertifikat und Endorsements lassen sich prüfen. Der nächste Automatismus würde daraus „Luftfahrzeug geortet“ machen.

Nicht in der Kette fehlt ein Datensatz. Es fehlt eine Messung der physischen Welt.

RFC 9886 standardisiert Registrierung und Suche von DRIP Entity Tags, kurz DETs, über DNS. Damit lassen sich Kennungshierarchie, öffentlicher Schlüssel und Registrierungsbelege finden. Ein Nameserver überwacht aber keinen Luftraum. Die Abfrage kann eine Registerfrage beantworten, ohne die Standortfrage überhaupt zu berühren.

Die Verwechslung beginnt bei der Form. RFC 9374 weist DETs 2001:30::/28 zu und bezeichnet HHITs als gültige, jedoch nicht routbare IPv6-Adressen. So passen sie in bestehende 128-Bit-Strukturen und die inverse DNS-Namensbildung. Sie sind keine Route zum Fluggerät und enthalten weder Breiten- noch Längengrad.

Die Reverse-Domain des Präfixes lautet 3.0.0.1.0.0.2.ip6.arpa. Der einzelne DET wird wie bei IPv6 nibbleweise umgekehrt. Abgefragt wird jedoch nicht der klassische PTR, sondern ein eigens definierter HHIT- oder BRID-Typ. Das Ergebnis beschreibt eine Kennung.

Zwei Records belegen zwei verschiedene Sachverhalte

Jeder DET muss sich in einen HHIT-Record auflösen lassen. Für UAS Remote ID muss zusätzlich ein BRID-Record vorhanden sein. Beide Einträge sind nicht dieselbe Statusmeldung in zwei Formaten.

HHIT RR Typ 67 umfasst Entitätstyp, eine Kurzform der Hierarchie und das kanonische Registrierungszertifikat. Darin steht der öffentliche Schlüssel der Entität, signiert vom Registrar oder einem anderen Vertrauensanker. Eine erfolgreiche Kettenprüfung stützt die Aussage, dass die schlüsselabgeleitete Kennung in der angegebenen Hierarchie registriert wurde. Eine URI kann auf private Informationen verweisen.

BRID RR Typ 68 enthält statische Informationen aus dem Broadcast-RID-Umfeld. Im Mittelpunkt stehen Broadcast Endorsements, die der Registrar nach erfolgreicher Registrierung erzeugt. Der Record kann über Funk verpasste statische Angaben ergänzen oder einen Abgleich ermöglichen.

Seine Existenz beweist keine Funkbeobachtung im aktuellen Einsatz. DNS ist ein öffentliches Registermedium; Broadcast RID ist ein lokales Funkereignis mit eigenem Empfänger, Zeitstempel und Reichweitenlimit. Der gemeinsame Begriff hebt diese Trennung nicht auf.

RFC 9434 warnt außerdem: Ein selbst behaupteter DET beweist die Senderidentität nicht. Alte signierte Inhalte können wiederholt werden. Aktueller Schlüsselbesitz erfordert eine Signatur über neue, wechselnde und extern überprüfbare Daten—etwa Zeit und Position, die zum tatsächlich beobachteten Fluggerät passen. Nachrichtenauthentisierung und unabhängige Ortung bleiben dennoch unterschiedliche Prüfungen.

DNSSEC authentisiert die Antwort, nicht den Himmel

RFC 9886 verlangt DNSSEC für Apex-Entitäten mit selbst signiertem kanonischem Registrierungszertifikat und empfiehlt es für andere. Ohne DNSSEC können gefälschte Antworten Denial of Service, Replay, Identitätsvortäuschung oder Klonen von Fluggeräten, Übernahme einer DET-Registrierung, falsche Metadaten und beschädigte Vertrauensbeziehungen fördern. Ohne DNSSEC muss ein Client die HHIT-Zertifikatskette ablaufen; BRID-Endorsements behalten ihre eigene Prüfung.

Der kryptografische Erfolg ist wesentlich, aber begrenzt. DNSSEC belegt Herkunft und Integrität der DNS-Daten innerhalb der Validierungskette. Es sieht kein Luftfahrzeug, kennt den aktuellen Besitzer des privaten Schlüssels nicht, meldet keinen laufenden Flug, prüft keine Koordinate und erteilt keine behördliche Erlaubnis.

Eine Zone kann eine sachlich falsche Aussage korrekt signieren. Ein authentischer Record kann für eine gegenwärtige Entscheidung zu alt sein. secure bezeichnet einen DNS-Validierungszustand, kein allgemeines Wahrheitsurteil.

Ein Verweis auf private Daten ist kein Zugangsrecht

Das öffentliche Register kann zu privaten Informationen verweisen. RFC 9886 spezifiziert bewusst nicht die Authentisierung, Autorisierung und Abrechnung, mit denen private Register personenbezogene Daten schützen. RFC 9434 ordnet dort etwa Herstellerseriennummern und Operational-Intent-Kennungen ein.

Eine Sicherheitsbehörde, ein Luftraumdienst und eine Privatperson können daher mit demselben DET beginnen und rechtmäßig verschiedene Antworten erhalten. DNS nennt den Dienst. Das private Register entscheidet nach Antragsteller, Zweck und lokaler Regel. Eine erfolgreiche öffentliche Suche ist kein privates Berechtigungstoken.

Auch eine offengelegte Identität genehmigt weder Flug noch Eingriff. Der Registrar registriert, steuert aber kein Fluggerät. Ein UAS Service Supplier kann einen Betrieb melden, ohne Regulierer zu sein. Ein Funkempfänger kann eine Nachricht authentisieren, ohne deren selbst gemeldete Position zu garantieren.

Veröffentlichung und Betrieb haben eigene Uhren

Ein HHIT-Record unter einem DET legt den zur Signaturprüfung nötigen öffentlichen Schlüssel offen. RFC 9886 empfiehlt deshalb, ihn soweit praktikabel erst bei Bedarf zu veröffentlichen. Ein UAS oder UTM-Bestandteil könnte signalisieren, dass ein Einsatz mit Specific Session ID bevorsteht oder beendet ist.

Das ist eine sinnvolle Idee zur Expositionsminderung, aber kein fertiges Lebenszyklusprotokoll. Just-in-time-Publikation zusammen mit DNSSEC liegt außerhalb des Dokuments. Ein fehlender Record kann fehlenden Betrieb, Publikationsfehler, defekte Delegation oder eine Richtlinie bedeuten. Ein vorhandener Record kann nach dem Flug fortbestehen. Automatisierung muss den Grund erhalten und darf keine einheitliche Fluglage erfinden.

Die Standards liefern eng begrenzte Belege, keinen universellen Schalter „Drohne geortet“. Running-Code-Primat heißt hier: Nur das Ergebnis verwenden, das die konkrete Komponente zur beobachteten Zeit und für ihren definierten Zweck tatsächlich erzeugt hat.

Quellen