Piotr GRD

My guess would be that it's because of ns2 being intermittently unavailable. And if such temporary "downtime" happend at the time when DNS records for new added domains/subdomains are trying to be synchronised between two nameservers - the process fail. I may be wrong, of course. I can not be sure how exactly the process of synchronising the DNS records on both nameservers works. If I'm right - solution would be either makes the ns2 more stable or doing a full sync of zones from time to time. Second solution may consume too much resources, though, depends on the number of domains and subdomains hosted. As I wrote before, when there was only one (physically) nameserver - having physically two nameservers is much better for reliability, but process of synchronising them may be painful, depends how many DNS records are stored.

All the records on HelioHost nameservers are fine and - as you can see by yourself - both domains works properly. The error may be either because of your registrars server for some reason can not access HelioHost nameservers to check for the existence of the valid records on it OR because it's one of the registrars that fully accept only the "confirmed" in some way nameservers. OR maybe something else unknown for me. As long as the registrar does not block you from using these nameservers for your domain names and everything works you may simply ignore this error (I assume it's visible only for you after login at your registrar). I remember that in the past one of my registrars did accept only such "confirmed" nameservers, too, but all what I needed to do was add these nameservers to the registrars list, process was fully automatic, my personal "confirmation" that these nameservers are valid was enough. Of course it may be completely different at various registrars. EDIT: Oh! That's not really a domain registrar, but just a place where you can get free (sub)domains. In that case simply ignore this error, really, as long as everything works.

If the user was aware of the problem with all accounts displaying his/her content, if he/she knew that the webhost admin has created the "technical difficulties" page and he/she did replace it with ads on purpose - well, maybe, but even if then I would have doubts, that's not his/her fault that all accounts did display the same content, right?... If the user was not aware of the problem, if he/she didn't knew that the admin created the "technical difficulties" page (does the admin even tried to contact with that user and ask him/her to temporarily do not edit this page?...), if he/she simply worked on his/her website - I'll let myself to completely disagree with you.

I remember similar situation (unfortunatelly I can not find that topic about it) when all accounts did show content of one specific account, then one of the admins suspended it, so all accounts did show as suspended. Later djbob wrote that it wasn't that users fault, but some other error appear. jje, I'm not saying that this is the case, but don't you think it's possible that the user just worked on his/her website at the moment with not being aware at all that all accounts display his/her content for some reason?

Yes, after seeing the -> 8th August <- and -> 9th August <- when Johnny didn't work at all and the following days when Johnny did start working again we can be sure that: a ) Johnny does affect the whole physical server with main heliohost / helionet and ns2 on it; b ) sometimes (ie. 9th August, 3 times) there are some problems unrelated to the load made by Johnny.

They (Hurricane Electric) have a Twitter account where they posted: http://twitter.com/#!/henet/status/100203056502816769 From a quick search, ie. on webhostingtalk.com, I can see that they have problems with power outages every now and then. The other company that I know with the same frequent problems with power is BurstNET Technologies. After all such power failures there are often problems with not all servers booting up properly. Even if the power outage is short (by looking at my monitoring results I think it was something around 22 minutes or so, but I may be wrong) the server may boot up properly and instantly OR may need intervention of the technician in the datacenter. And the time depends on how many technicians are there, how many servers they have to handle with and how much other things to do they have, does they check all the servers by themselves or do anything only on a support request of the server owner. The last thing is the queue, what priority the specific server has. If what byron wrote is true, then obviously HelioHost servers will be far far at the end of the queue of things to do / servers to manually restart in such situations.

All you did is irrelevant. That's server-wide problem for all accounts on Stevie. This happend in the past, this happend 2 days ago for little less than 7 hours, this happend today, again. @ admins I have just spot it. The time of the day when it start to happend. Today - July 28th - it started ~08:08 UTC (~01:08 PDT). 2 days ago - July 26th - it started ~08:06 UTC (~01:06 PDT). 20 days ago - July 8th - it started ~08:08 UTC (~01:08 PDT). So I think it's worth to check it. Possibly it's unexpected and unwanted result of something that is scheduled for that time?...

It should work OK. I do monitor accessibility of the server with my pages, too, and I see no problems with it. I'm aware of the very short (1-2 seconds) temporary issues, though, that could happend from time to time, but it's rare. However if for someone, anyone, there will be some longer problems with accessibility to my pages - send me an email or a private message about it.

Everything should work properly even if you use external nameservers as long as you'll create a proper "A" or "CNAME" record for the selected subdomain on these nameservers. It can be either the "A" record pointed to the same IP as the records for your root domain and www subdomain or "CNAME" pointed to your root domain name or any other domain/subdomain that is pointed to the same IP on HelioHost. The choice is yours. I would choose more reliable nameservers. I don't know anything at all about reliability of Yola nameservers, but ns1.heliohost.org works well while ns2.heliohost.org not so well.

