Initial situation: there are 18 domains (10 .com, 6 .ru, 2 .io) from two registrars. DNS is now on the old hosting (BIND), some zones are maintained manually, some through the panel. Mail - Microsoft 365 for 2 domains and Google Workspace for the rest. For 6 domains, client subdomains and NS delegation to external systems are used. There are periodic downtimes due to zone errors and inconsistent TTLs. The goal is to move the authoritative DNS to Cloudflare, enable DNSSEC, bring mail authentication to a single standard, and set up change monitoring. Technical environment and restrictions: access to registrars under customer accounts, access to current BIND DNS exports and M365/GWS panels will be provided. You cannot change the IP addresses of web services and email providers. Mail delivery must not be interrupted; it is critical to preserve all MX, TXT (SPF), DKIM selectors and existing validation records. Work window - weekdays 20:00-01:00 UTC+3. For 4 domains you cannot enable proxying via Cloudflare for A/AAAA, only DNS-only. It is required to take into account the features of .ru in DNSSEC and DS records at the registrar. Tasks by stages: 1) Inventory and audit of current zones - collect actual records from BIND/panel, identify discrepancies, evaluate current TTLs, find outdated records, understand subdomain delegation chains and split-horizon zones (if any). 2) Designing a target DNS scheme in Cloudflare - template settings, naming rules, TTL policy, where proxy is allowed, where strictly DNS-only, preparing a list of zones and owners. 3) Mail part - normalize SPF without exceeding 10 DNS lookup, configure/check DKIM for each domain (for M365 and GWS), generate DMARC with gradual tightening of policy and reports (rua/ruf), take into account subdomains that send mail. 4) Enable DNSSEC - enable in Cloudflare, correctly prepare DS for each registrar, publish DS and check the chain of trust. 5) Migration with zero downtime - pre-reduce TTL, synchronously transfer records, switch NS at registrars, control distribution, fallback plan in case of problems. 6) Monitoring and change control - set up basic monitoring of DNS and mail records (for example, through DNSControl/Git, Cloudflare API and periodic checks), enable notifications about zone changes, prepare short instructions for further maintenance. Specific result: all 18 domains are served by Cloudflare as an authoritative DNS, DNSSEC is enabled and valid, mail is delivered without degradation, SPF/DKIM/DMARC are configured and verified, subdomain delegations are preserved, control of zone changes through the repository and automatic verification are implemented. Measurable acceptance criteria: - For each domain: correct NS at the registrar and a match of the set of critical records (A/AAAA/CNAME/MX/TXT/SRV/CAA) with the initial state, except for pre-agreed cleanings. - DNSSEC: checking through independent validators shows the status OK, the chain of trust is being built (DS is published), there is no SERVFAIL for the main resolvers. - Mail: for each domain, successful verification of SPF, DKIM, DMARC (pass) on test letters, DMARC reports begin to arrive at the specified address, SPF does not exceed the limits. - Delegations: subdomains with external NS continue to resolve in the same way as before migration, without changing the target NS. - DNS/mail unavailability time - 0 minutes according to monitoring data (only TTL changes and NS propagation are allowed without loss of resolution). Artifacts: zone/configuration file(s) (for example, DNSControl/terraform for Cloudflare or export via API), before/after record mapping table, list of DS by domain, brief operating instructions and rollback checklist.