Zusammenfassung

  • FCFS Naming bindet einen freien Namen an den ersten akzeptierten SIG(0)-Schlüssel; es beweist Schlüsselkontinuität, nicht Unternehmensidentität, Registrarherkunft oder Dienstgesundheit.
  • SRP- und gewöhnliche DNS-Update-Pfade dürfen nicht widersprüchlich über dieselben Records verfügen; Annahme, Veröffentlichung und Anwendungserfolg benötigen je einen eigenen Beleg.

Ein Gerät registriert seinen Dienst korrekt. Tage später ändert ein automatisches Zonensystem denselben SRV-Record mit einer anderen, herkömmlichen DNS-Update-Berechtigung. Beide Transaktionen sind für ihren jeweiligen Pfad authentisiert. Trotzdem kann nur eine der beiden Behauptungen die Zusage an den ersten SRP-Schlüssel einhalten.

RFC 9665 warnt genau vor dieser Schnittstelle. Seine Regeln validieren SRP Updates. Ein autoritativer Server kann zusätzlich andere Update-Arten akzeptieren. Wenn deren Berechtigungsbereiche dieselben Namen oder RRsets überlappen, kann der zweite Pfad den vom Registrar geschützten Zustand ersetzen.

Der technische Fehler ist keine ungültige Signatur. Es ist eine ungeklärte Rangordnung zweier gültiger Autoritäten.

Was FCFS leistet

SRP ermöglicht automatische DNS-SD-Registrierung ohne vorab verteiltes Shared Secret. Der Requester erzeugt ein gerätespezifisches Schlüsselpaar, legt den öffentlichen Teil als KEY ab und signiert das DNS Update mit SIG(0). Ist der Name frei, wird der erste Schlüssel zum Kontinuitätsanker. Solange sein KEY-LEASE läuft, darf ein anderer Schlüssel Host- und Dienstinstanznamen nicht übernehmen.

Das beweist: Der aktuelle Requester verfügt über denselben privaten Schlüssel wie der erste akzeptierte Claim. Es beweist nicht: Das Gerät gehört zur Organisation, der Nutzer ist berechtigt, die Software ist vertrauenswürdig oder der beworbene Dienst arbeitet korrekt.

Der Schlüssel soll stabil gespeichert und möglichst dauerhaft behalten werden. Factory Reset oder Eigentümerwechsel können einen neuen Schlüssel erfordern. Dann gehört der alte Name weiterhin dem alten Schlüssel, bis dessen Lease endet. Ein Lifecycle-Prozess muss deshalb Schlüsselvernichtung, Inventarwechsel, neuen Namen und Support zusammen behandeln.

Atomar am Eingang, verteilt bei der Ausgabe

Ein SRP Update enthält genau eine Host Description und kann mehrere Service Description- und Service Discovery-Anweisungen bündeln. Explizite RFC-2136-Prerequisites entfallen; der Registrar prüft die impliziten Beziehungen, denselben KEY, SIG(0), Update Lease und Namenskonflikte. Alles wird angenommen oder alles verworfen.

Diese Atomarität endet am Registrar. Er kann ein Hidden Primary sein, während andere autoritative Server die Antworten ausliefern. Journaling, Signierung und Replikation liegen zwischen NoError und öffentlicher Sichtbarkeit. Ein Betriebsnachweis muss jede tatsächlich antwortende Instanz prüfen.

Eine korrekte DNS-Antwort ist wiederum kein Dienstbeleg. Sie beschreibt Ziel, Port, Adresse und Metadaten. Erst eine passende Endpunktauthentisierung und eine ungefährliche Anwendungstransaktion zeigen, ob der angekündigte Dienst existiert und brauchbar ist.

Getrennte Uhren für Dienst und Name

PTR, SRV, A, AAAA und TXT verwenden gewöhnlich ein kürzeres LEASE, typischerweise etwa zwei Stunden. Der KEY-LEASE kann ungefähr vierzehn Tage betragen. So verschwindet ein abgeschalteter Dienst relativ schnell aus der Discovery, ohne dass sein Name sofort neu vergeben wird.

„Name reserviert, Dienst abgelaufen“ ist ein vorgesehener Zustand. Zusätzlich läuft die TTL-Uhr eines rekursiven Caches. Nach Lease-Ende darf die Autorität den RR nicht mehr liefern, doch eine kurz zuvor gecachte Antwort kann bis zum Rest-TTL sichtbar bleiben. Lease, KEY-LEASE und TTL gehören als getrennte Werte in die Evidenz.

Auch der Registrar ist nicht automatisch authentisiert

SIG(0) authentisiert den Requester gegenüber dem Registrar. Die Basisspezifikation legt keinen automatischen Mechanismus fest, mit dem der Requester die Antwort des Registrars validiert. Registrare müssen DNS over TLS anbieten; ohne validierten Server-Key bleibt es Opportunistic Privacy und darf nicht als nachgewiesene Registraridentität berichtet werden.

Ebenso wenig ersetzt die Signatur die Netzwerkzulassung. Registrare sollten Quellen außerhalb ihrer Verwaltungsdomäne abweisen. TCP stützt sich gegen Off-Path-Spoofing auf den Handshake, sofern Fast-Open-Daten nicht ohne gleichwertige Prüfung akzeptiert werden. UDP in Constrained Networks braucht Source- und Interface-Filter.

Autorität durch Namespace-Design begrenzen

SRP sollte nicht direkt auf einer Organisationszone angeboten werden. Sonst kann der erste automatische Claim Namen wie www, mail oder smtp besetzen. Eine eigene Discovery-Subdomain und eine Sperrliste reduzieren die Wirkung von FCFS auf den vorgesehenen Zweck.

Genau dort muss auch der konventionelle Update-Pfad enden. Entweder SRP und andere Credentials bearbeiten disjunkte Objekte, oder ihre Präzedenz, Ausnahmen und Auditdaten sind explizit. „Beide Signaturen waren gültig“ ist keine Konfliktlösung.

service.arpa. schafft ebenfalls keine globale Identität. Es ist lokal bedient. Ein Host mit externem Resolver kann die falsche Sicht erhalten oder gar keine. Anwendungen dürfen das Suffix nicht als besonderen Vertrauensbeweis behandeln; eine globale PKI-Identität entsteht daraus nicht. Öffentlich ausgelieferte KEYs können zudem Geräte verfolgen helfen.

Der belastbare Receipt

Dokumentiert werden Netzwerkbeitritt, Eingangsinterface, Registrierungsdomain, Registrar-Discovery, Transport und tatsächliche TLS-Validierung. Dazu kommen Update-Bytes, Host-Service-Graph, KEY-Fingerprint, Algorithmus, SIG(0)-Ergebnis, Konflikt, gewünschte und gewährte Leases sowie die Antwort.

Danach folgen Hidden-Primary-Ereignis, Signierung, Antworten jeder Serving Authority, rekursive Beobachtung und TTL sowie Endpunkt- und Anwendungstest. Zusätzlich wird jede Änderung durch nicht-SRP Credentials auf denselben RRsets erfasst. Nur so bleibt sichtbar, welche Autorität den Zustand tatsächlich verändert hat.

Quellen