Listă de verificare pentru migrarea unui domeniu: DNS, e-mail, TLS și redirecționări

Ce fel de migrare faceți?

"Migrarea unui domeniu" acoperă mai multe proiecte destul de diferite, iar fiecare dintre ele eșuează în alt mod. Mutarea găzduirii DNS schimbă cine răspunde la interogări; transferul registrarului schimbă cine controlează delegarea; mutarea e-mailului schimbă unde indică înregistrările MX; o redenumire schimbă dintr-odată fiecare URL și fiecare adresă. Stabiliți de la bun început pe care dintre acestea o faceți, pentru că fiecare are pasul ei critic și drumul ei de întoarcere.

Pasul 1: inventarul

Exportați zona completă de la furnizorul DNS actual, dacă se poate chiar ca fișier de zonă. Mulți furnizori ascund în interfață înregistrările adăugate automat, așa că merită să comparați exportul cu interogări live. Acordați o atenție specială înregistrărilor pe care nimeni nu își amintește să le fi adăugat: de cele mai multe ori sunt verificări de proprietate pentru servicii care se strică în tăcere atunci când înregistrarea dispare.

for name in example.com www.example.com _dmarc.example.com _mta-sts.example.com; do
  for type in A AAAA CNAME MX TXT CAA; do
    dig +noall +answer "$name" "$type"
  done
done

Rulați Sănătatea domeniului înainte de a începe și salvați rezultatul. După migrare, aceeași verificare devine un test rapid de regresie pentru SPF, DMARC, MX, TLS, antete și redirecționări. Puse una lângă alta, cele două rezultate arată dintr-o privire ce înregistrare a rămas în urmă sau ce setare s-a pierdut pe drum.

Pasul 2: reduceți valorile TTL

Resolverele păstrează înregistrările în cache pe toată durata TTL-ului lor. Dacă o înregistrare are un TTL de o zi și o schimbați, unii utilizatori rămân cu valoarea veche până la o zi întreagă. Reducerea valorilor TTL la aproximativ 300 de secunde, cu cel puțin un TTL vechi înainte de schimbare, face ca trecerea să ajungă la toată lumea în câteva minute, iar același lucru rămâne valabil și pentru o eventuală revenire.

Schimbarea serverelor de nume este cu totul altceva: înregistrările NS ale domeniului dumneavoastră din zona TLD au propriul TTL, stabilit de registru, de obicei de una sau două zile, iar pe acela nu îl puteți reduce. Planificați așadar ca în tot acest interval să primească interogări atât serverele de nume vechi, cât și cele noi. Exact de aceea furnizorul DNS vechi trebuie să continue să servească zona până când intervalul trece complet.

Pasul 3: mutarea găzduirii DNS

1. Creați zona la noul furnizor și importați, una câte una, toate înregistrările din inventar.
2. Comparați direct răspunsurile serverelor de nume vechi și noi pentru fiecare nume și fiecare tip din inventar.
3. Planificați din timp DNSSEC: dacă zona este semnată, urmați abordarea din ghidul DNSSEC înainte de a schimba serverele de nume.
4. Abia după aceste verificări schimbați serverele de nume la registrar.
5. Urmăriți în primele ore jurnalele de interogări de la noul furnizor și ratele de eroare ale serviciilor dumneavoastră.
6. Păstrați zona veche neschimbată și servită cel puțin pe durata TTL-ului NS plus o marjă de siguranță, și abia apoi ștergeți-o.

dig @ns1.old-dns.example.net example.com MX +short
dig @ns1.new-dns.example.net example.com MX +short

dig @ns1.old-dns.example.net selector1._domainkey.example.com TXT +short
dig @ns1.new-dns.example.net selector1._domainkey.example.com TXT +short

Verificați apoi delegarea din două locuri diferite: serverele de nume pe care le are registrul, cu Căutare WHOIS, și ceea ce văd efectiv resolverele, cu Căutare DNS.

Pasul 4: transferul registrarului

Un transfer de registrar nu trebuie să atingă deloc DNS-ul și, în mod ideal, nici nu îl atinge. Păstrați serverele de nume îndreptate spre furnizorul dumneavoastră DNS pe tot parcursul, astfel încât transferul să rămână complet invizibil pentru utilizatori. Nu începeți un transfer aproape de data expirării și verificați că adresa de e-mail de contact a deținătorului funcționează, pentru că acolo ajung mesajele de confirmare a transferului.

• Deblocați domeniul la registrarul actual, adică scoateți blocarea de transfer.
• Obțineți codul de autorizare (auth code, cod EPP) și păstrați-l într-un loc sigur.
• Confirmați serverele de nume și eventualele înregistrări DS și notați-le valorile.
• Începeți transferul la noul registrar și aprobați toate mesajele de confirmare primite.
• După finalizare, verificați serverele de nume, înregistrările DS, contactele și reînnoirea automată; reactivați blocarea de transfer și, dacă o folosiți, blocarea la registru.
• Așteptați-vă la o restricție de 60 de zile pentru transferuri ulterioare după un transfer finalizat, așa cum permite politica de transfer ICANN pentru domeniile generice.

Pasul 5: mutarea e-mailului

E-mailul tolerează întreruperile scurte, pentru că serverele expeditoare reîncearcă livrarea, adesea zile întregi. Nu tolerează însă greșelile de autentificare, care duc la respingere imediată sub o politică DMARC de aplicare. Configurați complet autentificarea pentru noul furnizor înainte ca vreun mesaj să treacă prin el.

