Phase 4: Post-migration and DNSSEC Re-activation

After the cutover, verify and stabilize.

1. Thorough testing and validation

1. Test all services that rely on DNS: websites, email (sending and receiving), VPNs, APIs, etc.
2. Test from different networks and geographical locations if possible.
3. Monitor application logs for any DNS-related errors.

2. Enable DNSSEC in Cloudflare (if disabled earlier)

Enable DNSSEC only after you are confident that DNS is resolving correctly through Cloudflare and that nameserver changes have fully propagated. In practice, plan for at least one full DS TTL after you add new DS records at the registrar.

Action in Cloudflare:

1. In the Cloudflare dashboard, go to your zone's DNS Settings.

   Go to Settings

2. Select Enable DNSSEC. Cloudflare will sign your zone and generate DNSKEY and DS record details.

Action at registrar:

1. Log in to your domain registrar.
2. Navigate to the DNSSEC management section for your domain.
3. Add the DS record details provided by Cloudflare.

After adding the DS record, allow time for propagation and then validate your configuration with tools such as DNSViz ↗ or Verisign's DNSSEC debugger ↗. For more information, refer to DNSSEC.

Note

If your domain uses Cloudflare Registrar, some DNSSEC steps can be simplified or automated. Refer to Enable DNSSEC with Cloudflare Registrar for registrar-specific instructions.

3. Adjust TTLs in Cloudflare

After the migration is stable and DNSSEC is active (if used), increase the TTLs for your DNS records from the short values used during the migration to more standard values (for example, 3600 seconds for frequently changing records or 86400 seconds for very stable records).

Higher TTLs improve resolver cache efficiency and can reduce latency by allowing recursive resolvers to reuse cached answers for longer, at the cost of slower propagation when you make changes.

4. Review and enable Cloudflare proxy features

If you initially set records to DNS Only (grey cloud), now is a good time to enable Cloudflare's proxy (orange cloud) for HTTP/S records (A, AAAA, CNAME) to leverage CDN, WAF, and other security and performance features. Test thoroughly after enabling proxying.

5. Decommission On-Prem BIND servers

Only after a significant stabilization period (for example, several days to a week after full propagation and successful testing) and when you are fully confident in the Cloudflare setup, decommission the on-premise BIND servers.

Ensure no resolvers are still pointing to the old BIND servers. This is especially important for internal resolvers, if they were not addressed separately.

6. Update internal documentation and monitoring

Update all internal IT documentation to reflect the new DNS infrastructure and ensure your monitoring systems are checking DNS resolution via Cloudflare.