Question 1

Site shows "This site can't be reached" or times out

Accepted Answer

Root cause: A record missing, pointing to wrong IP, or server is down. Look up the A record for your domain — confirm it returns an IP address Ping that IP address to check if the server is responding If the A record is missing, add it in your DNS provider pointing to your server IP If the IP is wrong, update the A record to the correct server IP Wait for TTL to expire (check SOA record for the TTL value), then verify propagation

Question 2

www.example.com works but example.com doesn't (or vice versa)

Accepted Answer

Root cause: Missing A record or CNAME for one of the variants. Look up both example.com and www.example.com A records The non-www apex domain needs an A record pointing to your server IP www can use a CNAME pointing to the apex domain, or its own A record Ensure your web server is configured to respond to both hostnames Set up a redirect (301) from the unwanted variant to the canonical one

Question 3

CNAME on root domain causes errors or breaks MX records

Accepted Answer

Root cause: CNAME at the apex (root) domain is not allowed by the DNS spec (RFC 1912). Never set a CNAME on the bare apex domain (e.g. example.com) — it conflicts with MX, NS, and SOA records Use an A record on the apex pointing to your host's IP instead If your host only provides a hostname (not an IP), use ALIAS or ANAME records if your DNS provider supports them Place the CNAME on www.example.com pointing to your host's provided hostname

Question 4

Emails sent to your domain bounce or never arrive

Accepted Answer

Root cause: Missing or misconfigured MX records. Check MX records for your domain — there should be at least one Verify MX values match what your email provider specifies (e.g. Google Workspace, Microsoft 365) MX records must point to a hostname, never directly to an IP address Check MX priority values — lower number = higher priority (e.g. 1 is preferred over 10) Confirm the MX hostname itself has a valid A record resolving to your mail server

Question 5

Outgoing emails land in spam or get rejected

Accepted Answer

Root cause: Missing SPF, DKIM, or DMARC TXT records. Look up TXT records — check for a record starting with "v=spf1" If SPF is missing, add a TXT record like: v=spf1 include:_spf.yourmailprovider.com ~all Check for a DKIM TXT record at selector._domainkey.yourdomain.com (selector provided by your mail host) Look up _dmarc.yourdomain.com for a TXT record starting with "v=DMARC1" If DMARC is missing, add: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to start monitoring Use an email deliverability tester (mail-tester.com) to confirm all three are valid

Question 6

MX records not working after adding a CNAME

Accepted Answer

Root cause: A CNAME on the domain root conflicts with MX records. Check if there is a CNAME on the apex domain (example.com) A CNAME at the root overrides all other records including MX — remove it Replace the apex CNAME with an A record pointing to your server IP Re-add your MX records after removing the conflicting CNAME Verify MX records are visible again after TTL expires

Question 7

DNS changes made hours ago still not visible everywhere

Accepted Answer

Root cause: Old TTL values causing resolvers to cache the previous record. Check the TTL on the record you changed — if it was 86400 (24h), resolvers may cache it that long Before making changes, lower TTL to 300 (5 minutes) and wait for the old TTL to expire first Check propagation across global resolvers to see which regions have the new value Flush your local DNS cache: on macOS run "sudo dscacheutil -flushcache", on Windows run "ipconfig /flushdns" After propagation is complete, raise TTL back to 3600 or higher to reduce DNS query load

Question 8

Site loads for some users but not others

Accepted Answer

Root cause: Partial propagation — some resolvers have the new record, others still have the old one. Run a global propagation check to see which resolvers have the new vs old value This is normal during propagation — it typically resolves within 24–48 hours Keep both old and new servers running until propagation is 100% complete Check DNS history to confirm the change was actually saved at your registrar If the old IP is still showing everywhere, verify the change was saved correctly at your DNS provider

Question 9

Nameserver change not propagating after 48 hours

Accepted Answer

Root cause: NS delegation changes are controlled by the parent zone (TLD registry) and can take longer. Check NS records — confirm the new nameservers are showing at the TLD level (use a root resolver) NS changes go through your domain registrar to the TLD registry — confirm the change was submitted at the registrar, not just the DNS provider Contact your registrar if NS records haven't updated after 48 hours Ensure the new nameservers are fully configured with your zone before the NS change propagates

