1

I have a web site hosted on a VPS that was working correctly until a few weeks ago. This domain is used primarily for email and that still works as it did previously. However, attempting to reach the web site from a browser now results in a page displaying "Index of /" as if there were no index.html file. There are files there, including the index.html file, but the page lists no files. However, the files can be seen and manipulated through FTP.

Since the site typically just redirects to another site, I was unaware of the problem until Let'sEncrypt attempted to renew the SSL certificate and now I get multiple emails each day detailing the errors Let'sEncrypt receives when trying to validate for SSL renewal on the web site.

Accessing my domain with http://example.com gives the above result. Trying http://example.com/index.html returns a 404 Not Found error.

The redirect has been removed with no change in results.

Checking the server's error log for this domain reveals 'script not found' errors, but they reference scripts not expected to be found and also 'AH02042: rejecting client initiated renegotiation' errors. (Might that be related to Let'sEncrypt's attempts to validate SSL?).

It's like the DNS now points to something other than the correct server, but all DNS records seem to be there and correct (A and AAAA pointing to the proper IP addresses). TXT records were added in the recent past for DMARC and DKIM. These were added to insure email sent from this domain would not be bounced back. Could they affect the web sites ability to serve pages?

What should I be looking for that might cause this situation? Is there any other data I could provide that would be helpful?

UPDATE:

Ran domain test at Zonemaster and although no errors, received the following warnings:

ADDRESS warning Nameserver ns1.dns-parking.com has an IP address (2400:cb00:2049:1::a29f:18c9) without PTR configured.

ADDRESS warning Nameserver ns2.dns-parking.com has an IP address (2400:cb00:2049:1::a29f:192a) without PTR configured.

CONNECTIVITY warning All authoritative nameservers have their IPv4 addresses in the same AS (13335).

CONNECTIVITY warning All authoritative nameservers have their IPv6 addresses in the same AS (13335).

CONNECTIVITY warning The following name server(s) are announced in the same IPv6 prefix (2400:cb00:2049::/48): "ns1.dns-parking.com/2400:cb00:2049:1::a29f:18c9; ns2.dns-parking.com/2400:cb00:2049:1::a29f:192a"

Also tests at dnsviz: Here are the errors:

wannabesports.com zone: The server(s) responded over TCP with a malformed response or with an invalid RCODE. (2400:cb00:2049:1::a29f:18c9)

wannabesports.com/AAAA: The response had an invalid RCODE (REFUSED). (162.159.24.201, UDP_-_EDNS0_4096_D_KN)

wannabesports.com/DNSKEY: The response had an invalid RCODE (REFUSED). (162.159.25.42, 2400:cb00:2049:1::a29f:18c9, UDP_-_EDNS0_512_D_KN)

wannabesports.com/MX: The response had an invalid RCODE (REFUSED). (162.159.24.201, 2400:cb00:2049:1::a29f:18c9, UDP_-EDNS0_4096_D_KN, UDP-_EDNS0_512_D_KN)

wannabesports.com/SOA: The response had an invalid RCODE (REFUSED). (162.159.24.201, UDP_-_EDNS0_4096_D_KN)

wannabesports.com/SOA: The response had an invalid RCODE (REFUSED). (2400:cb00:2049:1::a29f:18c9, TCP_-_EDNS0_4096_D_N)

Does the above indicate problems with the nameserver or incompatibility of some sort with settings between the site and the nameserver?

Improve this question
14
  • Anything change in the web server configuration that might point the document root to an unexpected directory?
    – Stephen Ostermiller ♦
    Commented Sep 7, 2023 at 15:55
  • Sounds like a problem with permissions since you say index.html exists however you can't access it.
    – Luis Alberto Barandiaran
    Commented Sep 7, 2023 at 16:59
  • Document root is still pointing to .../public_html which is the location of index.html.
    – jMyk17
    Commented Sep 7, 2023 at 20:51
  • 1
    If you install dig from bind, you can try commands like dig wannabesports.com and dig NS wannabesports.com and dig @ns1.dns-parking.com wannabesports.com and dig @ns2.dns-parking.com wannabesports.com to make sure that you DNS is set up properly. It all looks OK to me when I run those commands.
    – Stephen Ostermiller ♦
    Commented Sep 10, 2023 at 1:29
  • 1
    If you install curl you can run a command to force it to fetch from the correct IP address. Doing that will make sure that the web server is functioning as you expect from your location and confirm that there is some DNS issue. curl --resolve wannabesports.com:443:153.92.214.61 https://wannabesports.com/
    – Stephen Ostermiller ♦
    Commented Sep 10, 2023 at 1:30

1 Answer 1

Reset to default
1

I can offer little insight into the hows and whys but this problem was fixed by simply deleting the AAAA (ipv6) record from the DNS data. Thank you so much to Stephen Ostermiller for his extremely helpful advice which pointed to the action which ultimately solved the problem.

A brief description of the thought process. Following Stephen's advice to use the curl command noting the result could confirm a DNS problem, narrowed possibilities to DNS. Researching other questions at this site, led to using tracert and finding it returned what appeared to be ipv6 addresses (also received ipv6 addresses in many of the errors quoted above from dnsviz and zonemaster sites). Other, much older posts referenced problems with ipv6 in rare instances. So, the AAAA record of the DNS for this site was simply deleted. The result - problem fixed.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.