@ Krydos I think that you mean: PST in Winter and PDT in Summer (and not PST all the time) - and this is what I have set in a day after your post. @ Tjoene I don't really want to play with this. Currently 1px wide on the graph is one test done every 2 minutes, 720px represents 720 tests done within 24 hours. It looks good in 1024px resolution, but I am aware that it's little bit to small for bigger screen resolutions. However I don't really want to play with this. But you may try to use your browser in-build functionality. I'm not sure the other browsers, but modern versions of Firefox (3.0 and above) handle quite well the scaling of the websites content, so you can click CTRL + +(plus) on your keyboard to enlarge the content and CTRL + -(minus) to reduce the size, CTRL + 0(zero) to reset to default size.

All accounts on the server "Stevie" does not work for ~5 hours already (at the time of my post) and redirects to "account queued" page for main URLs (ie. stevie.heliohost.org/ ) and to 404 for all the other URLs (ie. stevie.heliohost.org/page.php). This happend from time to time, unfortunatelly. You may see that even frame with twitter events above the forum is "404" currently and you can check this section of the forums: http://www.helionet.org/index/index.php?showforum=81 for many the same looking posts. So check your account when this issue - global for all accounts on Stevie - will be fixed (again).

Changes: At 27th June 2011, Monday, the URL of the service has been change: http://grd.net.pl/heliohost/monitor/ => http://heliohost.grd.net.pl/monitor/ Update your links and bookmarks, please. Thank you. Since 2nd July 2011, Saturday, new functionality has been implemented. The graphs display now average server load for Stevie and Johnny servers. The look of it may change a little bit to improve readability if will be necessary. Thank you to the person that gave me an idea for this implementation (quite long time ago) and the second one that unintentionally hastened me little bit to finally do this. : ) Since 3rd July 2011, Sunday, I have added the second time line in different time zone. Apart of Coordinated Universal Time (UTC) the time is displayed now in EST in Winter and in EDT in Summer, which reflects to the time used in example in New York. I am, personally, in Europe, so it's not for me, but for convenience of users in America. If you think that for majority of users different time zone will be more useful and/or more convenient - please, suggest one. HelioHost Server Monitor

I don't know if that was only one, that's why I wrote that access to at least one of the Stevie's IPs - 216.218.192.170 (my test account on Stevie is on it) - was blocked, while access to 65.19.143.2 (main one for stevie.heliohost.org) was fine. I didn't check any other Stevie's IPs apart these two. I have checked from various locations, so it's not that just I was blocked. And that was very first time that I did notice such situation. It was for 2 or 3 hours only. At the time of my post it was already fine (aka. back to being intermittently slow, but accessible).

