Hello WHT Memebers.
There was a serious problem. My website went completely down for 12+ hours, and after coming back up on the Internet, it has reverted to an old version from 11.11.2004 (exact date when I left the previous host and joined Surfspeedy).
I have submitted supprot tickets to Surfspeedy which have been answerd. In a nut shell, this is the response:
= = = Original message = = =
Medicalassistant.net
Hi there,
We just had a dns problem issue yesterday, thus, we just received an update from our senior admins and the dns is already working however, under your server, its not yet fully propagated. This was the first time it happens, with this, we already made precautionary measures and we do promise that it wont happen again. Do not be worried because none of your files were deleted of some sort. Thank you. Best regards, Damien Surfspeedy support
Best regards,
Damien
Surf Speedy Support Team
Below is what concerns me and makes me nervous. If people here at WHT would read the following warnings, and give me their thoughts and feedback on them, with focus on whether I should stay with Surfspeedy and ask them to work this out, or switch hosts in a hurry, I would greatly appreciate it:
DNS REPORT:
http://www.dnsreport.com/tools/dnsre...lassistant.net
1. WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).
2. ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame: 207.44.204.43
3. Your DNS servers leak stealth information in non-NS requests:
Stealth nameservers are leaked [ns14.surfspeedy.com.]!
Stealth nameservers are leaked [ns13.surfspeedy.com.]!
This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries.
4. WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: ns13.surfspeedy.com.. However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.
5. WARNING: Your SOA REFRESH interval is : 14400 seconds. This seems a bit high. You should consider decreasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours, with the longer time periods used for very slow Internet connections; 12 hours seems very high to us), although some registrars may limit you to 10000 seconds or higher, and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommends 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.
6. WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 recommends 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver.
7. WARNING: You only have 1 MX record. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you.
8. WARNING: One or more of your mailservers may be claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). This probably won't cause any harm, but may be a technical violation of RFC821 4.3 (and RFC2821 4.3.1). medicalassistant.net claims to be host s3.myhostcenter.com.
9. ERROR: One or more of your mailservers does not accept mail to
postmaster@medicalassistant.net. Mailservers are required (RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1) to accept mail to postmaster.
medicalassistant.net's postmaster response: >>> RCPT TO:<postmaster@medicalassistant.net> <<< 550-"The recipient cannot be verified. Please check all recipients of this 550 message to verify they are valid."
10. WARNING: One or more of your mailservers does not accept mail to
abuse@medicalassistant.net. Mailservers are expected by RFC2142 to accept mail to abuse.
medicalassistant.net's abuse response:
>>> RCPT TO:<abuse@medicalassistant.net>
<<< 550-"The recipient cannot be verified. Please check all recipients of this
550 message to verify they are valid."
11. WARNING: One or more of your mailservers does not accept mail in the domain literal format (user@[0.0.0.0]). Mailservers are technically required RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses. Not accepting domain literals can make it more difficult to test your mailserver, and can prevent you from receiving E-mail from people reporting problems with your mailserver. However, it is unlikely that any problems will occur if the domain literals are not accepted.
medicalassistant.net's postmaster@[67.19.37.4] response:
>>> RCPT TO:<postmaster@[67.19.37.4]>
<<< 501 : domain literals not allowed
12. Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record <
http://spf.pobox.com> ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).
Thanks!
Danni
Linear Mode