Question 10

SSL certificate can't be issued or auto-renews fail

Accepted Answer

Root cause: CAA records blocking the certificate authority, or A record not yet propagated. Check CAA records for your domain — if present, they restrict which CAs can issue certs If using Let's Encrypt, ensure "letsencrypt.org" is listed in CAA, or that no CAA records exist (open to all CAs) Example CAA record: 0 issue "letsencrypt.org" Verify the A record is pointing to the correct server where the certificate will be issued For wildcard certs (*.example.com), ensure CAA includes issuewild permission: 0 issuewild "letsencrypt.org"

Question 11

"Certificate name mismatch" browser warning

Accepted Answer

Root cause: The domain in the cert doesn't match the domain being accessed. Check what domain the SSL cert is issued for If using a CNAME to a CDN or hosting provider, the cert must cover your domain (not just the provider's) Enable custom domain SSL at your CDN/hosting provider (Cloudflare, Netlify, Vercel, etc.) For subdomains, ensure the cert is either a wildcard (*.example.com) or explicitly includes the subdomain

Question 12

Subdomain (e.g. app.example.com) returns NXDOMAIN or doesn't load

Accepted Answer

Root cause: Missing A or CNAME record for the subdomain. Look up the subdomain directly to confirm no record exists Add an A record for the subdomain pointing to the server IP, or a CNAME pointing to a hostname Wildcard records (*.example.com) can cover all subdomains — check if one exists Ensure your web server is configured to respond to the subdomain (virtual host / server block)

Question 13

VoIP, game server, or messaging service can't connect

Accepted Answer

Root cause: Missing or malformed SRV record. Look up SRV records for the service prefix (e.g. _sip._tcp.example.com) SRV record format: [priority] [weight] [port] [target hostname] Example for SIP: _sip._tcp.example.com → 10 20 5060 sip.example.com The target hostname in the SRV record must itself have a valid A record Check the service documentation for the exact SRV record name and values required

Question 14

Visitors see a 404 "Not Found" error on pages that should exist

Accepted Answer

Root cause: DNS is resolving correctly but the web server cannot find the requested resource. Confirm DNS is resolving correctly — the A record should point to your server Check if the page URL has changed — a recent deployment or CMS update may have altered the path Verify the file or route exists on the server (check your hosting file manager or deployment logs) If using a CMS (WordPress, etc.), check that permalink settings are saved and .htaccess is present For SPAs (React, Vue), ensure your server is configured to serve index.html for all routes (catch-all rule) Set up 301 redirects from old URLs to new ones to preserve SEO and fix broken links

Question 15

Site shows a 500 "Internal Server Error" or blank white page

Accepted Answer

Root cause: Server-side code crash, misconfiguration, or resource exhaustion. Check your server error logs immediately — the 500 message is generic but logs contain the real cause If using shared hosting, check for PHP errors, memory limit exceeded, or a corrupted .htaccess file Temporarily rename .htaccess to .htaccess.bak to rule it out as the cause Check if a recent code deployment or plugin update triggered the error — roll back if needed Verify file permissions: web files should be 644, directories 755 Confirm DNS still resolves to the correct server IP — a stale A record after a migration can cause this

Question 16

Site shows 502 "Bad Gateway" or 503 "Service Unavailable"

Accepted Answer

Root cause: The web server (nginx/Apache) cannot reach the upstream application server, or the server is overloaded. Check if the upstream service (Node.js, PHP-FPM, Gunicorn, etc.) is running on the server Verify the proxy configuration points to the correct port (e.g. nginx proxy_pass to localhost:3000) Check server resource usage — high CPU or memory can cause 503s under load Review nginx or Apache error logs for "connect() failed" or "upstream timed out" messages If behind a CDN or load balancer, confirm the origin server IP in the CDN config matches your current A record Restart the application service and monitor — if it recurs, investigate memory leaks or traffic spikes

Question 17

Browser shows "Too many redirects" or ERR_TOO_MANY_REDIRECTS

Accepted Answer

