DNS points to the wrong place
A, AAAA, CNAME or nameserver records can still reference an old server or an unintended target.
Hosting & DNS
Hosting, DNS or SSL problems?
A domain can resolve to the wrong server, HTTPS can break after a migration, email can stop delivering or a proxy can hide the real origin of an outage. We trace the problem from DNS records to the web server and the services around it.
Where the problem can sit
Hosting and DNS issues often look similar from the browser, but the fix depends on the layer that is actually failing.
SSL or certificate errors
Certificate issuance, proxy mode, origin configuration or an incomplete HTTPS migration can break access.
CDN or reverse proxy issues
Cloudflare or another proxy can cache errors, hide the origin problem or introduce redirect loops.
Hosting outage or server error
The domain resolves correctly but the origin is unavailable, overloaded or misconfigured.
Email stopped working
MX, SPF, DKIM or DMARC changes can affect delivery even when the website itself works.
Migration not completed cleanly
DNS, SSL, redirects, cron jobs or application configuration may still depend on the previous environment.
How we diagnose it
We start from the public symptom and move inward until the failing layer is identified.
Check DNS resolution
Review nameservers, records, TTLs and the addresses returned from multiple resolvers.
Verify the network and TLS path
Check HTTPS, certificates, redirects, proxy mode and whether the origin responds as expected.
Inspect the hosting layer
Review web server, PHP or application processes, logs, resource pressure and filesystem permissions where relevant.
Check dependent services
Email, cron, external APIs, storage or database connections are verified when they are part of the incident.
Apply the smallest safe change
We correct the failing configuration, then retest DNS, HTTPS and the application from the public side.
What we check
The exact list depends on the provider and architecture, but these are the most common points.
Nameservers and DNS zone
A, AAAA and CNAME records
MX, SPF, DKIM and DMARC
TLS certificate and HTTPS redirects
Cloudflare or reverse proxy configuration
Origin server response
Web server and application logs
Cron jobs and environment variables
Goal
Make the public path predictable again
The goal is a domain that resolves consistently, reaches the intended origin, serves valid HTTPS and keeps dependent services working after the change.
- DNS records aligned with the intended infrastructure
- HTTPS and redirects verified
- Origin response checked independently from the proxy
- Email-related records validated where relevant
- Post-change verification from outside the network
Useful references
Is the site unreachable or pointing to the wrong place?
Send the domain and a short description of what changed. We can start from the public DNS and HTTPS path.