Situație inițială: există 18 domenii (10 .com, 6 .ru, 2 .io) de la doi registratori. DNS este acum pe vechea găzduire (BIND), unele zone sunt întreținute manual, altele prin panou. Mail - Microsoft 365 pentru 2 domenii și Google Workspace pentru restul. Pentru 6 domenii sunt utilizate subdomeniile client și delegarea NS către sisteme externe. Există întreruperi ocazionale din cauza erorilor de zonă și a TTL-urilor inconsecvente. Scopul este de a muta DNS-ul autoritar în Cloudflare, de a activa DNSSEC, de a aduce autentificarea e-mailului la un singur standard și de a configura monitorizarea modificărilor. Mediu tehnic și restricții: va fi oferit acces la registratorii în conturile clienților, accesul la exporturile actuale BIND DNS și panourile M365/GWS. Nu puteți modifica adresele IP ale serviciilor web și ale furnizorilor de e-mail. Livrarea corespondenței nu trebuie întreruptă; este esențial să păstrați toate selectoarele MX, TXT (SPF), DKIM și înregistrările de validare existente. Fereastra de lucru - în zilele lucrătoare 20:00-01:00 UTC+3. Pentru 4 domenii nu puteți activa proxy prin Cloudflare pentru A/AAAA, doar numai DNS. Este necesar să se țină cont de caracteristicile .ru în înregistrările DNSSEC și DS la registrator. Sarcini pe etape: 1) Inventarierea și auditul zonelor curente - colectați înregistrările reale de la BIND/panou, identificați discrepanțe, evaluați TTL-urile actuale, găsiți înregistrări învechite, înțelegeți lanțurile de delegare a subdomeniilor și zonele cu orizont divizat (dacă există). 2) Proiectarea unei scheme DNS țintă în Cloudflare - setări șablon, reguli de denumire, politică TTL, unde proxy-ul este permis, unde strict DNS-only, pregătirea unei liste de zone și proprietari. 3) Partea de e-mail - normalizați SPF fără a depăși 10 căutări DNS, configurați/verificați DKIM pentru fiecare domeniu (pentru M365 și GWS), generați DMARC cu înăsprirea treptată a politicii și rapoartelor (rua/ruf), luați în considerare subdomeniile care trimit mail. 4) Activați DNSSEC - activați în Cloudflare, pregătiți corect DS pentru fiecare registrator, publicați DS și verificați lanțul de încredere. 5) Migrare cu zero downtime - pre-reduceți TTL, transferați în mod sincron înregistrările, comutați NS la registratori, controlați distribuția, plan de rezervă în caz de probleme. 6) Monitorizare și control al schimbărilor - configurați monitorizarea de bază a înregistrărilor DNS și e-mail (de exemplu, prin DNSControl/Git, API Cloudflare și verificări periodice), activați notificări despre modificările zonei, pregătiți instrucțiuni scurte pentru întreținere ulterioară. Rezultat specific: toate cele 18 domenii sunt servite de Cloudflare ca DNS autoritar, DNSSEC este activat și valid, corespondența este livrată fără degradare, SPF/DKIM/DMARC sunt configurate și verificate, delegațiile subdomeniilor sunt păstrate, controlul modificărilor zonei prin depozit și verificarea automată sunt implementate. Criterii de acceptare măsurabile: - Pentru fiecare domeniu: NS corect la registrator și o potrivire a setului de înregistrări critice (A/AAAA/CNAME/MX/TXT/SRV/CAA) cu starea inițială, cu excepția curățărilor pre-acordate. - DNSSEC: verificarea prin validatori independenți arată starea OK, lanțul de încredere este în curs de construire (DS este publicat), nu există SERVFAIL pentru solutorii principali. - Mail: pentru fiecare domeniu, verificarea cu succes a SPF, DKIM, DMARC (trece) scrisorile de testare, rapoartele DMARC încep să sosească la adresa specificată, SPF nu depășește limitele. - Delegații: subdomeniile cu NS extern continuă să se rezolve în același mod ca înainte de migrare, fără a schimba NS țintă. - Timp de indisponibilitate DNS/mail - 0 minute conform datelor de monitorizare (doar modificările TTL și propagarea NS sunt permise fără pierderea rezoluției). Artefacte: fișiere de zonă/configurare (de exemplu, DNSControl/terraform pentru Cloudflare sau export prin API), tabel de cartografiere înainte/după înregistrare, listă de DS după domeniu, instrucțiuni scurte de operare și listă de verificare pentru rollback.