Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
If a site opens by IP address but not by its domain name, the server is often reachable and the failure is in the hostname path: DNS records, registrar delegation, DNSSEC, or a stale cached answer. Check the exact hostname, query it through several public resolvers, verify the authoritative name servers, then investigate caching and DNSSEC. If the name resolves to the correct IP, move on to TLS, virtual-host, firewall, and IPv6 checks.
Why an IP address can work when the domain does not
A browser normally performs several steps before it requests a page. It first asks a DNS resolver to translate a name such as example.com into an IPv4 address (A record), an IPv6 address (AAAA record), or another hostname (CNAME record). It then connects to the returned address and sends the hostname in the HTTP Host header or during the TLS handshake.
Entering an IP address skips the name-to-address lookup. That proves only that at least one network route and one web-service endpoint can answer at that address. It does not prove that the domain has a record, that the registrar delegates the domain to the intended DNS provider, that every resolver sees the same answer, or that the web server is configured for that hostname.
The most common pattern is a missing or incorrect apex or subdomain record. Other causes include name servers that do not match at the registrar, edits made in the wrong DNS zone, old answers retained until their TTL expires, broken DNSSEC data, and an authoritative server that fails under normal resolver queries.
#1 Best Overall
- DUAL-BAND WIFI 6 ROUTER: Wi-Fi 6(802.11ax) technology achieves faster speeds, greater capacity and reduced network congestion compared to the previous gen. All WiFi routers require a separate modem. Dual-Band WiFi routers do not support the 6 GHz band.
- AX1800: Enjoy smoother and more stable streaming, gaming, downloading with 1.8 Gbps total bandwidth (up to 1200 Mbps on 5 GHz and up to 574 Mbps on 2.4 GHz). Performance varies by conditions, distance to devices, and obstacles such as walls.
- CONNECT MORE DEVICES: Wi-Fi 6 technology communicates more data to more devices simultaneously using revolutionary OFDMA technology
- EXTENSIVE COVERAGE: Achieve the strong, reliable WiFi coverage with Archer AX1800 as it focuses signal strength to your devices far away using Beamforming technology, 4 high-gain antennas and an advanced front-end module (FEM) chipset
- OUR CYBERSECURITY COMMITMENT: TP-Link is a signatory of the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Secure-by-Design pledge. This device is designed, built, and maintained, with advanced security as a core requirement.
Identify the exact symptom before changing anything
Record the complete hostname and the protocol that fails. example.com, www.example.com, and blog.example.com are separate DNS names and may be hosted in different zones. Note whether the IP test used HTTP or HTTPS, whether it included a port, and the precise browser or command-line error.
| Observed result | What it usually means | First check |
|---|---|---|
DNS_PROBE_FINISHED_NXDOMAIN |
The resolver concluded that the requested name does not exist or has no usable DNS records. | Verify the spelling, the zone apex, and the requested subdomain’s A, AAAA, or CNAME record. |
DNS_PROBE_POSSIBLE or an empty answer |
A lookup may be failing because a record is missing, inactive, or incorrectly delegated. | Compare answers from several public resolvers and query the authoritative servers directly. |
SERVFAIL |
The resolver could not obtain or validate an answer. DNSSEC failure and unreliable authoritative servers are important possibilities. | Compare a DNSSEC-validating resolver with a non-validating query and inspect DS, DNSKEY, and signature data. |
| Timeout or “server IP address could not be found” | The resolver path or an authoritative server is unreachable, overloaded, or filtering traffic. | Test multiple resolvers, then test each authoritative name server over UDP and TCP. |
| The name resolves, but the page still fails | DNS is probably working; the remaining fault may be TLS, HTTP host routing, a firewall, or IPv6. | Confirm the returned address, certificate name, virtual-host configuration, and both address families. |
Cloudflare describes DNS_PROBE_FINISHED_NXDOMAIN as a completed lookup whose result is that the domain does not exist. Treat that message differently from an HTTP 404: the request has not reached the web server at all.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Step 1: Verify the hostname and its DNS records
Check the apex and every active subdomain
Look up the exact name shown in the address bar. The apex (example.com) does not automatically create www.example.com. If visitors use both, each must have an intentional record: an A or AAAA record pointing to the origin, or a CNAME pointing to the service hostname supplied by the host.
- Confirm the spelling, hyphens, and top-level domain.
- Check that the zone is active at the DNS provider you actually use.
- Confirm that the A record contains the current IPv4 address and that any AAAA record contains a working IPv6 address.
- Check that a CNAME is allowed at the name you are editing and that its target still exists.
- Remove obsolete records only after confirming that no service depends on them.
A stale AAAA record can make some users fail over to an unreachable IPv6 endpoint even while an IPv4 test succeeds. Test A and AAAA answers separately rather than assuming that one healthy address makes the hostname healthy for everyone.
Query the name from your own computer
Use the operating system’s resolver first to see what ordinary applications receive:
nslookup example.com
dig example.com A
dig example.com AAAA
An answer section containing no address, an unexpected address, or an alias that ends in another missing name gives you a concrete record to investigate. Do not edit records until you know which hostname is failing; changing the apex will not repair a missing www record.
Rank #2
- Dual-band Wi-Fi with 5 GHz speeds up to 867 Mbps and 2.4 GHz speeds up to 300 Mbps, delivering 1200 Mbps of total bandwidth¹. Dual-band routers do not support 6 GHz. Performance varies by conditions, distance to devices, and obstacles such as walls.
- Covers up to 1,000 sq. ft. with four external antennas for stable wireless connections and optimal coverage.
- Supports IGMP Proxy/Snooping, Bridge and Tag VLAN to optimize IPTV streaming
- Access Point Mode - Supports AP Mode to transform your wired connection into wireless network, an ideal wireless router for home
- Advanced Security with WPA3 - The latest Wi-Fi security protocol, WPA3, brings new capabilities to improve cybersecurity in personal networks
Step 2: Compare independent public resolvers
A single resolver result cannot tell you whether the fault is local, resolver-specific, or authoritative. Query the same name through Google Public DNS, Cloudflare’s 1.1.1.1, Quad9, and OpenDNS. Replace the resolver address in these examples as needed:
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @9.9.9.9 example.com A
dig @208.67.222.222 example.com A
On systems without dig, use:
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1
| Comparison result | Likely scope | Next action |
|---|---|---|
| All public resolvers return the same correct address | DNS is probably correct; investigate the local cache, browser, TLS, HTTP routing, firewall, or IPv6. | Test the hostname with curl and inspect the server’s certificate and host routing. |
| All public resolvers return NXDOMAIN or SERVFAIL | The domain or its authoritative DNS service is likely at fault. | Inspect delegation and query each authoritative server. |
| Only one resolver fails | The failing resolver’s cache, policy, or network path may be responsible. | Flush local/provider caches, test from another network, and report the inconsistent resolver behavior if it persists. |
| Resolvers return different addresses | Propagation, low TTL, split DNS, duplicate zones, or inconsistent authoritative servers may be involved. | Compare TTLs and authoritative answers before changing records again. |
Google’s Public DNS guidance uses this distinction: when other public resolvers have the same difficulty, the problem is most likely with the domain or its authoritative servers; when only one resolver fails, investigate that resolver path.
Step 3: Inspect delegation and authoritative name servers
Find the delegated NS records
The registrar publishes which name servers are authoritative for the domain. Ask a resolver for those NS records:
dig example.com NS
dig +trace example.com
Write down every authoritative server returned. Then query each one directly for the records you need:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutedig @ns1.dns-provider.example example.com A
dig @ns2.dns-provider.example example.com A
dig @ns1.dns-provider.example www.example.com CNAME
The answers should be consistent, and the registrar’s delegated names must exactly match the names assigned by the active DNS provider. Cloudflare notes that mismatched registrar name servers prevent correct resolution. DigitalOcean lists incomplete name-server propagation, incorrect registrar configuration, and multiple active DNS providers among common causes.
Look for duplicate or abandoned zones
It is possible to have two hosted zones for the same domain at one provider, or to leave the old provider’s names at the registrar after creating a new zone. In that situation, you may edit records successfully but not in the zone that the public Internet uses. AWS explains that a recent DNS-service transfer can continue serving the old provider when registrar name servers were not changed, and that duplicate hosted zones can lead to edits in the wrong place.
Rank #3
- NIGHTHAWK WIFI 6 ROUTER FOR YOUR WHOLE HOME: Delivers fast, reliable WiFi across every room of your apartment or small home for streaming, gaming, video calls, and smart home devices, all running at the same time without slowing each other down.
- WORKS WITH YOUR EXISTING INTERNET SERVICE: Pairs with your existing modem or gateway via ethernet. Compatible with most cable, fiber, DSL, and satellite providers. Some gateways and modem router combos may require bridge mode. No coax needed.
- SET UP AND MANAGE YOUR NETWORK WITH THE NIGHTHAWK APP: Download the free Nighthawk app on iOS or Android for guided setup. Manage WiFi, run speed tests, pause devices, and set up guest networks from anywhere. Active internet required.
- READY FOR THE DEVICES YOU ALREADY OWN: Your phones, laptops, and TVs work right out of the box. WiFi 6 delivers speeds up to 1.8 Gbps across 2.4 GHz and 5 GHz bands. Backward compatible with WiFi 5 and earlier.
- COVERAGE IN EVERY ROOM: Covers up to 1,500 sq. ft. for up to 20 connected devices. Walls, floors, and interference can reduce range. Larger or multi-story homes may benefit from a NETGEAR Orbi mesh WiFi system.
- Copy the exact NS set displayed by the active DNS provider.
- Compare it with the NS set shown at the registrar.
- Delete or clearly label unused zones so future edits cannot be made in the wrong account.
- After correcting delegation, repeat the direct authoritative queries and the public-resolver comparison.
Step 4: Account for TTL and cached answers
Every DNS record has a TTL, measured in seconds. AWS defines TTL as the period during which resolvers may cache information such as a web server’s IP address. A resolver is allowed to keep the old answer until that TTL expires, even after you have corrected the authoritative record.
Inspect the TTL in a dig response. A large remaining value indicates that a previous answer is still cached. A low value does not force instant global convergence because different resolvers may have cached the record at different times, and negative answers can also be cached.
How long should propagation take?
There is no universal propagation timer. The record’s TTL, negative caching, registrar delegation, provider behavior, and resolver refresh schedule determine when a particular user sees the new answer. DigitalOcean’s 2026 support guidance says name-server changes usually take 24–48 hours to update completely; that is an operational expectation, not a guarantee for every record or geography.
Do not repeatedly change the record while waiting. Each change can create another cached value and make the final state harder to diagnose. First verify that the authoritative servers are correct, then monitor several resolvers until their answers converge.
Flush caches only after authoritative data is right
Once the authoritative answer is correct, clear caches that you control. Restarting a browser usually does not clear the operating-system resolver cache, and flushing a local cache cannot repair an incorrect authoritative record.
- On Windows, run
ipconfig /flushdnsin an elevated Command Prompt. - On systems using
systemd-resolved, runsudo resolvectl flush-caches. - For browsers with their own DNS cache, close all windows and restart the browser; enterprise or ISP caches may require the network administrator or provider to clear them.
Google documents cache-flush tooling for its public resolver. Use such tools only after confirming that the published record is the one you intend to serve.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
- 𝐅𝐮𝐭𝐮𝐫𝐞-𝐑𝐞𝐚𝐝𝐲 𝐖𝐢-𝐅𝐢 𝟕 - Designed with the latest Wi-Fi 7 technology, featuring Multi-Link Operation (MLO), Multi-RUs, and 4K-QAM. Achieve optimized performance on latest WiFi 7 laptops and devices, like the iPhone 16 Pro, and Samsung Galaxy S24 Ultra.
- 𝟔-𝐒𝐭𝐫𝐞𝐚𝐦, 𝐃𝐮𝐚𝐥-𝐁𝐚𝐧𝐝 𝐖𝐢-𝐅𝐢 𝐰𝐢𝐭𝐡 𝟔.𝟓 𝐆𝐛𝐩𝐬 𝐓𝐨𝐭𝐚𝐥 𝐁𝐚𝐧𝐝𝐰𝐢𝐝𝐭𝐡 - Achieve full speeds of up to 5764 Mbps on the 5GHz band and 688 Mbps on the 2.4 GHz band with 6 streams. Enjoy seamless 4K/8K streaming, AR/VR gaming, and incredibly fast downloads/uploads.
- 𝐖𝐢𝐝𝐞 𝐂𝐨𝐯𝐞𝐫𝐚𝐠𝐞 𝐰𝐢𝐭𝐡 𝐒𝐭𝐫𝐨𝐧𝐠 𝐂𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐨𝐧 - Get up to 2,400 sq. ft. max coverage for up to 90 devices at a time. 6x high performance antennas and Beamforming technology, ensures reliable connections for remote workers, gamers, students, and more.
- 𝐔𝐥𝐭𝐫𝐚-𝐅𝐚𝐬𝐭 𝟐.𝟓 𝐆𝐛𝐩𝐬 𝐖𝐢𝐫𝐞𝐝 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 - 1x 2.5 Gbps WAN/LAN port, 1x 2.5 Gbps LAN port and 3x 1 Gbps LAN ports offer high-speed data transmissions.³ Integrate with a multi-gig modem for gigplus internet.
- 𝐎𝐮𝐫 𝐂𝐲𝐛𝐞𝐫𝐬𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐂𝐨𝐦𝐦𝐢𝐭𝐦𝐞𝐧𝐭 - TP-Link is a signatory of the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Secure-by-Design pledge. This device is designed, built, and maintained, with advanced security as a core requirement.
Step 5: Investigate DNSSEC when the error is SERVFAIL
DNSSEC adds signatures that validating resolvers check before accepting a DNS answer. A broken chain can produce SERVFAIL even though a non-validating lookup appears to work.
Google recommends comparing a DNSSEC-validating query with a query that does not validate. If dns.google returns SERVFAIL while queries without DNSSEC succeed, investigate:
- A stale DS record left at the registrar after moving DNS providers.
- DS data that does not match the DNSKEY published by the authoritative service.
- Expired or otherwise invalid signatures.
- Authoritative responses so large that the server or network mishandles UDP truncation and the required TCP retry.
Use DNSViz or a DNSSEC Analyzer to follow the chain from the parent zone to the authoritative DNSKEY. Do not remove DNSSEC blindly: either publish matching keys and DS records or deliberately remove stale delegation data during a controlled migration.
Step 6: Check authoritative-server reliability
When every public resolver reports failure, test each authoritative server separately. All of them should answer consistently, not just the first server in the NS list.
Recommended Free Tools
- Query each server for the apex A, AAAA, and NS records.
- Repeat the queries from more than one network if possible.
- Check whether large responses set the truncation flag and whether the server answers the follow-up TCP query.
- Look for intermittent timeouts, refusal codes, or rate limits that block recursive resolvers.
- Confirm that no firewall or access-control rule permits your test machine while denying normal resolver traffic.
Google’s Public DNS troubleshooting guidance specifically calls for authoritative servers to support UDP truncation and TCP retry, answer consistently, and avoid overly strict limits that prevent resolver access.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 7: Separate DNS from web-server and network failures
If a public resolver returns the expected IP, stop changing DNS and test the next layer. An IP address can serve a default site while the named virtual host is missing, which makes the domain appear broken even though the address responds.
Best Value
- Dual band router upgrades to 1200 Mbps high speed internet (300mbps for 2.4GHz plus 900Mbps for 5GHz), reducing buffering and ideal for 4K stream
- Full Gigabit Ports - Gigabit Router with 4 Gigabit LAN ports, ideal for any internet plan and allow you to directly connect your wired devices
- Boosted Coverage - Four external antennas equipped with Beamforming technology extend and concentrate the Wi-Fi signals
- MU-MIMO technology - (5GHz band) allows high speeds for multiple devices simultaneously
- Access Point Mode - Supports AP Mode to transform your wired connection into wireless network, an ideal wireless router for home
Test the hostname and host header
Use the hostname in the request so the server can select the correct virtual host:
curl -I https://example.com
curl -v https://example.com
Check the response status, the certificate presented during TLS, and whether the certificate covers the exact name. A certificate issued only for www.example.com will not validate example.com unless the apex is included.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsCheck HTTP routing and firewall rules
- Confirm the web server has a site definition for the hostname, not only for its IP address.
- Verify that ports 80 and 443 are open at the host firewall, cloud firewall, and any reverse proxy.
- Check redirects for loops or a target hostname that lacks DNS.
- Review application logs using the request’s hostname and timestamp.
Test IPv4 and IPv6 independently
Run curl -4 -I https://example.com and curl -6 -I https://example.com. If IPv4 succeeds but IPv6 fails, repair or remove the incorrect AAAA record, or fix routing and firewall rules on the IPv6 endpoint. Some users will prefer IPv6 and therefore see failures that an IPv4-only test misses.
A compact decision path for common cases
| Case | Interpretation | Resolution path |
|---|---|---|
| IP works; all resolvers return NXDOMAIN | The requested name has no publicly usable record. | Create or correct the apex/subdomain record in the authoritative zone, then verify delegation. |
| IP works; resolvers return different addresses | Cached data, split DNS, duplicate zones, or inconsistent name servers. | Compare authoritative answers and TTLs; stop editing until the active zone is identified. |
| Resolvers return SERVFAIL; non-DNSSEC query works | DNSSEC validation or large-response handling is failing. | Repair DS/DNSKEY/signatures and confirm UDP-to-TCP fallback. |
| Resolvers return the right IP; HTTPS fails | DNS is functioning. | Inspect the certificate, virtual host, firewall, proxy, and IPv6 path. |
| Only one ISP or resolver fails | The fault is probably local to that resolver path or its cache. | Flush caches, test another network, and provide resolver results to the affected network operator. |
What to evaluate when choosing a DNS provider
If the incident exposes weaknesses in your current setup, compare providers on operational capability rather than a generic speed claim. The useful criteria are:
| Criterion | Questions to ask |
|---|---|
| Registrar and delegation workflow | Can you see the exact assigned NS values, change them safely, and protect the registrar account? |
| Record support | Are A, AAAA, CNAME, MX, TXT, CAA, alias, and delegated-subdomain records supported where your services need them? |
| DNSSEC | Does the service automate signing, key rollover, DS publication, and validation diagnostics? |
| TTL controls | Can you set practical TTLs and view the currently published value? |
| Resolver visibility | Are query logs, authoritative responses, and failure codes available for troubleshooting? |
| Authoritative reliability | Are multiple name servers geographically and operationally independent, with UDP truncation and TCP retry handled correctly? |
| Migration handling | Can you stage the new zone, compare records, and obtain clear instructions for changing registrar delegation? |
| Monitoring and support | Can the service alert on NXDOMAIN, SERVFAIL, expired DNSSEC signatures, and unreachable name servers? |
Prevent the problem from returning
- Keep an inventory of every apex,
www, application, mail, and delegated subdomain. - Document the registrar, authoritative provider, account owner, and current NS set.
- Remove duplicate hosted zones and label staging zones clearly.
- Monitor A, AAAA, CNAME, NS, MX, and DNSSEC status from outside your own network.
- Before a migration, lower TTLs in advance, copy and verify the complete zone, publish the new zone, then change delegation once.
- After migration, query each authoritative server and several public resolvers; retain the old service until answers have converged.
- Test both IPv4 and IPv6 and renew certificates for every hostname users can enter.
When to contact the registrar, DNS provider, or host
Contact the registrar when the delegated NS records are wrong, a DS record cannot be removed or corrected, or the domain is unexpectedly placed on hold. Contact the DNS provider when authoritative servers disagree, time out, fail TCP fallback, or return malformed DNSSEC data. Contact the web host when the hostname resolves correctly but the certificate, virtual host, firewall, or application still rejects requests.
Include the exact hostname, UTC timestamps, results from at least two public resolvers, the delegated NS set, direct authoritative answers, and whether A and AAAA behave differently. This evidence lets support distinguish a missing record from a cache, delegation, DNSSEC, or HTTP-layer problem without guesswork.
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.
