Zusammenfassung

  • Die Homenet Naming Authority erzeugt und signiert die öffentliche Zone und behält das private DNSSEC-Schlüsselmaterial; Distribution Manager und öffentliche autoritative Server übernehmen die Sichtbarkeit im Internet.
  • Gegenseitiges TLS belegt die Peers eines geschützten Kanals, aber weder Domainberechtigung noch Parent-DS, vollständige Verteilung oder externe Validierung.
  • Belastbare Autorität verlangt getrennte Belege für Berechtigung, signierte Generation, Transfer, Auslieferung, Delegation, Beobachtung und vollständigen Rückzug.

Eine Löschung, die öffentlich noch nicht stattgefunden hat

Die HNA sendet eine korrekt authentifizierte Löschanweisung. Der Distribution Manager antwortet mit NOERROR. Im internen System ist die Delegation entfernt. Dennoch beantwortet ein öffentlicher Standort weiterhin Anfragen, und rekursive Resolver halten alte Antworten im Cache.

Das ist kein vom RFC berichteter Vorfall, sondern eine Konsequenz seiner Grenzziehung. Die Antwort des DM beschreibt seinen eigenen Zustand. Sie ist kein Nachweis dafür, dass jede öffentliche Instanz aufgehört hat zu antworten, dass NS oder DS im Parent angepasst wurden oder dass Caches abgelaufen sind.

Die Stärke von RFC 9526 liegt darin, diese Zuständigkeiten nicht als einen einzigen DNS-Schalter zu behandeln. Das Heimnetz erstellt und signiert. Die Outsourcing-Infrastruktur übernimmt und verteilt. Eine Registrar- oder Parent-Beziehung verbindet die Vertrauenskette. Externe Resolver beobachten das Ergebnis. Kontrolle ist nur dann real, wenn sie auch den nachweisbaren Entzug umfasst.

Eine öffentliche Zone ist nicht das Inventar von home.arpa

Das Verfahren betrifft eine Public Homenet Zone unter einer registrierten Domain. Die interne Homenet Zone home.arpa bleibt lokal und gehört nicht zum öffentlichen Ablauf. Eine automatische Entdeckung im Heimnetz ist daher noch keine Freigabe für das Internet.

Die HNA kann Kandidaten aus DHCP, mDNS, UPnP, PCP oder manueller Konfiguration sammeln. Anschließend muss sie auswählen. Link-Local-Adressen gehören nicht in die öffentliche Zone. Private Adressen oder ULA können über ein VPN nützlich sein; eine auflösbare Adresse sagt jedoch nichts darüber, wer den Dienst erreichen darf.

Der erste Nachweis sollte die Auswahl selbst festhalten: eingeschlossene Namen, Ausschlüsse, Regelversion, Genehmigung und Zweck. Eine fertige Zonendatei erklärt später nicht, ob ein Gerätename absichtlich veröffentlicht, automatisch übernommen oder nach der Stilllegung vergessen wurde.

Namen tragen zudem längerfristige Privatsphärenrisiken. Sie sind oft stabiler und aussagekräftiger als wechselnde Adressen. NSEC3 und geschützte Zonentransfers erschweren bestimmte Aufzählungen, beseitigen aber weder öffentliche Abfragen noch Verkehrsbeobachtung.

Der kryptografische Autor bleibt verborgen

RFC 9526 weist der HNA die Erstellung des gesamten Zoneninhalts zu. Sie signiert mit DNSSEC und verwaltet das private Schlüsselmaterial. Ein Transfer privater DNSSEC-Schlüssel zum DM ist nicht vorgesehen.

Die HNA ist ein Hidden Primary. Ihre Adresse soll ohne zusätzliche Schutzmaßnahmen nicht im öffentlichen NS-Satz erscheinen, und sie soll keine gewöhnlichen Internetanfragen beantworten. Diese Aufgabe übernehmen die autoritativen Server der DNS Outsourcing Infrastructure.

Die Trennung beschränkt den Dienstleister. Er erhält eine signierte Aussage, nicht die Fähigkeit, eine neue authentische Aussage zu erfinden. Gleichwohl kontrolliert er, ob und wann er eine Generation abholt, wie sie in seiner Infrastruktur verteilt wird und ob eine ältere, noch gültig signierte Version sichtbar bleibt.

„Signiert“ und „öffentlich“ müssen deshalb zwei Statuswerte sein. Der erste braucht Seriennummer, Hash, DNSKEY und Gültigkeitszeitraum. Der zweite braucht Instanzen, beobachtete Version und Messzeit. Ein grüner Signaturstatus darf nicht stillschweigend die Veröffentlichung bestätigen.

Zwei Kanäle, umgekehrte Rollen

Im Control Channel initiiert die HNA die Verbindung zum DM. Beide Seiten authentisieren sich über TLS und tauschen Parameter für Delegation, DS und Synchronisation aus.

Im Synchronization Channel wird der DM zum TLS-Client, während die HNA Server und Hidden Primary ist. AXFR oder IXFR überträgt die Zone. NOTIFY beschleunigt die Prüfung; SOA-Zeitwerte erlauben dem Secondary, Änderungen auch ohne Benachrichtigung zu entdecken.

Selbst bei denselben Adressen und Ports bleiben die Aussagen verschieden. Der geschützte Kontrollkanal beweist Teilnehmer gemäß einer Vertrauensregel. Der Transfer beweist nur dann eine bestimmte Generation, wenn Seriennummer, Inhalt und Readback verbunden werden. Beide zusammen sagen noch nichts über die nachgelagerte öffentliche Flotte.

Auch die HNA-Identität ist nicht automatisch ein Eigentumsnachweis für die Registered Homenet Domain. Gerätezertifikat, Domainkonto und DNSSEC-Schlüssel können getrennte Besitzer und Lebenszyklen haben. Authentisierung, Berechtigung, Ausführung und Ergebnis sind aufeinanderfolgende Prüfungen.

