|dot us (.us) DNS error|
.us site will not open sometimes
Anyone knows if it's normal for .us domains to sometimes be inaccesible? I have many .com domains but the .us I have only works sometimes and other times it just says "domain dot found" or DNS error, just like the domain would not exist.
I am thinking that other worldwide dns servers that handle .us domains are not as stable as .com? (Otherwise my server has some issues)
Did you check your DNS configuration with a DNS checker?
I think we get away with posting this one. I've seen it here enough...
Note that .us domains will most often not have "glue records", necessitating an extra DNS lookup. This will happen, for example, if your DNS servers are in the .com TLD.
You can remedy this by using "vanity DNS" to give your DNS servers an alias in the .us TLD. Note that this will also cover the .biz TLD, as Neustar runs both .us and .biz from a common registry.
However, this is unlikely the problem, unless you have more general (probably client-side or ISP-related) DNS problems. If you are losing, say 25% of your DNS requests, then an extra DNS request will increase the possibility of failure significantly.
Whoa - I very seldom venture into this particular forum, because to say that I'm not a techie would be a vast understatement. But I'd stopped in today to ask if anyone knew what might be causing some aggravating connection problems on one of my sites - that's a .us site. I never would have thought of that having anything to do with the difficulties, so I about fell over when I saw the title of adrian's thread - especially the subtitle/description, because that's exactly what's happening with my site. It's not general: I and a couple of other site regulars have intermittent times of not being able to access the site. It may last an hour, or it may last a couple of days. It doesn't seem to be browser related; if it won't open in Firefox then it won't open in IE, and vice versa. One of the site regulars switched to a better ISP, and my ISP set up a different kind of connection for me, and both of those things helped but certainly didn't get rid of the problem.
I followed the link jtara gave, and a test of the problem site returned four "Fails" and six "Warnings." As I said, my technology knowledge is low, and I had no idea what to do with the information, so I emailed it to my webhost along with a description of the problems the site's been having. (FWIW, I have another .us site with the same host that works fine, but the problem site is larger and has been growing - the other one has basically been sitting there.)
The reply from my webhost said that the bad marks in the test results were related to the open DNS server set-up they use on their end, and that none of them would cause connection problems. But I have my doubts. Three of the things that showed up on the test results had to do with the amount of time allowed for a browser to "look up" a page or page content - my site was listed with only fractions of a second for each of these, while the recommended time was much longer. This would fit perfectly with what's happening - Firefox, for example, never gets out of the "looking up" stage when it won't connect, then goes to a "not found on server" error page. That would seem to be a reasonable response if it's not getting the time it needs to connect.
Sorry this is getting so long. A lot of the above is probably irrelevant. The website's a "one-person show" and this kind of thing is definitely my weak point (although I'm learning - like with a car, every time something goes wrong you learn something new).
Anyway, is it reasonable to suspect that the short "look-up" times might be contributing to the connection difficulties? Is that something I should ask my webhost about specifically? The only other advice their tech support was able to give me was to try a different browser (which doesn't seem to make a difference).
My webhost is one of the "inexpensive but reliable" companies - I've been with them for about six years and have never had a problem. But I'm wondering if it's time to switch the large-and-growing site to a webhost that costs more, and maybe uses a different server set-up.
Any comments/help would be greatly appreciated (and I'll try to return the favor in the copy writing/copyright forum). Thanks.
|Three of the things that showed up on the test results had to do with the amount of time allowed for a browser to "look up" a page or page content |
I don't think anything in that test suite has to do with the amount of time allowed for a browser to "look up" a page or page content. You are probably mis-interpreting.
You can post the specifics of the test here, as long as you substitute example.com for the domain name, and substitute "generic" IP addresses (use 126.96.36.199, etc. or better yet, 10.1.2.3 - anything starting with a 10. is a "private" IP address.) If you do so, it will be educational for everyone.
|The reply from my webhost said that the bad marks in the test results were related to the open DNS server set-up they use on their end, |
WHOA! Open DNS is a Bad Thing, and if this is really the case, you should run, not walk, to another host.
Please post the error and warning messages, and I can comment on whether it looks like they are really running an open DNS server.
I'm game. Given the anonymity of the web, I'm happy to act as an object lesson. If I'm too pitifully ignorant, I can always go hide somewhere. Here are the warnings and errors; errors were labeled as "fail" on the test site. Except for the last one, I've never heard of any of these until now:
|WARNING. Glue at parent nameservers: The parent servers (I checked with a.gtld.biz.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (10x.0.1.23), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain. |
|ERROR: Open DNS servers: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are: |
Server 10.2x4.56.x89 reports that it will do recursive lookups. [test] Server 10.2x6.54.789 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.
|ERROR: Missing (stealth) nameservers: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNSreport will not query these servers, so you need to be very careful that they are working properly. |
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example).
|ERROR: Missing nameservers 2: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: |
|WARNING: Nameservers on separate class C's: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location. |
|ERROR: Stealth NS record leakage: Your DNS servers leak stealth information in non-NS requests: |
Stealth nameservers are leaked [ns1.myhostmachines.com.]!
Stealth nameservers are leaked [ns2.myhostmachines.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.
|WARNING: SOA MNAME Check: Your SOA (Start of Authority) record states that your master (primary) name server is: ns1.myhostmachines.com.. However, that server is not listed at the parent servers as one of your NS records! This is legal, but you should be sure that you know what you are doing. |
|WARNING: SOA REFRESH value: Your SOA REFRESH interval is : 86400 seconds. This seems high. You should consider decreasing this value to about 3600-7200 seconds (or higher, if using DNS NOTIFY). 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), and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommend 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. |
|WARNING: SOA EXPIRE value: 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 suggests 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. |
I don't know if it makes any difference regarding the following, but I've never used my domain for email. I've always used a "normal" email address. This is the only one I've ever heard of, but I guess because I haven't use the domain for email I haven't worried about it:
|WARNING: SPF record: 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 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). |
That's it. The site says it performs 50+ tests, and the rest were okay. If there are any other results that tie into the lesson, let me know and I can post them.
jtara, thanks for any help you can give - from myself and anyone else who might learn something. The host I use was personally recommended to me by someone who knows a lot more about websites than I do, and I know she's recommended them to a lot of other people. As I said earlier, I've had two sites with them for about six years and haven't had any problems until now. I'm guessing that the larger site has reached a point where the seams are starting to show.
|WARNING. Glue at parent nameservers: |
"Normal" for a .us. Your nameservers are probably .com. You can get a slight DNS lookup improvement by using "vanity DNS" with nameservers in your own domain. (Or any other .us or .biz domain.) Some DNS providers have .us nameservers registered, and this will avoid this warning as well.
|(1) ERROR: Open DNS servers: |
Run, do not walk.... If your host doesn't understand why this is bad, the best way you can educate them is to go elsewhere.
|(2) ERROR: Missing (stealth |
You need to fix this one. You have nameservers listed in your DNS configuration that you failed to list at your registrar. Go into your registrar configuration, and make sure that ALL of your nameservers are listed.
|(3) ERROR: Missing nameservers 2: |
Just the opposite of the error above. You have nameservers listed at your registrar that you do NOT have in your DNS configuration.
Get your registrar nameservers and your DNS nameservers in agreement!
|(4) WARNING: Nameservers on separate class C's: |
You can probably ignore this. Do make sure you have at least two nameserver, and they are geographically diverse. No fair running two nameservers on the same physical hardware!
|(5) ERROR: Stealth NS record leakage: |
This is related to (2) and (3) above, and will go away when you fix them.
|(6) WARNING: SOA MNAME Check |
You need to fix this. Probably also related to (2) and (3).
|(7) WARNING: SOA REFRESH value: |
Follow the recommendation. Not a biggie, though.
|(8) WARNING: SOA EXPIRE value: |
Same as above. I'd follow the recommendation. It's troubling that your host is apparently using oddball default values.
If you do not use the domain for email, then it's best to have an SPF record that says that you do not use the domain for email. It will help to prevent others from "tainting" your domain by using a return address in your domain.
The following SPF record says that you don't use email on this domain:
Fix (2) and (3) at minimum. They are the reason a percentage of your DNS lookups fail.
jtara - Thank you!
I'm not going to ask any "how do I?" questions at the moment, as I want to see how much I can figure out on my own. Hopefully if I need more help it will be very specific.
I've learned a lot at WebmasterWorld, but this has been the most important. And I'll be adding "Website Technology Issues" to my list of regularly-read forums instead of letting it scare me off.