Root cause: Conflicting redirect rules between DNS, CDN, and web server creating an infinite loop. Clear your browser cookies and cache for the domain — a cached redirect can cause this locally Check if both your CDN (e.g. Cloudflare) and your web server are both forcing HTTPS redirects — disable one If using Cloudflare, set SSL mode to "Full (Strict)" — "Flexible" causes redirect loops when the server also redirects HTTP→HTTPS Check .htaccess or nginx config for conflicting redirect rules (e.g. www↔non-www and HTTP→HTTPS at the same time) Verify CNAME chain — a CNAME pointing to another CNAME pointing back creates loops Test with curl to see the exact redirect chain: curl -I -L https://yourdomain.com

Question 18

Site loads but shows "Not Secure" warning or broken images/scripts after moving to HTTPS

Accepted Answer

Root cause: Page contains HTTP resources (images, scripts, stylesheets) on an HTTPS page. Open browser DevTools → Console — look for "Mixed Content" warnings listing the HTTP URLs Update all hardcoded http:// URLs in your content, templates, and database to https:// For WordPress: use a plugin like "Better Search Replace" to update http:// to https:// in the database Add a Content-Security-Policy header with upgrade-insecure-requests to auto-upgrade HTTP resources Verify your SSL certificate covers all subdomains serving assets (CDN, media, API) Check DNS for any subdomains still pointing to HTTP-only servers

Question 19

DNS resolves correctly but the website still will not load

Accepted Answer

Root cause: Server is reachable via DNS but the web service itself is down or blocked. Confirm DNS is resolving to the expected IP Try accessing the site by IP directly (http://YOUR.SERVER.IP) — if it loads, DNS is fine and the issue is the server config Check if a firewall or security group is blocking port 80 or 443 on the server Verify the web server process (nginx, Apache, Caddy) is running: run "systemctl status nginx" or equivalent Check if the SSL certificate has expired — an expired cert causes browsers to block the page entirely Review server uptime and recent deployment logs for any changes that coincide with the outage

Question 20

Domain resolves on some resolvers but returns SERVFAIL on others

Accepted Answer

Root cause: DNSSEC signatures are invalid, expired, or the DS record at the registrar does not match the zone signing key. Check DNSSEC status using a validator like dnsviz.net or Verisign DNSSEC debugger — look for "Bogus" status Look up the DS record at your registrar and the DNSKEY record in your zone — the key tag and algorithm must match If you recently changed DNS providers, the old DS record at the registrar may still be pointing to the old key — update or remove it Check RRSIG expiry dates — if signatures have expired, your DNS provider needs to re-sign the zone If DNSSEC is not actively managed, consider disabling it: remove the DS record at the registrar first, then disable DNSSEC at the DNS provider (never the reverse) After fixing, verify propagation — DNSSEC-validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) must return NOERROR

Question 21

Site goes down after migrating DNS providers with DNSSEC enabled

Accepted Answer

Root cause: DS record at registrar still references the old provider's key after nameserver change. Before migrating, disable DNSSEC at the registrar by removing the DS record — wait for the DS TTL to expire (usually 24–48h) Then change nameservers to the new provider and wait for NS propagation Enable DNSSEC at the new DNS provider and get the new DS record values Add the new DS record at the registrar only after the new nameservers are fully propagated Verify the new DNSSEC chain is valid before considering the migration complete

Question 22

DNSSEC validation fails with "unsupported algorithm" errors

Accepted Answer

Root cause: Zone is signed with an outdated algorithm (e.g. RSA/SHA-1) that modern resolvers reject. Check the algorithm number in your DNSKEY record — algorithm 5 (RSA/SHA-1) and 7 are deprecated Migrate to algorithm 13 (ECDSA P-256/SHA-256) or 8 (RSA/SHA-256) — both are widely supported Perform a key rollover: add the new key alongside the old one, update the DS record, then remove the old key after propagation Most modern DNS providers handle algorithm selection automatically — check your provider's DNSSEC settings panel

Question 23

DNS changes take too long to take effect globally

Accepted Answer