Die öffentliche Verteilung bleibt anbieterspezifisch

Der DM empfängt die Zone als Hidden Secondary und bringt sie zu den öffentlichen Servern. RFC 9526 nennt diesen Weg Distribution Channel, legt aber kein einziges Verfahren fest. AXFR, Datenbankkopie, REST oder andere Mechanismen sind möglich.

Diese Offenheit schützt vorhandene Plattformen, schafft aber eine Nachweislücke. Ein erfolgreicher Transfer HNA–DM ist keine Quittung jeder Edge-Instanz. Anycast kann Regionen, Softwarestände und getrennte Rollout-Warteschlangen hinter einer Adresse verbergen.

Der DOI sollte deshalb pro Generation festhalten, was der DM angenommen hat, welche Ziele den Stand installiert haben und welche SOA- und DNSKEY-Werte die öffentlichen Klassen zurückgeben. Externe Messungen aus mehreren Netzen sind wertvolle Beobachtungen, aber kein vollständiges internes Inventar.

Eine präzise Aussage lautet: „Der DM nahm Generation 108 an; vier Perspektiven lieferten 108, eine noch 107.“ Das ist handlungsfähig. „Veröffentlichung erfolgreich“ verdeckt dagegen Ort und Dauer der Abweichung.

NOERROR ist ein Versprechen an den Parent

Die HNA übermittelt den Hash ihrer KSK als DS. Verfügt der DOI über die nötige Registrar- oder Registry-Beziehung, kann er die Parent-Zone aktualisieren. Nimmt der DM die Anforderung an, antwortet er mit NOERROR als Zusage, den DS im Parent zu ändern.

Die Zusage endet am DM. Sie ist weder Readback der Parent-Zone noch Abschluss des Registry-Prozesses oder Ablauf alter Caches. Ein alter DS kann bleiben, ein Konto kann die Berechtigung verlieren oder mehrere Werte können unerwartet nebeneinander bestehen.

Eine sichere Delegation besteht erst, wenn die Child-Zone signiert ist, der passende DS im Parent steht und ein Validator die Kette aufbauen kann. Der RFC verlangt die Signatur sogar dann, wenn die HNA keine sichere Delegation einrichten kann. Eine gültige Signatur kann also vom öffentlichen Vertrauenspfad getrennt sein.

Der Betriebsnachweis braucht den eingereichten DS, die DM-Antwort, das unabhängige Parent-Readback und ein externes Validierungsergebnis. Ein Feld „DNSSEC aktiv“ macht bei Rollovers unsichtbar, welche Grenze gebrochen ist.

Domainbesitz liegt vor dem Protokoll

Der DOI darf die Zone nicht bereitstellen, wenn er nicht überzeugt ist, dass die HNA die registrierte Domain besitzt. Der Eigentumsnachweis liegt jedoch außerhalb des RFC. Vor der technischen Sitzung steht daher eine Governance-Entscheidung.

Ist der DOI zugleich Registrar, können Kundenkonto und Vertrag die Grundlage bilden. Bei einem unabhängigen DNS-Anbieter ist eine andere Prüfung nötig. Domainrecht, Control-Channel-Zertifikat und DNSSEC-Schlüssel können unterschiedliche Verwahrer, Ablaufzeiten und Wiederherstellungswege haben.

Ein Migrationsplan muss zeigen, wer den Parent ändern darf, welche HNA-Identität den DM steuert, welcher Schlüssel die aktive Zone signiert und wann der alte Anbieter aufhört zu antworten. Eine Zonensicherung stellt nicht automatisch die Steueridentität wieder her. Ein neuer Schlüssel überträgt nicht das Domainrecht.

Rückzug ist eine Kette, kein einzelner Befehl

Die HNA muss eine Delegation bei einem bestimmten DM löschen können. Der DM soll danach die Zone nicht mehr bereitstellen und darf NOERROR als Löschbestätigung liefern.

Der vollständige Nachweis beobachtet Abwesenheit: alter DM, alle bekannten autoritativen Ziele, NS und DS im Parent, Signaturrestlaufzeit, Cachehorizont und Start des Nachfolgers. Solange die alte Plattform antwortet, besteht ein Rest operativer Autorität.

Die Löschung einer inaktiven HNA richtet sich außerdem nach dem Geschäftsvertrag. Das technische Recht des Kunden zum Rückzug und das vertragliche Recht des Anbieters zur Bereinigung sind nicht gleich. Sie brauchen getrennte Fristen, Verantwortliche und Einspruchswege.

Renumbering verteilt die Wahrheit über mehrere Uhren

Ändert sich das Präfix, aktualisiert die HNA Adressen, teilt dem DM ihren neuen Synchronisationsort mit und stößt einen weiteren Transfer an. Bei Make-before-break koexistieren alte und neue Präfixe. Bei abruptem Renumbering fällt das alte aus, bevor das neue bereitsteht.

Die HNA soll ihren Ort bei jedem Start aktualisieren, weil sie weder die Offline-Dauer noch den Ablauf ihrer signierten Zone sicher kennt. Beabsichtigte Adresse, HNA-Serie, DM-Kopie, öffentliche Kopien, Parent und Caches ändern sich nicht atomar.

Monitoring muss diese Uhren vergleichen. Eine alte Adresse kann korrekt gecacht und dennoch unerreichbar sein. Eine neue kann vor der passenden Firewall-Regel erscheinen. Lokale Auflösung kann bei WAN-Ausfall weitergehen, während die öffentliche Seite veraltet. Entscheidend ist, welche Generation jede Grenze zu welchem Zeitpunkt akzeptiert.

Quellen

Quellen