I don't know what you did, but for some time access to at least one of Stevie's IPs - 216.218.192.170 - was blocked (it didn't answer even for a ping) while access to 65.19.143.2 was fine. But I guess you may know this already. Back on the topic... I am not a hardware expert, but maybe network card or something else of this kind is broken and can not handle more than X connections or limits transfer speed which cause the slow responces while not generating server load. Pure guess work.

DNS issue has gone, so you're one step further. Redirection to "account queued" is another problem and with this one I am not able to diagnose why it could be. As to why you still did see that the page does not exist: remember about cache, either cache of your browser (temporary internet files) or DNS cache, which may sometimes cause that for some time you'll still see previous version even after changing something.

At the moment the DNS entries for wideaperture.heliohost.org are already present on HelioHost nameserver - while these were not couple of hours before. Similar problem was here and seems to be fixed, too: http://www.helionet.org/index/index.php?s=...ost&p=66623 So it looks that something has been done. (Maybe some kind of reset or whatever djbob done while testing Charlie's power usage was enough.)

At the moment the DNS entries for femaleonly.co.cc already are present on HelioHost nameserver. The same happend for mentioned in here http://www.helionet.org/index/index.php?s=...ost&p=66443 wideaperture.heliohost.org, so it looks that something has been done. (Maybe some kind of reset or whatever djbob done while testing Charlie's power usage was enough.)

femaleonly.co.cc does point to ns1/ns2.heliohost.org nameservers. But HelioHost nameservers does NOT have any records for femaleonly.co.cc, so the reason of problems seems to be really on HelioHost side. I can not check if the server does accept requests for femaleonly.co.cc at all (bypassing the DNS system) as Johnny is not accessible at all at the moment and still existsing on HelioHost nameservers records for femaleforum.eu suggest that Panos80's account is on Johnny. Tip for people trying to help in such cases: apart of "whois", using "dig" could be good idea, too. : ) PS. Similar situation with working account but with no DNS records created on HelioHost nameservers has been mentioned in here: http://www.helionet.org/index/index.php?s=...ost&p=66443

Quote: ...Resolved itself overnight.... This is what I wrote about having to wait for DNS changes, cached copies of them having to expire etc. As for the proper grammar part - I am not sure what you mean, as English is not my native language, I didn't even take any lessons of it, so I don't know at all if either your or my posts are correct or not in this matter (most probably my is not best and if so - sorry).

Quote: ... then I have to add 2 new NS records(ns01.heliohost.org, ns02heliohost.org) in my ns space from domain DNS settings and ... No. Currently you use the following nameservers: hndservers.earth.orderbox-dns.com hndservers.mars.orderbox-dns.com hndservers.mercury.orderbox-dns.com hndservers.venus.orderbox-dns.com Can you add any A/CNAME/MX/etc. records in there? If so, then just like you have created all the A and CNAME and MX records in there, create another "A" one for service.impaki.net that will point to the IP of your HelioHost account (found in cPanel). You don't have to use HelioHost nameservers at all. I, personally, don't even recommend it as recently HelioHost nameservers have low uptime (you can check my monitor, link in signature) which would make your subdomain being unavailable for visitors, even if the hosting server would be available. Of course on the HelioHost side you need to add service.impaki.net as the add-on or parked domain (unless it is set already as the main one).

Currently you use the following nameservers: dns1.registrar-servers.com dns2.registrar-servers.com dns3.registrar-servers.com dns4.registrar-servers.com dns5.registrar-servers.com And these nameservers points your domain name to 174.109.... IP where I see Drupal installation. Remember that DNS changes are not instant, especially if you change the authoritative nameservers for your domain. It's just most probably the cached copies of DNS records are working for you, your computer, your ISP etc. I didn't call your domain name ever before, I had no cached copies of your DNS entries anywhere on my computer or at my ISP, so I've just accessed the entries from original source. But you did call your domain when having it pointed to HelioHost and these cached entries are still working for you (on your computer, at your ISP etc.) and you have to wait until these cached entries will expire so you'll get them again from original source. After changing the nameservers you have to always remember that it may be even 24-48 hours before the changes will take a place on the whole world. Usually faster, but anyway, all cached copies of previous DNS entries have to expire everywhere before. So if you ever want to have instant switch between the hosts - keep the same nameservers and play around only with A records while having low TTL set for them. You can always check the crrectness of your DNS settings - even if not propagated everywhere, yet - with using "whois" and "dig".

@ djbob Data diged from heliohost nameserver: ;; QUESTION SECTION: ;ns1.heliohost.org. IN ANY;; ANSWER SECTION: ns1.heliohost.org. 14400 IN MX 0 ns1.heliohost.org. ns1.heliohost.org. 86400 IN SOA ns1.heliohost.org. ashoat.gmail.com. 2011062001 86400 7200 3600000 86400 ns1.heliohost.org. 86400 IN NS ns1.heliohost.org. ns1.heliohost.org. 86400 IN NS ns2.heliohost.org. ns1.heliohost.org. 14400 IN A 64.62.211.131 ;; ADDITIONAL SECTION: ns1.heliohost.org. 14400 IN A 64.62.211.131 ns2.heliohost.org. 14400 IN A 64.62.211.134 Just saying. Maybe it shouldn't, but it goes to .131. So I incorrectly diagnose the problem while not having previous correct records anywhere stored. The real issue is that the DNS record has been change for some reason. Result is that "ns1" is not accessible to the world.

There is no any A or CNAME record for wideaperture.heliohost.org so no any surprise that is not accessible for you or for anyone. If I'll "spoof" the DNS system, though, I see that it works (when Johnny works correctly at all, which is rare recently) and display the default portion of data. So I assume (I'm not an admin, I may be wrong) that the account has been created correctly except DNS entries not being set on nameserver.

In cPanel on your heliohost account check the "Shared IP Address" in the left column. Then you can create the "A" record for your subdomain that will point to that IP address and everything should work. If for some reason you can not or you don't want to create "A" record but only the "CNAME" then it can point to ANY hostname (domain/subdomain) that is pointed to that mentioned IP address (so for example you can use your heliohost.org subdomain if you did register account with it).

Short version: ns1.heliohost.org does not work for almost 24 hours already. Longer version: Technically there is only one nameserver on heliohost. But it's accessible through 4 IP addresses (maybe more, but these 4 I know for sure): 64.62.211.131 (as ns1.heliohost.org), 64.62.211.132, 64.62.211.133, 64.62.211.134 (as ns2.heliohost.org). It doesn't matter to which IP address you'll send the DNS request - the same nameserver installed on Cody will answer you. For every regular browser, though, ns1/.131 and ns2/.134 are the only "official" addresses. But for 24 hours already for some reason it does not respond for DNS queries when being asked through .131 / ns1 address. The same IP address is assigned to johnny.heliohost.org, so the problem may (or may not) be related to the latest longer problem with Johnny being inaccessible. This fact has no serious effect on websites being accessible or not, as ns2/.134 still does answer (when works at all) but something is definitelly wrong in there. More serious problem is that the nameserver (whole nameserver, accessible through both ns1 and ns2 addresses) is down so often (in other topic you said Cody has 95% uptime, which is low) as this has effect on theoretically more stable Stevie being so much inaccessible (if one use heliohost nameservers for domains hosted on it), too.