Root cause: TTL values are set too high, causing resolvers to cache records for hours or days. Check the current TTL on your records — a TTL of 86400 means resolvers cache for 24 hours Before planned changes (migrations, IP changes), lower TTL to 300 (5 minutes) at least 24–48 hours in advance Check the SOA record's minimum TTL field — this sets the floor for negative caching (NXDOMAIN responses) After changes are stable, raise TTL back to 3600 (1 hour) or higher to reduce DNS query load on your nameservers Use the propagation checker to see which resolvers are still serving the old cached value

Question 24

DNS lookups are slow (>200ms) causing page load delays

Accepted Answer

Root cause: Nameservers are geographically distant, overloaded, or not using anycast routing. Check nameserver response times using the propagation checker — compare latency across global resolvers Verify you have at least 2 nameservers in different locations — single nameserver = single point of failure Consider migrating to a DNS provider with anycast routing (Cloudflare, NS1, Route53) for sub-10ms global response times Reduce the number of DNS lookups per page: consolidate third-party scripts, use DNS prefetch hints (<link rel="dns-prefetch">) Enable DNS prefetching in your HTML for external domains your page loads resources from

Question 25

SPF check fails with "too many DNS lookups" error

Accepted Answer

Root cause: SPF record exceeds the 10 DNS lookup limit defined in RFC 7208. Look up your SPF TXT record and count the number of include:, a:, mx:, and ptr: mechanisms Each include: directive counts as one lookup, and each nested include counts too — the total must stay under 10 Use an SPF flattening tool (dmarcian, MXToolbox) to resolve all includes into direct IP ranges Replace multiple include: statements with a single flattened list of ip4: and ip6: ranges After flattening, re-test with mail-tester.com or a DMARC analyzer to confirm SPF passes

Question 26

Subdomain needs its own DNS zone managed by a different provider

Accepted Answer

Root cause: NS delegation for a subdomain zone is missing or misconfigured. In your parent zone, add NS records for the subdomain pointing to the child zone's nameservers (e.g. sub.example.com NS ns1.childprovider.com) Do NOT add a glue A record in the parent zone for the subdomain itself — let the NS delegation handle resolution Ensure the child zone is fully configured at the new provider before adding the NS delegation Verify the delegation is working by querying the subdomain directly If the child nameservers are within the delegated subdomain itself (e.g. ns1.sub.example.com), you must add glue A records in the parent zone

Question 27

Wildcard DNS record (*.example.com) is overriding specific subdomain records

Accepted Answer

Root cause: Wildcard records match any label not explicitly defined — a missing specific record falls through to the wildcard. Check if a wildcard record (*.example.com) exists in your zone Wildcard records only match subdomains that have no explicit record — add a specific A or CNAME for the subdomain to override it Wildcards do not match the apex domain (example.com) — only subdomains If the wildcard is pointing to the wrong server, update it or add explicit records for each subdomain that needs a different destination Check DNS history to see if a specific record was accidentally deleted, causing fallthrough to the wildcard

Question 28

Subdomain resolves slowly or intermittently due to long CNAME chains

Accepted Answer

Root cause: Multiple CNAME records chained together add extra DNS round-trips per lookup. Look up the CNAME record and follow the chain — each hop adds latency RFC 1034 allows CNAME chains but resolvers may limit depth — keep chains to 3 hops or fewer If possible, point the CNAME directly to the final target hostname to eliminate intermediate hops Never create circular CNAME chains (A → B → A) — this causes SERVFAIL on all resolvers Use DNS comparison to check if the final resolved IP is consistent across resolvers

Question 29

Emails rejected with "no reverse DNS" error, or PTR lookup fails

Accepted Answer

Root cause: Missing PTR record for the mail server's IP address. PTR records are set by whoever owns the IP block — usually your hosting provider or ISP, not your domain registrar Contact your hosting provider and request a PTR record for your mail server IP pointing to your mail hostname (e.g. mail.example.com) The PTR hostname must match the HELO/EHLO hostname your mail server announces Verify the PTR record once set: look up the reverse IP (e.g. 1.2.3.4 → 4.3.2.1.in-addr.arpa) Also ensure a forward A record exists for the PTR hostname pointing back to the same IP (forward-confirmed rDNS)

Fix DNS Problems Fast

DNS Record Type Reference