#LOREHAVEN
Technical Support Request: Intermittent DNS Resolution Failure for Lorehaven Website
### Website URL https://lorehaven.great-site.net ### Error Message Title: Intermittent DNS Resolution Failure Affecting My Lorehaven Website Hello InfinityFree Technical Support Team, I am requesting a thorough investigation into an ongoing DNS resolution problem affecting my website hosted on InfinityFree. Some devices and network connections cannot open the website and display the browser error DNS_PROBE_FINISHED_NXDOMAIN. However, the website resolves successfully through Google Public DNS. My Android phone can access it when Google Private DNS is enabled and set to dns.google, but it fails to resolve when using the default DNS configuration. The same hostname therefore resolves successfully through one DNS resolver but fails through another. I have performed several checks and included the results below so your team can investigate the cause without requiring me to repeat the preliminary tests. Website hostname: lorehaven followed by a dot, then great-site followed by a dot, then net. Hosting IP returned by Google DNS: 185 dot 27 dot 134 dot 214. 1. DNS and website tests completed Test A — Google Public DNS A-record lookup I queried Google Public DNS for the A record of my website hostname. The result was: DNS status: 0 (NOERROR) Record type: A Returned IPv4 address: 185 dot 27 dot 134 dot 214 Initial TTL: 20803 seconds The response successfully mapped my website hostname to the hosting IP address. This establishes that Google Public DNS can resolve the hostname. It does not prove that every authoritative nameserver is responding consistently or that every ISP can resolve it. Test B — Parent-domain nameserver lookup I queried the NS records for the parent domain, great-site followed by a dot, then net. Google Public DNS returned seven nameserver records: ns1 dot great-site dot net ns2 dot great-site dot net ns2 dot byet dot org ns1 dot byet dot org ns3 dot byet dot org ns4 dot byet dot org ns5 dot byet dot org The DNS status was 0 (NOERROR), and the TTL was 21600 seconds. The response identified 198 dot 251 dot 86 dot 153 as the responding DNS server. I would appreciate confirmation that these seven nameservers are the expected configuration and that the parent-domain delegation and authoritative records are correct. The lookup does not prove that all listed servers are currently authoritative, reachable, correctly configured, or returning identical answers. Test C — Subdomain NS-record lookup I queried the NS record for my website hostname. The response returned DNS status 0 (NOERROR) and an SOA record in the Authority section for the parent domain. The SOA data began with the primary nameserver ns1 dot great-site dot net, followed by the contact name support dot great-site dot net, and serial number 2006112402. This was a recursive Google DNS lookup, not a direct query to each authoritative nameserver. I am not treating it as proof that the authoritative nameservers are healthy. Test D — Repeated Google DNS lookups I performed additional Google Public DNS A-record lookups. Both returned: DNS status: 0 (NOERROR) IPv4 address: 185 dot 27 dot 134 dot 214 TTL: 3868 seconds The queries used the DNS checking-disabled parameter cd=1. Both responses returned the same IP address. These were recursive Google DNS queries and did not independently verify the responses from the authoritative nameservers. Test E — Windows default DNS resolver My Windows computer uses the default DNS resolver 10 dot 191 dot 26 dot 126. I ran the command: nslookup followed by my website hostname. The query resulted in DNS request timeouts or a server failure instead of successfully resolving the hostname. Test F — Windows lookup using Google Public DNS I then queried the same hostname using Google’s resolver at 8 dot 8 dot 8 dot 8. This successfully returned 185 dot 27 dot 134 dot 214. The hostname therefore resolved through Google Public DNS while the default resolver on the same computer failed. Test G — Windows lookup using Cloudflare DNS I also queried the hostname using Cloudflare’s resolver at 1 dot 1 dot 1 dot 1. The request timed out repeatedly. I cannot determine whether this is a resolver-specific issue or whether direct DNS queries to that resolver are blocked or interrupted by my current network. I am not presenting this result as proof of a Cloudflare DNS fault. Test H — External website availability check An external HTTP status checker previously tested my website over HTTPS. It returned: HTTP status: 200 Redirects: 0 This indicates that the checker could reach the website at the time of testing. It does not prove that every network can resolve the hostname or that the site is continuously available. Test I — Command-line HTTP checks I also attempted command-line HTTP checks from my Windows computer. A normal request failed to resolve the hostname. When I forced the hostname to use the hosting IP with the curl --resolve option, the HTTPS connection closed abruptly and the HTTP request returned an empty reply. These results were inconclusive. I am not treating them as proof that the hosting server is down because the external status checker previously returned HTTP 200. Please check the server and virtual-host configuration if necessary, while prioritising the inconsistent DNS resolution. Test J — Android phone access My Android phone can access the website when Google Private DNS is enabled and set to dns.google. When using the default DNS configuration, the hostname fails to resolve. This suggests a resolver-specific or network-specific issue may be involved, but it does not establish whether the cause is ISP filtering, cached negative responses, or authoritative DNS behaviour. Test K — InfinityFree service status I checked the official InfinityFree status page. At the time of checking, it reported no current issues and showed the relevant services as operational. I also found previous status incidents involving DNS resolution and the free-subdomain domain used by my website. I would appreciate confirmation that the current DNS configuration is healthy, since a general status page may not identify an issue affecting one hostname or one particular resolver. 2. Current findings The available evidence establishes that: Google Public DNS resolves the website hostname to the hosting IP address. My Windows computer’s default resolver fails to resolve the hostname consistently. Google DNS queries work, while direct queries to Cloudflare DNS time out from my current network. An external HTTP status checker previously received HTTP 200. My Android phone can access the website when Google Private DNS is enabled. Google Public DNS returns seven nameserver records for the parent domain. I have not independently queried each authoritative nameserver to establish that they all return consistent records. The available evidence does not conclusively identify whether the cause is authoritative DNS, a recursive resolver, an ISP/network, or another part of the DNS resolution process. The difference between successful Google DNS resolution and failed default-resolver resolution is the main reason for this support request. 3. Specific investigations requested A. Verify the authoritative DNS configuration Please confirm that the delegation and authoritative DNS configuration for the parent domain and my website hostname are correct. In particular, please verify: Whether the seven nameservers returned by Google Public DNS are the expected configuration. Whether the two nameservers under great-site dot net are correctly configured and reachable. Whether the five nameservers under byet dot org are expected to appear alongside them. Whether all authoritative nameservers serve consistent and current records for my website hostname. Whether the A record consistently points to the correct hosting IP address. Whether any delegation, glue-record, zone-file, DNSSEC, or other DNS configuration issue could explain the inconsistent resolution. I am not asserting that the configuration is incorrect. I am requesting verification. B. Check authoritative responses directly Please query the authoritative nameservers directly rather than relying exclusively on recursive DNS lookups. Please verify that the authoritative servers respond correctly and consistently for: The website’s A record. The parent domain’s NS records. The relevant SOA record and serial number. Any relevant delegation or DNSSEC configuration. Please check for inconsistent responses, failed queries, stale records, or intermittent authoritative-server failures. C. Investigate resolver-specific or network-specific failures Please investigate whether there is evidence of: A temporary DNS resolution issue affecting the free-subdomain domain. Authoritative DNS timeouts or inconsistent responses. Incorrect negative DNS caching. Filtering that affects the free subdomain. A resolver-specific or hosting-side issue that could cause some visitors to receive NXDOMAIN. If the issue is outside InfinityFree’s control, please explain which part of the DNS resolution path is responsible and what evidence supports that conclusion. D. Verify the hosting configuration Please confirm that the hosting account and subdomain mapping are configured correctly and that my website hostname is associated with the intended hosting account and IP address. I do not want to change website files or configuration unnecessarily if the underlying problem is DNS resolution. 4. Requested resolution My goal is to make the existing website consistently accessible to visitors without asking customers to change their DNS settings or perform technical troubleshooting. Please provide a clear response addressing: Whether the authoritative DNS configuration is correct. Whether all authoritative nameservers return consistent responses. Whether you identified a hosting-side DNS issue or known filtering affecting the domain. Whether the failure appears to originate outside InfinityFree’s infrastructure and what evidence supports that conclusion. What corrective action is available without changing the website address. Whether I need to change anything in my hosting account. If you cannot reproduce the issue from your own network, please do not assume that the problem does not exist. The difference between the default resolver and Google Public DNS is documented above. Please advise what additional server-side evidence is needed to isolate the failing part of the DNS resolution process. 5. Important constraints I want to preserve the existing Lorehaven website exactly as it is. Please do not recommend rebuilding the website, reinstalling WordPress, deleting the hosting account, migrating to another provider, or changing the subdomain as an initial troubleshooting measure. The available evidence does not justify those actions. My requirements are: Keep the existing website address unchanged. Keep the current hosting account and website files. Preserve all existing image URLs and file paths. Avoid unnecessary changes to WordPress, the theme, custom code, and uploaded media. Correct the underlying issue if it is within InfinityFree’s control. If the issue is caused by an external ISP or DNS resolver, explain that limitation and identify the appropriate party to investigate it. I am using the existing free subdomain and would like to continue using it if the issue can be resolved without changing the website address. 6. Closing request I have performed the preliminary DNS and website availability checks available to me and have included the actual results above. The issue remains unresolved because the website is accessible through some DNS paths but fails through others. Please investigate the authoritative DNS configuration and inconsistent resolution behaviour, and let me know your findings and the appropriate next action. Thank you for your time and assistance. Kind regards, Lorehaven ### Other Information Additional context: I have not changed my WordPress files, website content, image URLs, or hosting configuration to troubleshoot this issue. Google Public DNS resolves the domain to 185.27.134.214, but some default DNS connections fail with DNS_PROBE_FINISHED_NXDOMAIN. Enabling Google Private DNS on my Android phone restores access. I would appreciate a server-side investigation before making any changes to the existing website or subdomain.
forum.infinityfree.com
October 25, 2026 at 3:17 PM
Technical Support Request: Intermittent DNS Resolution Failure for Lorehaven Website
_Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look._ Going by your results, this sounds like your network’s default DNS server giving wrong answers, not a fault with the domain. Our article on this error describes it. Free subdomains can be filtered by some internet providers and networks, and their DNS servers answer “not found” for blocked domains. The article says we can’t see these blocks from our side. Reports from users are how we find out where they happen. Why does my browser say my domain can't be found? Domains and DNS > When you try to open your website, your browser says it can’t find the address. Depending on your browser, you will see an error like: This site can’t be reached Hmm. We’re having trouble finding that site. ERR_NAME_NOT_RESOLVED DNS_PROBE_FINISHED_NXDOMAIN This means your browser couldn’t look up which server your domain points to. Before your browser can connect to a website, it asks a DNS server to translate the domain name into an IP address. If that lookup fails, your browser doesn’t even… Your own tests fit that. Google DNS returns the right IP, your external checker got a 200, and only your default resolver fails. The Cloudflare timeouts are probably your network blocking outside DNS servers. The article says some networks do this, so it doesn’t point at Cloudflare or at our nameservers. Two things would settle it: 1. What does dnschecker.org show for `lorehaven.great-site.net` with record type A? If most locations show the IP, the domain works worldwide and the problem is on your network’s side. If some locations fail, that’s a different situation. 2. Which internet provider and country is the failing connection (your Windows PC and your Android phone on its default DNS)? The article asks for this so reports can be matched to a provider.
forum.infinityfree.com
October 25, 2026 at 3:17 PM
💯💪♥️🇵🇱👑😉
m.youtube.com/watch?v=7WoM...
GDY BRAKUJE SIŁ — Polski Rap o Wierze, Walce i Nadziei 2026 | 10 Utworów
YouTube video by LOREHAVEN
m.youtube.com
October 3, 2026 at 10:05 PM
@Nexus_526