1. Verificați domeniul la noul furnizor de e-mail și publicați înregistrările lui DKIM alături de cele vechi, fără să le ștergeți pe acestea.
2. Adăugați noul furnizor în SPF păstrându-l pe cel vechi și verificați numărul de căutări cu Securitatea e-mailului.
3. Dacă folosiți MTA-STS, adăugați noile gazde MX în fișierul de politică și schimbați identificatorul politicii cu cel puțin un max_age înainte de a comuta MX.
4. Migrați cutiile poștale și abia apoi schimbați înregistrările MX.
5. Urmăriți rapoartele agregate DMARC și furnizorul vechi, pentru e-mailul care încă ajunge acolo.
6. După câteva săptămâni, scoateți furnizorul vechi din SPF, revocați-i cheile DKIM și actualizați politica MTA-STS.

Verificați noile înregistrări MX cu MX și SMTP după schimbare. Păstrați raportarea rua activă pe tot parcursul; un sistem de trimitere care încă folosește releul furnizorului vechi apare acolo de la sine.

Pasul 6: certificatele TLS

Asigurați-vă că noua gazdă are un certificat valid înainte ca traficul să se mute. Dacă noua platformă emite certificate cu validare HTTP, s-ar putea să poată face asta abia după ce DNS-ul indică spre ea, ceea ce deschide o scurtă fereastră cu erori de certificat. Validarea prin DNS sau încărcarea unui certificat pe care îl aveți deja elimină complet acea fereastră. Cu HSTS activat, o eroare de certificat nu mai este o simplă neplăcere, ci o întrerupere totală pentru vizitatorii care au mai fost pe site.

• Verificați dacă înregistrările CAA permit autoritatea de certificare folosită de noua platformă.
• Acoperiți toate numele de gazdă, inclusiv www și orice subdomeniu care se mută.
• Testați noua gazdă înainte de comutare, conectându-vă direct la adresa ei IP cu numele de gazdă corect.
• După comutare, confirmați rezultatul cu Verificator TLS și configurați o monitorizare a expirării certificatului.

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' --resolve example.com:443:192.0.2.80 https://example.com/

Pasul 7: redenumirea unui domeniu

O redenumire este cea mai mare migrare, pentru că fiecare legătură, fiecare semn de carte, fiecare rezultat de căutare și fiecare adresă de e-mail indică în continuare spre numele vechi. Scopul este ca nimic să nu se rupă vreodată: URL-urile vechi redirecționează permanent către echivalentul lor nou, adresele vechi primesc în continuare e-mail pe durata unei perioade de tranziție, iar domeniul vechi rămâne înregistrat. Redirecționați fiecare pagină către pagina nouă care îi corespunde, nu totul către pagina principală.

server {
    listen 443 ssl;
    server_name example.org www.example.org;
    return 301 https://example.com$request_uri;
}

• Construiți o hartă a URL-urilor pentru paginile a căror cale se schimbă și testați-o bucată cu bucată cu Verificator de redirecționări.
• Folosiți redirecționări 301 și păstrați-le ani la rând, nu doar câteva luni.
• Anunțați motoarele de căutare prin instrumentele lor, de exemplu prin funcția de schimbare a adresei din Google Search Console.
• Actualizați URI-urile de redirecționare OAuth, setările SSO, webhook-urile, clienții API și legăturile scrise direct în aplicații.
• Continuați să redirecționați e-mailul de la adresele vechi pe durata unei perioade de tranziție și anunțați contactele despre adresele noi.
• Păstrați domeniul vechi reînnoit; un domeniu vechi expirat poate fi înregistrat de altcineva, care vă primește apoi traficul și e-mailul.

Planificați revenirea înainte de a începe

Fiecare pas al comutării ar trebui să aibă un drum de întoarcere scris și o persoană anume care decide când se folosește. Cu TTL-uri mici, revenirea la o înregistrare veche durează câteva minute; revenirea la serverele de nume vechi durează cât TTL-ul NS, exact motivul pentru care furnizorul DNS vechi trebuie lăsat neatins. Scrieți planul de revenire înainte de fereastra de schimbare, nu în mijlocul unui incident.

Stabiliți de comun acord, înainte de deschiderea ferestrei, semnalele care declanșează o revenire, de exemplu e-mail care se întoarce de mai bine de cincisprezece minute sau site-ul principal care dă erori într-o regiune. Criteriile clare împiedică atât revenirile de panică asupra unei schimbări sănătoase, cât și orele pierdute cu depanarea unei configurații stricate în timp ce utilizatorii sunt afectați.

Redirecționările permanente sunt singura schimbare cu adevărat greu de anulat, pentru că browserele păstrează răspunsurile 301 în cache multă vreme. Dacă nu sunteți sigur de o corespondență între URL-uri, testați-o o perioadă scurtă cu 302 și treceți la 301 după ce a fost confirmată.

După migrare

Dezafectați zona DNS veche, contul de e-mail vechi sau găzduirea veche abia după ce toate aceste verificări trec. Serviciile anulate care încă au înregistrări DNS îndreptate spre ele sunt și configurația clasică pentru preluarea de subdomenii, așa că ștergeți acele înregistrări ca parte din curățenia finală.

Întrebări frecvente

Surse

• RFC 1034: Nume de domenii, concepte și facilități (cache și TTL)
• RFC 8659: Autorizarea autorității de certificare în DNS (CAA)
• ICANN: Politica de transfer
• Google Search Central: Mutarea unui site cu schimbări de URL
• RFC 8461: MTA-STS