14 Common DNS Problems and How to Troubleshoot Them

DNS troubleshooting works best when you ask a precise question: which hostname, which record type, which resolver and which expected answer? “The site is down” could describe a DNS failure, certificate error, overloaded application or local network problem.

Before editing, save the current records and note the last authorised change. Use read-only queries first. Examples below use example.co.uk as an illustration; replace it with a name you are authorised to administer.

Start with a small evidence set

Record the exact browser or mail error, the affected network and the time. Check the domain's registration status and delegated nameservers. Compare the authoritative answer with a recursive resolver before blaming caches or waiting a fixed number of hours.

Commands such as dig example.co.uk A, dig example.co.uk MX and dig example.co.uk NS inspect different record types. On systems without dig, nslookup or a reputable browser-based lookup service can help. Do not share account passwords with a diagnostic website.

Distinguish NXDOMAIN, which reports that a queried name does not exist, from a successful response containing no record of the requested type. SERVFAIL indicates a processing or validation failure rather than proving the name is unregistered. These distinctions narrow the investigation. Save the full response, including status and authority information, before reducing it to a screenshot of a single address.

1. Different answers after a recent change

An authoritative server can publish a new value while a recursive resolver still caches the old one. Check both answers and their TTLs. Confirm the change was made in the active zone, then keep the old destination operating during the intended overlap.

Lowering TTL now does not erase an older cached answer. Avoid repeated edits that make it unclear which state each test is observing.

2. Incorrect A or AAAA address

Compare the published addresses with the values supplied for your hosting account. Check both IPv4 and IPv6: an old AAAA record can send some users to a retired server while IPv4 works.

A 404 or 502 response proves a web service answered; it is not automatically a DNS error. Test the hostname on the intended server and check its virtual-host configuration before changing correct records.

3. Missing or incorrect MX

If incoming mail fails, query MX for the receiving domain and compare priorities and hostnames with the email provider's current instructions. Confirm the domain is activated and the destination mailbox exists.

Do not mix old and new mail providers as an improvised backup arrangement. Prepare the new service before moving delivery, retain old access during the transition and inspect actual bounce codes.

4. Local cache or browser state

If only one device sees an old result, compare another device and network. Check DNS separately from browser content caching and any service worker. An incognito window does not guarantee every DNS cache has been bypassed.

Clear local caches only after recording the evidence. Clearing them cannot repair an incorrect authoritative record or force every customer's resolver to update.

5. An unsuitable TTL plan

A long TTL can complicate a rushed move; an extremely short TTL increases fresh-query demand and reliance on the authoritative service. Neither value is universally correct for every record.

For a planned migration, lower the relevant TTL in advance and let the old TTL pass. After a stable transition, choose a sustainable setting appropriate to the service rather than leaving emergency values indefinitely.

6. Broken nameserver delegation

Check the nameservers registered at the parent through the registrar and compare them with the active DNS provider's required set. Query each authoritative server directly where practical.

Changing an NS entry inside an inactive zone does not necessarily update the parent delegation. Build the complete replacement zone first, and avoid mixing unrelated old and new nameservers without a supported synchronisation design.

7. DNSSEC validation failure

A mismatched DS, missing key or expired signature can cause validating resolvers to return SERVFAIL even while the web server is healthy. Compare the parent's DS with the authoritative provider's current signing configuration.

Use a DNSSEC-aware diagnostic and involve both registrar and DNS provider. Do not treat bypassing validation as the repair or repeatedly disable signing without a documented transition plan.

8. A subdomain fails while the main site works

Check the exact hostname for A, AAAA or CNAME records and confirm whether it belongs to a delegated child zone. An entry in the wrong zone may never be used.

Then test the receiving platform's custom-domain configuration and certificate. DNS resolving correctly does not guarantee the application has been instructed to serve that subdomain.

9. Conflicting records or an alias loop

An ordinary CNAME cannot coexist with other ordinary record data at the same owner name. Inspect the specific types rather than relying on an ANY query, which is not a dependable complete zone inventory.

Follow alias chains to their final destination and check for a loop. Remove only the obsolete records identified by the change plan, keeping unrelated mail and verification entries intact.

10. A local network or filtering difference

If the domain works on mobile data but not office Wi-Fi, compare resolver answers and network policy. A security filter, captive portal, routing issue or local resolver fault can resemble a public DNS problem.

Do not instruct staff to evade organisational security controls. Gather the hostname and result, then ask the network administrator or provider to review the difference.

11. Lookup timeouts

A timeout means the query did not receive a timely answer; it differs from an authoritative statement that the name does not exist. Test the resolver and the authoritative service separately.

Record whether the issue affects IPv4, IPv6, UDP, TCP or only certain networks. Larger DNSSEC answers and broken fallback paths can reveal problems a simple small query does not expose.

12. Expired or suspended registration

Check the registrar account and relevant registry status. Renewal failures, contact-validation issues and other restrictions may affect a domain even if its DNS zone remains visible in your dashboard.

Use the current rules for the suffix. .uk lifecycle and transfer rules differ from many gTLDs, and announced 2027 changes must not be mistaken for current October 2026 procedures. Contact the registrar promptly.

13. Authentication failures and spam placement

If mail is delivered but marked suspicious, inspect SPF, DKIM and DMARC outcomes in real headers. A public TXT record existing does not prove messages are signed or aligned correctly.

Inventory all senders, avoid duplicate SPF policies and enable provider-specific DKIM. Authentication is only part of delivery: reputation, message practices and recipient preferences also matter. Do not repeatedly change MX to fix outgoing authentication.

14. Migration left services pointing at the old host

Compare the whole zone with your migration inventory, including mail, IPv6, subdomains, verification entries and delegated zones. Moving the website does not mean every record should point to the new web server.

Keep old services available during the overlap, test business journeys and complete final data synchronisation. Remove retired values only after confirming what they served and which replacement is working.

Escalate with useful evidence

Send support the affected hostname, query type, expected value, actual answer, resolver, time and relevant error. Include recent changes and which tests succeed. Remove personal information from message headers and screenshots where possible.

For a service on telaHosting, use the genuine account support route to confirm account-specific destinations. A measured diagnosis and one reversible correction are more effective than changing nameservers, mail records and application settings simultaneously.