📚 Lorehaven — proof of concept. Positivity-first fanfiction archive: trust levels, IPFS + ActivityPub federation, gamified quality, self-hosted.

Feedback and testers welcome.

#Lorehaven #FanFiction #SelfHosted #ActivityPub #Fediverse

https://x.com/i/web/status/2101665799756755390
September 29, 2026 at 4:39 PM
@Breeder592

📚 Lorehaven #fanfiction #archive

It's meant to be a thematic instance with gravity on the recommendation algorithm showing fics you'd enjoy with a bit of tension towards the theme. #DarkMC #LitRPG #Gamer #Celestial #CYOA #Progressio...

https://x.com/i/web/status/2103732050478223789
September 28, 2026 at 5:55 AM
📚 Lorehaven #fanfiction #archive

https://reddthat.com/post/73521584

It's meant to be a thematic instance with gravity on the recommendation algorithm showing fics you'd enjoy with a bit of tension towards the theme. #DarkMC #LitRPG #Gamer #Celestial #CYOA #ProgressionFantasy #DarkFics
September 26, 2026 at 6:23 AM
@Breeder592

📚 Lorehaven — proof of concept. Positivity-first fanfiction archive: trust levels, IPFS + ActivityPub federation, gamified quality, self-hosted.

Feedback and testers welcome.

#Lorehaven #FanFiction #SelfHosted #ActivityPub #Fediverse

https://x.com/i/web/status/2101937468488479008
September 22, 2026 at 7:06 AM
📚 Lorehaven — proof of concept. Positivity-first fanfiction archive: trust levels, IPFS + ActivityPub federation, gamified quality, self-hosted.

lorehaven.polarisocial.xyz

Feedback and testers welcome.

#Lorehaven #FanFiction #SelfHosted #ActivityPub #Fediverse
September 21, 2026 at 7:31 AM
@Breeder592

📚 Lorehaven — proof of concept. Positivity-first fanfiction archive: trust levels, IPFS + ActivityPub federation, gamified quality, self-hosted.

Feedback and testers welcome.

#Lorehaven #FanFiction #SelfHosted #ActivityPub #Fediverse

https://x.com/i/web/status/2101937468488479008
September 21, 2026 at 7:32 AM
📚 Lorehaven — proof of concept. Positivity-first fanfiction archive: trust levels, IPFS + ActivityPub federation, gamified quality, self-hosted.

lorehaven.polarisocial.xyz

Feedback and testers welcome.

#Lorehaven #FanFiction #SelfHosted #ActivityPub #Fediverse
September 20, 2026 at 1:32 PM