Het verplaatsen van een ondertekende zone is een gecoördineerde vertrouwenstransitie. De registrar kan de delegatie en DS-wijzigingen beheren, terwijl de oude en nieuwe DNS providers zonegegevens en ondertekeningssleutels beheren. Een succesvolle import bewijst niet dat validerende solvers elke tussenliggende status kunnen volgen.
Inventariseer het oude vertrouwenspad
Referenties: RFC 6781 §4.3.5.
Exporteer gewone records, DNSKEY- en DS-gegevens, ondertekeningsconfiguratie, relevante TTL's en autoriteitsadressen. Leg vast wie bovenliggende NS- en DS-gegevens kan wijzigen. Bevestig of de nieuwe provider het importeren van bestaande sleutels, gecoördineerde ondertekening of alleen een nieuwe, onafhankelijke sleutelset ondersteunt. Exporteer geen privé-ondertekeningssleutels, tenzij een goedgekeurde veilige procedure en compatibele providers dit vereisen.
Voordat u een migratiemethode kiest, moet u testen of de nieuwe autoriteiten consistent de volledige zone bedienen. Inclusief MX , selectors, authenticatie TXT en TLSA records. Behoud het gedrag bij negatieve antwoorden en bestaande delegaties. Een nieuwe gezonde DNSSEC chain compenseert geen ontbrekende postrecords.
Kies een gedocumenteerde transitie
Referenties: RFC 6781 §4.1, RFC 6781 §4.3.5, RFC 8767 §4.
RFC 6781 beschrijft overwegingen DNSSEC rollover en operatorwijzigingen. Er is geen veilige universele volgorde, onafhankelijk van de mogelijkheden van de provider. Een gecoördineerde transitie kan ervoor zorgen dat oude en nieuwe validatiepaden bruikbaar blijven, terwijl in de cache opgeslagen DS-, DNSKEY- en NS-informatie elkaar overlappen. Als de aanbieders de gekozen aanpak niet kunnen ondersteunen, regel dan een gedocumenteerde transitie met hen in plaats van een timing-shortcut te bedenken.
Een doelbewuste migratie van ondertekend naar niet-ondertekend naar ondertekend is een beveiligingsdowngrade met zijn eigen afhankelijkheidsvolgorde en wachttijden. Ouder-DS mag niet blijven verwijzen naar een onbruikbare onderliggende sleutel. Omgekeerd kan het toevoegen van een nieuwe DS voordat het corresponderende ondertekende kind bereikbaar is, tot mislukkingen leiden. Het verlagen van de TTL net vóór het overschakelen verkort de levensduur van records die al in de cache zijn opgeslagen met een oudere TTL niet. RFC 8767 staat verouderde weergave toe onder gespecificeerde omstandigheden bij verversingsfouten; Beschouw het verlopen van TTL niet alleen als bewijs dat elk afhankelijk pad de oude gegevens heeft verwijderd.
Oefen incompatibele cachestatussen
Referenties: RFC 6781 §4.3.5, RFC 4035 §5.
Bouw een wegwerpouder en twee gezaghebbende kinderopvangvoorzieningen. Definieer oude DS/sleutel A en nieuwe DS/sleutel B, plus vaste MX en TLSA-testgegevens. Test ten minste vier resolutiestatussen: oude delegatie met oude vertrouwensgegevens, nieuwe delegatie met compatibele vertrouwensgegevens, oude in de cache opgeslagen DS met alleen nieuwe sleutels, en nieuwe in de cache opgeslagen DS met alleen oude sleutels. De laatste twee zijn gevallen van opzettelijke onverenigbaarheid en geen aanvaardbare overgangstoestanden.
Bewaar voor elke status de bovenliggende DS-, onderliggende DNSKEY- en RRSIG-gegevens, de cache-instellingen van de solver, de klok, de exacte query en de validatortracering. Herhaal dit voor, tijdens en na de gekozen overlap. Controleer de koppeling tussen certificaat en TLSA afzonderlijk als het e-maileindpunt verandert. Dit zijn vereisten voor een op een oplosser gebaseerde migratietest. De onderstaande offline cryptografische matrix heeft alleen betrekking op de compatibiliteit van ondertekende gegevens, niet op een live migratie.
Maak van het terugdraaien een vertrouwensoperatie
Referenties: RFC 6781 §4.3.5, RFC 4035 §5.
Als u NS terugzet, wordt de DS- of DNSKEY-informatie in de cache niet gewist. Een rollback-plan moet specificeren welke sleutels beschikbaar blijven en welke combinaties in de cache nog geldig zijn. Houd de oude dienst en het benodigde tekenmateriaal beschikbaar voor de goedgekeurde overlap, met bewaakte pensioencriteria in plaats van een handige kalenderdatum.
Vergelijk na de cutover elke gezaghebbende server, meerdere relevante oplosserpaden en representatieve e-mailtests. Bevestig de validatie na de verwachte cache-overgangen en beëindig vervolgens de oude infrastructuur via het wijzigingsproces. Bewaar het exacte definitieve DS- en delegatiebewijs, zodat de volgende operator het resulterende vertrouwenspad kan uitleggen.
Waargenomen synthetische migratiematrix
Referenties: RFC 4035 §5.
Een behouden cryptografisch laboratorium van 7 november 2026, geïnspecteerd maar niet opnieuw uitgevoerd voor deze beoordeling, testte zeven ondertekende gegevensstaten. Oude DS/sleutel A, overlappende A/B DS met sleutel A, overlappende DS met sleutel B en definitieve DS/sleutel B, allemaal gevalideerd. De oude DS met alleen de nieuwe sleutel B mislukte, evenals het terugdraaien naar sleutel A na het vervangen van de DS door alleen B. Matching herstellen Een materiaal dat opnieuw is gevalideerd. Dit zijn daadwerkelijke handtekening- en DS-controles met gegenereerde testsleutels, geen gesimuleerde paslabels. Ze demonstreren incompatibele combinaties van gegevens in de cache, maar emuleren geen solver-cache, provider-API of verstreken TTL-overgang. Live providermigratie, timing en rollback-uitvoering blijven in behandeling.