Flytning af autoritative DNS -ændringer, hvor resolvere henter domænets data. En succesfuld navneserver forandring beviser ikke det SPF, DKIM, DMARC eller modtageruter overlevede. Bevar de effektive registreringer og afhængigheder, før du ændrer delegering, og hold både gamle og nye tjenester tilgængelige, mens caches kan bruge begge dele.
Inventar den effektive zone
Referencer: RFC 1034 §4.2, RFC 1035 §3.3.14, RFC 6376 §3.1.
Identificer den aktuelle overordnede delegation og alle autoritative servere. Få en autoriseret eksport- eller API-beholdning fra den faktiske DNS vært. En almindelig forespørgsel kan ikke opregne alle mulige DKIM vælger, så kombiner eksporten med konfiguration af afsendelsestjeneste og nylige signerede meddelelsesheadere. Inkluder apex SPF , DMARC , aktive og tilbagegående vælgere, brugerdefinerede retur-sti records, MX , deres adresseafhængigheder og transportpolitikposter, hvor de er implementeret.
Registrer nøjagtige ejernavne, typer, TTL'er og værdier. Bevar grænser TXT -ressourceregistrering og strengfragmenter. Beholdningsaliasser og underordnede delegeringer i stedet for kun at kopiere terminalværdien set af et rekursivt opslag. Udbyderfunktioner som f.eks. udfladning eller administrerede registreringer har brug for en eksplicit ækvivalent på destinationen; de overlever muligvis ikke en grundlæggende zone-fil-eksport.
Byg destinationen, før du skifter
Referencer: RFC 4034 §5, RFC 4035 §2.4.
Importer de gennemgåede data til destinationen, inspicér forskellen og forespørg direkte på hver ny autoritativ server. Dens SOA- og apex NS-værdier kan bevidst afvige fra den gamle udbyder; autentificeringsdata bør kun afvige, hvis migrationsplanen udtrykkeligt tillader en ændring. Kontroller, at indtastning af relativ-navn ikke duplikerede zonesuffikset.
For signerede zoner skal du koordinere den overordnede DS og den underordnede DNSKEY-overgang med udbydernes understøttede migreringsprocedure. Kopiering af almindelige poster uden koordinering DNSSEC kan få en validerende resolver til at afvise ellers synlige data. Slet ikke DS eller deaktiver validering som en improviseret standard. Bestem den nøjagtige kontinuitet eller overgangsprocedure, før du planlægger flytningen.
Genskab en manglende vælgerfejl
Brug en isoleret laboratoriezone ved navn eksempel.test. Den gamle myndighed har eksempel.test. 300 IN TXT " v=spf1 -all ", _dmarc.example.test. 300 IN TXT "v=DMARC1; p=none" og s1._domainkey.example .test. 300 IN TXT "fixture=selector-present". Den sidste værdi er en markør, ikke en DKIM nøgle. Forbered en destinationskopi, der bevidst udelader s1.
Løbe dig @OLD_IP s1._domainkey.example .test. TXT +norecurse og dig @NEW_IP s1._domainkey.example .test. TXT +norecurse, der erstatter laboratorieserveradresser. Den forventede sammenligning identificerer den manglende markør hos den nye myndighed. Gendan det, gentag alle nøjagtige ejer/type-forespørgsler og behold før-og-efter-svarene. Denne opstilling tester beholdningens fuldstændighed, ikke en gyldig DKIM signatur.
Skift og observer begge veje
Referencer: RFC 1034 §4.2, RFC 2308 §5, RFC 8767 §4.
Sænk gældende TTL'er tilstrækkeligt i forvejen, hvis den understøttede plan kræver det; gamle cachelagrede TTL'er forkortes ikke med tilbagevirkende kraft. RFC 8767 tillader også afgrænset forældet servering under specificerede betingelser for opdateringsfejl, så en TTL er ikke en universel forsvindingsfrist. Opdater forældredelegationen gennem det autoriserede registreringsworkflow, observer derefter forældrehenvisninger og rekursiv løsning samt direkte svar fra nye servere. Delegering, positive svar og negative svar kan have forskellige cachehistorier.
Behold den gamle DNS -tjeneste, indtil migreringens relevante cache og driftsbetingelser er ryddet. En rollback er en anden distribueret ændring, ikke en øjeblikkelig fortrydelse. Luk først, når registreringerne er enige, validerende løsning fungerer, hvor det er relevant, og repræsentative legitime poststier er blevet testet. Produktionsmigrering og posttests afventer fortsat. Den bevarede historiske armatur nedenfor giver et eksempel på afgrænset DNS bevaring.
Beholdt historisk laboratoriebevis
Den bevarede 7. november 2026-opsamling, inspiceret, men ikke genudført her, registrerer, at det isolerede socket-laboratorium forespurgte de gamle og nye faste zone-myndigheder for s1._domainkey.example .test. Destinationen returnerede oprindeligt NXDOMAIN , mens den gamle myndighed returnerede markøren. Efter den syntetiske tilføjelse beskrevet i den historiske runner, returnerede destinationen markøren. Den bevarede opsamling bevarer de nøjagtige forespørgselsnavne og før/efter svar for denne snævre registreringsbevarende sag; det er ikke en kundemigreringsplan eller -godkendelse. Capture-etiketterne er migration_missing_s1; migration_old_s1; migration_efter_reparation. Den historiske løber og råfangst er inkluderet i denne anmeldelsespakke; deres tilstedeværelse er ikke et nyt tvangspåstand. Produktions DNS , DNSSEC og SMTP resultater forbliver utestede.