Flytta auktoritativa DNS -ändringar där resolvers hämtar domänens data. En framgångsrik namnserver förändring bevisar inte det SPF, DKIM, DMARC eller mottagningsvägar överlevde. Bevara effektiva register och beroenden innan du ändrar delegering, och håll både gamla och nya tjänster tillgängliga medan cacher kan använda båda.
Inventera den effektiva zonen
Referenser: RFC 1034 §4.2, RFC 1035 §3.3.14, RFC 6376 §3.1.
Identifiera den nuvarande överordnade delegationen och alla auktoritativa servrar. Skaffa en auktoriserad export- eller API-inventering från den faktiska DNS värden. En vanlig fråga kan inte räkna upp alla möjliga DKIM väljare, så kombinera exporten med konfigurationen av sändningstjänsten och rubriker för senaste signerade meddelanden. Inkludera apex SPF , DMARC , aktiva och utgående väljare, anpassade returväg poster, MX , deras adressberoenden och transportpolicyposter där de distribueras.
Registrera exakta ägarnamn, typer, TTL:er och värden. Bevara TXT -resurspostgränser och strängfragment. Inventeringsalias och underordnade delegationer istället för att kopiera endast terminalvärdet som ses av en rekursiv sökning. Leverantörsfunktioner såsom utjämning eller hanterade poster behöver en explicit motsvarighet på destinationen; de kanske inte överlever en grundläggande zonfilsexport.
Bygg resmålet innan du byter
Referenser: RFC 4034 §5, RFC 4035 §2.4.
Importera granskad data till destinationen, inspektera skillnaden och fråga varje ny auktoritativ server direkt. Dess SOA- och apex NS-värden kan avsiktligt skilja sig från den gamla leverantören; autentiseringsdata bör endast skilja sig åt när migreringsplanen uttryckligen tillåter en ändring. Kontrollera att inmatning av relativnamn inte duplicerade zonsuffixet.
För undertecknade zoner, samordna övergången till den överordnade DS och den underordnade DNSKEY med leverantörernas understödda migreringsprocedur. Kopiering av vanliga register utan samordning DNSSEC kan få en validerande resolver att avvisa annars synlig data. Ta inte bort DS eller inaktivera validering som en improviserad standard. Bestäm den exakta kontinuiteten eller övergångsproceduren innan du schemalägger flytten.
Återskapa ett misslyckat väljarfel
Använd en isolerad labbzon med namnet example.test. Den gamla myndigheten har exempel.test. 300 IN TXT " v=spf1 -all ", _dmarc.example.test. 300 IN TXT "v=DMARC1; p=none" och s1._domainkey.example .test. 300 IN TXT "fixture=selector-present". Det sista värdet är en markör, inte en DKIM nyckel. Förbered en destinationskopia som medvetet utelämnar s1.
Sikt dig @OLD_IP s1._domainkey.example .test. TXT +norecurse och dig @NEW_IP s1._domainkey.example .test. TXT +norecurse, ersätter labbserveradresser. Den förväntade jämförelsen identifierar den saknade markören hos den nya myndigheten. Återställ det, upprepa alla exakta ägare/typfrågor och behåll före- och eftersvaren. Denna fixtur testar inventeringens fullständighet, inte en giltig DKIM signatur.
Växla och observera båda vägarna
Referenser: RFC 1034 §4.2, RFC 2308 §5, RFC 8767 §4.
Sänk tillämpliga TTLs tillräckligt i förväg om planen som stöds kräver det; gamla cachade TTL:er förkortas inte retroaktivt. RFC 8767 tillåter också begränsad inaktuell servering under specificerade förhållanden med uppdateringsfel, så en TTL är inte en universell försvinnande deadline. Uppdatera den överordnade delegeringen genom det auktoriserade registreringsarbetsflödet, observera sedan föräldrahänvisningar och rekursiv upplösning samt direkta svar från nya server. Delegering, positiva svar och negativa svar kan ha olika cachningshistorik.
Behåll den gamla DNS tjänsten tills migreringens relevanta cache och driftsförhållanden har rensats. En återställning är en annan distribuerad förändring, inte en omedelbar ångra. Stäng endast efter att posterna överensstämmer, validerande lösning fungerar där tillämpligt och representativa legitima e-postvägar har testats. Produktionsmigrering och posttester kvarstår. Den bevarade historiska fixturen nedan ger ett exempel på bevarande av begränsat DNS .
Behållit historiskt labbbevis
Den bevarade insamlingen den 7 november 2026, inspekterad men inte körd här, registrerar att det isolerade socket-labbet frågade de gamla och nya myndigheterna för fasta zoner för s1._domainkey.example .test. Destinationen returnerade initialt NXDOMAIN , medan den gamla myndigheten returnerade markören. Efter det syntetiska tillägget som beskrivs i den historiska löparen, returnerade destinationen markören. Den bibehållna infångningen bevarar de exakta frågenamnen och före/efter-svaren för detta snäva postbevarande fall; det är inte en kundmigreringsplan eller godkännande. Infångningsetiketterna är migration_missing_s1; migration_old_s1; migration_efter_reparation. Den historiska löparen och råfångsten ingår i detta recensionspaket; deras närvaro är inte ett nytt exekutionskrav. Produktionsresultat för DNS , DNSSEC och SMTP förblir oprövade.