Durant una migració, els resolvers poden conservar la resposta anterior fins que caduqui el TTL publicat. El trànsit dividit també pot continuar per un AAAA o www sense actualitzar, nameservers inconsistents, un fitxer hosts o un origen antic a la CDN.
Protegeix primer les escriptures: dues bases de dades actives poden divergir encara que tots dos webs semblin normals.
Demostra quin servidor ha respost
Afegeix temporalment una capçalera de diagnòstic segura o un marcador estàtic diferent a cada servidor i prova des de les xarxes afectades.
Registra:
hostname sol·licitat
resolver utilitzat
resposta A i AAAA
marcador del servidor
certificat TLS
data, hora i zona horàriaNo exposis noms interns, versions ni IPs més temps del necessari.
Consulta els registres autoritatius
Confirma la delegació del registrador i consulta directament el proveïdor autoritatiu. Revisa l’arrel, www, wildcard, A, AAAA i CNAME.
Si han canviat els nameservers, també influeixen el TTL de la delegació pare i les memòries cau. Editar el proveïdor antic ja no té efecte després de moure la delegació.
No alternis repetidament els valors: cada canvi crea una nova població de memòria cau.
Calcula la finestra real
Utilitza el TTL publicat abans del canvi, no el valor reduït posteriorment. Un resolver pot conservar la IP antiga durant el temps restant d’aquell TTL.
Alguns resolvers imposen mínims. El navegador, sistema operatiu, service worker i CDN afegeixen capes separades. Documenta el màxim esperat i consulta diversos resolvers; un comprovador global només n’ofereix una mostra.
Revisa IPv6 i subdominis
Un AAAA antic afecta usuaris amb IPv6 encara que l’A sigui correcte. www, idiomes o administració poden apuntar separadament.
Prova A i AAAA amb hostname i SNI reals. Actualitza o retira registres web obsolets, però no eliminis MX o TXT de correu mentre edites el DNS. Conserva l’inventari i el rollback.
Congela o connecta les escriptures
Mentre hi hagi trànsit dividit, deixa el lloc antic en mode de només lectura o manteniment, o utilitza un proxy segur cap al servidor nou quan sigui viable.
No facis una redirecció HTTP per a webhooks de pagament: es poden perdre mètode, cos o signatura. Conserva la base, fitxers i registres antics, i identifica entrades, usuaris, formularis i operacions creats a cada banda.
Evita sobreescriure la base nova amb una còpia antiga.
Reconcilia les dades divergents
Defineix l’hora de tall i compara IDs o referències estables. Fusiona mitjançant exportacions o API conscients de l’aplicació i un procediment assajat.
Els fitxers pujats i els adjunts de la base de dades han de viatjar junts. Els correus o pagaments externs no es reverteixen copiant WordPress.
Registra cada element reconciliat i impedeix escriptures noves durant la fusió final.
Protegeix els callbacks externs
Els proveïdors de pagaments, formularis, SMTP i API poden resoldre DNS independentment i reintentar durant hores. Inventaria els webhooks i comprova quin servidor els rep.
Actualitza directament l’endpoint quan sigui possible. No depenguis de 301 o 302 per a POST signats. Mantén logs i un handler o proxy segur durant tota la finestra de reintents.
Controla l’exposició als cercadors
El servidor antic pot ser indexat mitjançant un hostname de previsualització. Mantén canònics, noindex o controls d’accés coherents sense bloquejar producció.
No demanis retirar el domini real perquè un resolver estigui obsolet. Comprova el rastreig després de convergir i redirigeix només els hostnames retirats.
Revisa CDN i overrides locals
Cloudflare pot tenir el DNS correcte i continuar enviant a l’origen antic. Inspecciona pools, regles d’origen i capçalera Host.
Elimina entrades hosts, VPN, DNS privat i variables antigues després de provar. No purguis tot abans de capturar evidències: les capçaleres ajuden a identificar la capa.
Completa i monitoritza el tall
Mantén el servidor antic en línia però sense escriptures durant el TTL, la memòria cau CDN i els reintents externs. Vigila els seus logs fins que desaparegui el trànsit.
Prova web pública, administració, correu, cron i callbacks al servidor nou. La propagació DNS és previsible; el risc real són les escriptures dobles sense pla.