Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Hosting Dns Containment

A Malicious DNS Record Sends Part of the Traffic Elsewhere

Recover a domain from malicious DNS changes by preserving zone history, securing registrar/DNS access and verifying global resolution.

Some visitors reach the real WordPress server while others see a fake site, certificate warning or unrelated host. DNS records, nameservers or CDN origin settings may have been changed. WordPress file cleanup will not repair traffic that never reaches WordPress.

Treat registrar and DNS-provider access as critical incident scope.

Capture resolution from multiple locations

Record current nameservers and A, AAAA, CNAME records for the affected host from more than one trusted resolver. Include TTL and timestamp.

Compare with the known server/CDN configuration and provider zone history. Different answers can result from propagation, split DNS or multiple legitimate records, not only compromise.

Do not query random online tools with private internal hostnames.

Preserve zone and account history

Export the zone, audit log, user list, API tokens and recent nameserver/record changes. Save registrar contact and transfer-lock status.

Protect this evidence; it reveals infrastructure. Ask providers to retain authentication and change logs.

Do not immediately delete every unfamiliar record—email, verification and service subdomains may be legitimate.

Secure the registrar and DNS provider

From a clean device, protect the owner email, revoke unknown sessions/users/tokens and enable strong multi-factor authentication. Change account credentials and review recovery contacts.

Enable registrar/domain lock where appropriate and verify no unauthorised transfer or nameserver change is pending.

Use provider support through a verified URL/telephone route, not contact details inside suspicious email.

Restore authoritative records

Use a documented known-good zone or hosting/CDN values. Check both IPv4 and IPv6; a malicious AAAA record can divert visitors whose networks prefer IPv6 while IPv4 tests look normal.

Confirm wildcard records and apex/www behaviour. Coordinate mail MX/SPF/DKIM/DMARC records so website recovery does not break email.

Lowering TTL after the malicious answer is cached does not invalidate existing resolver caches.

Validate DNSSEC before and after changes

If the domain uses DNSSEC, compare the registrar DS record with the active DNS provider’s signing configuration. Moving nameservers or regenerating keys without coordinating DS can make the domain fail validation for many visitors.

Do not disable DNSSEC merely to hide an unexplained mismatch. Preserve the prior key/DS history, identify the authorised provider and follow its rollover or removal procedure.

After restoration, query validating resolvers and monitor for SERVFAIL as well as the expected A/AAAA answers. Document who owns future key rotations.

Review CDN and origin configuration

If Cloudflare or another proxy is authoritative, inspect its origin addresses, Workers, redirects and load balancers. A clean DNS answer can still proxy to an attacker-controlled origin.

Verify TLS certificates and issuance logs for unknown certificates where available. Revoke/replace affected origin credentials as needed.

Do not expose the protected origin during recovery.

Inspect WordPress and hosting too

DNS compromise may be independent or part of wider credential theft. Review hosting-panel users, WordPress administrators, files, database, cron and email resets.

If visitors entered credentials/payment data on the false destination, coordinate legal/privacy/payment response rather than assuming traffic diversion was harmless.

Preserve the malicious destination as text; do not interact with it.

Verify propagation and stability

Monitor authoritative and recursive resolver answers across several TTL periods. Test HTTP/TLS through the canonical domain and relevant regions.

Confirm registrar/DNS audit logs show only approved changes and alerts are enabled. Document the final zone and owners.

Schedule a quarterly review.

When urgent DNS recovery is needed

Request immediate provider/specialist help if nameservers changed, account ownership is disputed or visitors reached a credential/payment clone. Send domain and redacted DNS evidence, never registrar passwords.

The repair must restore authoritative control, secure account recovery and verify traffic consistently reaches the trusted service.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident↗