What to do if…
your website’s DNS records change unexpectedly and traffic starts going somewhere else

What to do now

1. Switch to a safer admin posture (minutes).

   • Use a known-clean device if possible.
   • Pause any tools that automatically push DNS changes (CI/CD DNS updates, infrastructure-as-code runs, API automations) so they don’t conflict with recovery.

2. Lock down the registrar account (your main control point).

   • Log in to your domain registrar and immediately:
     • Change the password to a strong unique one.
     • Enable MFA/2FA.
     • Turn on Domain Lock / Registrar Lock (to block transfers and reduce unauthorized changes).
     • If your registrar offers it (and your domain supports it), ask about Registry Lock as an added safeguard.
   • Remove unknown users, delegated access, recovery emails/phones, and revoke any API keys/tokens you don’t recognize.

3. Record what happened (you’ll need this for escalation).

   • Screenshot/export:
     • Current nameservers (NS) at the registrar.
     • DNS provider/CDN audit logs (record changes, API activity).
     • Any registrant/contact changes you can see.
   • Write a brief timeline (local time): when you noticed, what users see, and what you changed (if anything).

4. Restore delegation first, then restore records.

   • If nameservers changed, set them back to your correct DNS provider/CDN values using a known-good reference (internal documentation, prior ticket, provider onboarding details).
   • If nameservers are correct but records were modified, restore from your last known-good DNS export/template.
   • If you don’t have a known-good copy, restore only the minimum needed to bring the website back safely (A/AAAA/CNAME for the web service), then add other records carefully.

5. Check DNSSEC status so recovery doesn’t fail silently.

   • In the registrar panel, check whether DNSSEC is enabled and whether the DS record was changed or removed.
   • If DNSSEC was altered, coordinate fixes with your DNS provider/registrar (a mismatched DS can break valid resolution or keep pointing to attacker-controlled signing).

6. Escalate to the registrar’s security/abuse channel.

   • Use official registrar support and say: “Unauthorized DNS/name server changes; suspected domain hijack.”
   • Ask them to:
     • Apply the strongest available lock/hold for your domain.
     • Confirm whether changes came from login, API token, or support-assisted action.
     • Preserve and provide the change history/audit logs.
   • If you suspect an unauthorized transfer, ask for the registrar’s unauthorized transfer dispute steps immediately.

7. Contain common entry points in parallel.

   • Secure the email accounts used for registrar/DNS recovery:
     • Change password, enable MFA, remove unknown forwarding rules, check connected apps/app passwords.
   • Secure DNS provider/CDN access (MFA, revoke tokens, review access).
   • If you suspect an admin workstation compromise, stop using it for admin logins until it’s cleaned.

8. Reduce harm to customers while recovery is in progress.

   • Pause ads/email campaigns driving users to the domain until you verify resolution is correct.
   • Tell staff not to log into admin panels via the domain until you confirm it resolves correctly (use known-good direct URLs only).
   • If you control the correct hosting, temporarily serve a maintenance page and disable risky features until stable.

9. Report if appropriate (crime, loss, or broader risk).

   • For cybercrime/fraud (especially if money or customer harm is involved), file a report with the FBI Internet Crime Complaint Center (IC3).
   • You can also report/share incident details with CISA via its cyber incident reporting channels.