The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
A newly registered domain is not automatically connected to a website. The domain must be delegated to the correct authoritative nameservers, those nameservers must publish working records for the exact hostname visitors use, the hosting account must accept that hostname, and HTTPS must have a certificate for it. Diagnose those layers in that order.
Start by recording the browser’s exact error and whether you entered the apex name (such as example.com) or the www hostname. Then verify registration and nameserver delegation, inspect NS and SOA responses, check the apex and www records, separate DNS failures from hosting failures, and only then troubleshoot TLS.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems
First, identify what “won’t open” actually means
Different browser messages point to different layers of the setup. Write down the complete hostname in the address bar and the exact error before changing anything.
| Browser or connection result | What it usually indicates | First check |
|---|---|---|
DNS_PROBE_FINISHED_NXDOMAIN |
The DNS lookup completed, but the resolver found no records for that name. Cloudflare defines NXDOMAIN as a result indicating that the domain does not exist in DNS. | Check the hostname spelling, nameserver delegation, and whether an A, AAAA, or CNAME record exists. |
DNS_PROBE_POSSIBLE |
DNS may be missing or incorrect, although the resolver has not given a definitive “name does not exist” result. | Inspect authoritative NS, SOA, and address records from more than one network. |
| “Server not found,” timeout, or intermittent lookup | Delegation, authoritative-server health, DNSSEC, or an unreachable target may be involved. | Query the authoritative nameservers directly and check DNSSEC status. |
| A provider parking page, default web page, blank page, or HTTP error | DNS resolves, but the hosting origin is not attached to the custom domain or the record points to the wrong infrastructure. | Confirm the domain is added in the hosting account and that the target is the current origin. |
| HTTP works but HTTPS fails, loops, or warns | The DNS path is working; the certificate, proxy mode, redirect, or hostname coverage is wrong. | Test both hostnames over HTTP and HTTPS and inspect certificate names and proxy settings. |
Always test the exact name you intend to publish. The apex (example.com) and www.example.com are separate DNS names and can have different records.
#1 Best Overall
Check registration and nameserver delegation
Confirm that the domain is registered and active
Sign in to the registrar and verify that the domain appears in the account, has not expired, and is not suspended or locked in a way that prevents DNS changes. A successful purchase confirmation alone does not prove that the registry has published the domain’s delegation.
Find the DNS or nameserver section in the registrar. If you use a separate DNS provider, copy the provider’s authoritative nameservers exactly, including every hostname and any required trailing dot shown by the provider. Delete unintended old nameservers. A mixed set can send different visitors to different DNS servers or leave the domain without a valid authoritative response.
Cloudflare notes that the nameservers in the registrar must exactly match the nameservers it assigned; otherwise the domain will not resolve correctly. Some registrars can take up to 24 hours to publish a nameserver change, according to Cloudflare’s 2026 documentation. That is an upper bound reported for some registrars, not a universal propagation timer.
Verify the delegation from outside the registrar’s dashboard
A registrar’s control panel may show the intended values before the registry has published them. Query NS records from a terminal or an authoritative DNS-checking service after saving the change. Compare the returned nameservers with the set supplied by your DNS provider. Remove any extra or misspelled server.
Test from a second resolver or a different network, such as mobile data. One local resolver can retain an older delegation while another already sees the new one. Do not repeatedly switch nameservers while waiting; each change creates another publication and caching cycle.
Inspect NS and SOA before checking website records
NS and SOA responses establish whether the DNS zone itself is reachable. If these fail, editing an A record will not fix the problem.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use dig for the domain’s delegation
On macOS, Linux, and Windows systems with a DNS utilities package, run:
dig NS example.com
dig SOA example.comReplace example.com with your domain. An NS query should return the authoritative nameservers. An SOA query should return the zone’s start-of-authority record, including the primary server and timing values. Cloudflare requires valid NS and SOA responses when a domain is added, and Google recommends checking delegation, DNSSEC, authoritative-server health, and response behavior with tools such as dig and DNSViz.
To ask a specific authoritative server directly, first obtain its name from the NS result, then run:
dig @ns1.example-dns.com example.com A
dig @ns1.example-dns.com example.com SOAA response from the authoritative server proves that the zone is being served there. A timeout, SERVFAIL, or an empty answer requires fixing delegation, server availability, or DNSSEC before you adjust web hosting.
Interpret the important response codes
- NOERROR with an answer: The name exists and the queried record type was returned.
- NOERROR with no answer: The zone exists, but that record type may not be defined. For example, the apex may have no AAAA record.
- NXDOMAIN: The authoritative system says the queried name does not exist. Check spelling, the zone being served, and whether you created the record under the correct domain.
- SERVFAIL: A resolver could not complete validation or obtain a usable response. DNSSEC errors and broken authoritative servers are common causes.
- Timeout or refused connection: The authoritative server may be unreachable, incorrectly delegated, or blocking queries.
Verify the apex and www records
Point the apex to the actual origin
Query the address records:
dig example.com A
dig example.com AAAAAt least one returned address must belong to the current web-hosting origin. Use the exact IPv4 address or IPv6 address supplied by the host; do not substitute an address from an old server, a temporary setup, or a different project. If your provider requires a CNAME-style target at the apex, follow that provider’s documented method rather than creating an invalid record combination.
An obsolete AAAA record can be particularly confusing: visitors on IPv6-capable networks may reach the wrong server even when the A record is correct. Remove an old AAAA record or replace it with the current IPv6 target when your host confirms that IPv6 is supported.
Make www intentional
Check the hostname many visitors actually type:
dig www.example.com A
dig www.example.com AAAA
dig www.example.com CNAMECreate the www record if it is missing. It may be a CNAME to the apex or to a host-provided target, or it may use an address record, depending on your DNS provider and hosting design. Cloudflare notes that a www record helps visitors who enter the prefixed hostname find the site.
Decide which hostname is canonical. Configure the host and web server to redirect the other hostname to it with a single permanent redirect. A DNS record alone does not create that redirect; the hosting platform must recognize both names.
Recommended Free Tools
Watch for record conflicts
- Do not publish a CNAME and an A or AAAA record at the same hostname.
- Check for duplicate A records left from an earlier host. Multiple addresses can intentionally support load balancing, but an old address can send users to a dead or unrelated server.
- Check the record name field in the DNS editor. Many panels append the zone automatically, so entering
www.example.comin a field that expects onlywwwcan createwww.example.com.example.com. - Confirm that you edited the authoritative DNS provider, not a dormant zone at the registrar. The NS response tells you which service is authoritative.
Allow for caching without guessing a universal propagation time
DNS responses are cached according to their TTL. After a record or nameserver change, some resolvers can continue returning the previous answer until that cached value expires, while others query the new authority immediately. A local operating-system cache, browser cache, router, corporate resolver, and public resolver can each hold different results.
Check the authoritative server directly to determine whether the new record is published. Then compare results through more than one recursive resolver and network. If the authoritative answer is correct but one resolver is stale, wait for that resolver’s cache rather than changing the record again. Lowering a TTL after a change does not retroactively shorten an answer already cached elsewhere.
Nameserver changes are a different event from ordinary record edits. Cloudflare documents that some registrars may take up to 24 hours to publish nameserver updates. During that window, old and new delegations can be observed from different locations.
Investigate DNSSEC when the result is SERVFAIL or setup remains pending
DNSSEC adds a chain of cryptographic signatures. At the registrar, a DS record tells resolvers which DNSSEC key to trust. If that DS record refers to keys no longer published by the authoritative provider, validating resolvers can return SERVFAIL even though unsigned DNS queries appear to work.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Fix a stale DS record during a nameserver move
- Check the registrar’s DNSSEC section for an existing DS record.
- Compare it with the DNSSEC configuration at the current authoritative provider.
- If the DS belongs to the previous provider and you are switching nameservers, remove the old DS record at the registrar before completing the switch. Cloudflare specifically documents this requirement.
- Wait for the DS removal to publish, then confirm that validating resolvers receive normal NS, SOA, and address responses.
- Enable DNSSEC again only through the provider that is now authoritative, using the exact DS values it supplies.
Do not delete random DNS records to address DNSSEC. A DS record is published at the registrar, while DNSKEY and related records are published in the authoritative zone; both sides must match.
Separate DNS resolution from the hosting account
If dig returns the expected address or CNAME but the browser shows a blank page, a provider default page, a refusal, or a server error, DNS is probably doing its job. The request is reaching an origin that does not know your domain.
Attach the custom domain at the host
- Open the hosting control panel and find the site, domains, or custom-domain area.
- Add the exact apex name and, if supported separately, the
wwwname. - Complete any ownership verification the host requests.
- Confirm that the domain is assigned to the intended site, application, or document root rather than a default project.
- Check that the host’s displayed DNS target matches the record you published.
After a hosting move, point DNS to the new hosting infrastructure. Google Search Central gives this as a required site-move step. Leaving records aimed at the former server can produce an old copy, a closed account page, or an unrelated site even though DNS resolves successfully.
Rank #4
Use the symptom to locate the origin problem
- Provider parking or “domain not configured” page: The domain is not attached to a site at that provider, or the request reached a shared default virtual host.
- Old version of the site: An A, AAAA, or CNAME record still points to the previous host, or a cache is serving old content.
- Connection refused or timeout: The origin service may be stopped, firewalled, or listening only on a different address or port.
- 404 for the home page: The domain reaches the right application, but its route, document root, or deployment is incomplete.
- Works by IP address but not by domain: The web server may lack a virtual-host binding for the domain. Add the hostname at the host; do not rely on the IP test as proof that the public site is configured.
Finish with HTTP and HTTPS checks
Test each intended hostname explicitly:
curl -I http://example.com
curl -I https://example.com
curl -I http://www.example.com
curl -I https://www.example.comLook for the HTTP status, the Location header, and whether the response comes from the expected host. A normal setup commonly redirects HTTP to HTTPS and redirects one hostname variant to the canonical variant, but the exact redirect policy is controlled by the host or web server.
Confirm certificate coverage
Open the certificate details in the browser and verify that its subject or Subject Alternative Name list includes every hostname visitors can use. A certificate for www.example.com does not automatically cover example.com, and the reverse is also true unless both names are listed.
Certificate issuance can fail when the DNS record is missing, the domain is not attached to the hosting account, or a proxy prevents the validation method from reaching the origin. Correct DNS and domain attachment first, then request or reissue the certificate through the host.
Check proxy and redirect settings
If a DNS provider offers proxying, ensure the proxy mode matches the origin’s TLS configuration. Cloudflare documents that A, AAAA, and CNAME records may require appropriate proxy settings. A mismatch can cause an HTTPS loop, an origin certificate error, or a redirect that alternates between HTTP and HTTPS.
- Use one clear HTTPS policy; avoid simultaneous redirects at several layers that point back to each other.
- Ensure the origin accepts the protocol and hostname the proxy uses.
- After changing TLS or proxy settings, test in a private browser window and with
curlso an old browser redirect is not mistaken for a current server response.
A practical decision path
- Capture the error and hostname. Record whether the failing name is the apex or
www. - Check registration and delegation. Confirm the domain is active and the registrar publishes only the exact authoritative nameservers supplied by your DNS provider.
- Query NS and SOA. If either is missing, timing out, or returning
SERVFAIL, fix delegation or DNSSEC before editing web records. - Query A, AAAA, and CNAME. Make the apex and
wwwrecords point to the current hosting origin, with no stale or conflicting entries. - Compare networks. Check an authoritative response, another recursive resolver, and a second internet connection to distinguish publication from caching.
- Inspect the host account. Attach both intended hostnames to the correct site and confirm the target is the current infrastructure.
- Test HTTP and HTTPS. Correct certificate names, proxy mode, and redirect rules only after DNS and hosting work.
Choosing a registrar, DNS provider, or host for a new setup
Changing providers does not repair a wrong record by itself. Before purchasing or migrating, compare the operational details that determine how quickly you can diagnose the next failure.
| Capability | Questions to ask | Why it matters |
|---|---|---|
| Authoritative DNS control | Who serves the NS and SOA records, and can you identify that service unambiguously? | You need to know where edits actually take effect. |
| Record visibility | Can you inspect A, AAAA, CNAME, NS, SOA, TXT, and DNSSEC-related records without hidden defaults? | Transparent records make NXDOMAIN, stale targets, and verification failures easier to isolate. |
| DNSSEC support | Can the service publish DNSSEC correctly and explain how to remove or rotate DS records during a migration? | A stale DS record can make validating resolvers return SERVFAIL. |
Apex and www mapping |
Does the platform document both hostnames and explain any apex-CNAME limitation? | The two names may need separate records and separate application bindings. |
| Certificate issuance | Will certificates include both the apex and www, and can you see issuance status and renewal failures? |
DNS can be correct while HTTPS still fails for one hostname. |
| Propagation and status visibility | Are nameserver changes, DNS edits, and certificate requests given clear status information? | You can distinguish a pending publication from a misconfiguration. |
| Origin custom-domain support | Can the host attach the exact domain to the intended site, application, or virtual host? | Resolution alone does not make the origin serve your content. |
Prevent the problem on the next change
- Keep a written inventory of the registrar, authoritative DNS provider, host, canonical hostname, and current A, AAAA, and CNAME targets.
- Before migrating, record the existing NS, SOA, DNSSEC, and web records so you can identify an accidental deletion.
- Change one layer at a time: delegation, then records, then host binding, then TLS. Test after each layer.
- Use a short maintenance window and test both apex and
wwwfrom a wired or local connection and a mobile network. - Remove old A, AAAA, CNAME, and DS records only after confirming that no active service still depends on them.
- Keep the registrar account’s contact email and multifactor authentication current; an inaccessible account can prevent urgent DNS or DS changes.
Once NS and SOA are healthy, both hostnames resolve to the current origin, the host accepts the custom domain, and certificates cover the names you publish, the domain should open normally. If one layer still fails, return to the first layer whose observed response differs from the intended configuration instead of changing unrelated settings.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
