PDA

View Full Version : A Lesson In Website Management!!




JordanL
11-28-2007, 09:04 AM
Alright. It seems that MANY here don't seem to know the basics of website management, and it's really starting to bite us in the ass. Looking at TeaParty07.com for instance, the domain quit resolving this morning... a great time for that to happen considering that the debates are coming on later.

So, people don't seem to understand how these things work, and as a consequence, we have problems like this happening, which should not be happening. First, here's a basic breakdown of how domains work, and why they do and don't resolve.

When you type an address into your browser, it gets sent with a request to your Internet Service Provider. (That might be Comcast, AOL, MSN, etc.) All of the ISPs have giant servers which have nothing on them but a giant list which matches domain names to computer friendly server addresses. (IP Addresses, just like the ones your computer gets when it's online.)

Now when you register a domain, this address goes out immediately to a group of servers known as the root DNS servers. These servers aren't owned by any company or ISP. Instead they are managed by a pseudo-governmental agency known as ICANN (Internet Corporation for Assigned Names and Numbers).

Now there are only 26 root DNS servers, and to put it bluntly, the internet would grind to a halt if every time a person wanted to visit a website they asked one of the root DNS servers. This is why all of the ISPs keep their own servers which handle this task then update their servers every 12 - 48 hours so that it's inline with the root DNS servers.

This is also why different people in different places are able to see a website at different times.

Now, anytime you make a change which needs to be stored in the root DNS servers, that change takes the same 12 - 48 hours to propagate. There are however changes which take effect immediately, and they have to do with where the change occurs.

Basically, most hosting companies keep their own "control" server at the front of their network as a kind of traffic director, so that when they submit the domain info to ICANN, it basically says, "oh, teaparty07.com? Yeah, talk to GoDaddy about that" and sends the users browser happily along to GoDaddy.

There the traffic control server looks at the request and more or less responds with "yeah, I keep that information on the server to your left". This is useful because if you want to change servers but don't want to switch off of GoDaddy, then you simply tell the traffic control server "hey, we moved that information to the server on the right", and instantly anyone coming in the door will know to go to the right.

With the teaparty07 website, it appears that they wanted to switch off of GoDaddy's hosting, which is overall a good move. The problem is that for the next two days, some people will be sent to the new location, and some will be sent to the old.

The only way to make THAT process painless is if for those two days, you host it at BOTH locations identically, then turn the GoDaddy version off after the switchover is complete.


Please, everyone out there, when you are making a website that others will depend on, make sure that you have someone helping you that is intricately familiar with these types of problems. I don't know if this is what happened with the teaparty website, but it seems likely.

I don't expect everyone to know how to run a professional and well thought website. But I do expect people to ask for help when they don't. This is more of a cautionary tale than one of reprimand, so don't go chastizing Trevor. It's just a good opportunity to illustrate how things can very easily go wrong when you aren't aware of the situation.

If this is what happened here, the single point of failure would be turning the GoDaddy site off before the new site was turned on. (Then again, it could be a tick of the actual GoDaddy hosting service and not a switchover, which would do a very good job of illustrating why you DON'T want to use budget hosts.)

TechnoGuyRob
11-28-2007, 09:07 AM
Error, error. TeaParty07.com does not resolve. No ping. No DNS resolution.

Looks like you're wrong; otherwise, it could at least find a server.

JordanL
11-28-2007, 09:10 AM
Error, error. TeaParty07.com does not resolve. No ping. No DNS resolution.

Looks like you're wrong; otherwise, it could at least find a server.

No, that's the point. if you update the DNS information with a NEW location for the server, and terminate the old one, than the old one doesn't exist any more, and that's the one all the ISPs have. So for the next 12-48 hours, they are sent to a location that doesn't exist any more.

me3
11-28-2007, 09:10 AM
The first post is somewhat accurate. I normally lower the TTL (time to live) for the record a day in advance, and then when I make the move, the local ISPs recache the DNS much quicker.

I have made many moves, in less than 2 hours for 90% propagation.

12~ 48 hours is just an approximation. Every ISP is run differently.

It seems pretty clear, DNS is BROKEN for teaparty07 right now. It's not an ISP cache or propagation delay problem.

JordanL
11-28-2007, 09:11 AM
The first post is somewhat accurate. I normally lower the TTL (time to live) for the record a day in advance, and then when I make the move, the local ISPs recache the DNS much quicker.

I have made many moves, in less than 2 hours for 90% propagation.

12~ 48 hours is just an approximation. Every ISP is run differently.

It seems pretty clear, DNS is BROKEN for teaparty07 right now. It's not an ISP cache or propagation delay problem.

That's awfully strange... there's not many other points of failure in an HTTP request.

TechnoGuyRob
11-28-2007, 09:12 AM
No, that's the point. if you update the DNS information with a NEW location for the server, and terminate the old one, than the old one doesn't exist any more, and that's the one all the ISPs have. So for the next 12-48 hours, they are sent to a location that doesn't exist any more.

True, but I doubt GoDaddy shuts off a server when they stop hosting one of the sites that server handles. :p

ConstitutionGal
11-28-2007, 09:14 AM
That's a very nice synopsis of DNS propagation, however, from what I read on here yesterday, there's some issue with GoDaddy, not with a DNS move. I don't mess with GoDadday but I'm wondering if they're one of those hosting companies that will shut down your site if you go over xx amount of bandwidth usage unless you're set up for automatic debiting for payment.

me3
11-28-2007, 09:16 AM
I don't mess with GoDadday but I'm wondering if they're one of those hosting companies that will shut down your site if you go over xx amount of bandwidth usage unless you're set up for automatic debiting for payment.
They either post a bandwidth exceeded message, and/or notify by email.

There are errors in the DNS entries. That would have nothing to do with an overage. The domain name is clearly not properly BOUND to the server.

JordanL
11-28-2007, 09:16 AM
True, but I doubt GoDaddy shuts off a server when they stop hosting one of the sites that server handles. :p

Ah... yeah...

Well, as I was more teaching a lesson than chiding a mistake, the point of the thread stands. ;)

It would seem that this is more due to GoDaddy basically throwing away requests for sites that have been shut off instead of responding with an error code.

me3
11-28-2007, 09:18 AM
Ah... yeah...

Well, as I was more teaching a lesson than chiding a mistake, the point of the thread stands. ;)

It would seem that this is more due to GoDaddy basically throwing away requests for sites that have been shut off instead of responding with an error code.
Actually, GoDaddy should have forwarded the DNS to the new server within their network from the existing name servers.

Old nameserver => points to => new name server
New name server => properly bound.

That way old and new cached entries get forwarded. Hosts can do this within their own network, it is just difficult to get different hosts (when you change providers) to forward DNS. They don't usually like to work together.

ConstitutionGal
11-28-2007, 09:20 AM
They either post a bandwidth exceeded message, and/or notify by email.

There are errors in the DNS entries. That would have nothing to do with an overage. The domain name is clearly not properly BOUND to the server.

In that case, my first statement stands.

Has anyone heard anything from Trevor about this yet? Someone said yesterday that they had offered to get in the middle of this with GoDaddy but that Trevor had his business accounts there and couldn't risk giving out the account info to someone else so they could try and help find out what the problem was.

me3
11-28-2007, 09:21 AM
I believe he is working on it.

JordanL
11-28-2007, 09:22 AM
Actually, GoDaddy should have forwarded the DNS to the new server within their network from the existing name servers.

Old nameserver => points to => new name server
New name server => properly bound.

That way old and new cached entries get forwarded. Hosts can do this within their own network, it is just difficult to get different hosts (when you change providers) to forward DNS. They don't usually like to work together.

Again, the point stands that this is why you don't use a budget host with a time critical application. ;)

But yes, this one sounds like it's GoDaddy's fault.

voytechs
11-28-2007, 09:22 AM
One thing that can be done short term is to ask GoDaddy to redirect the teaparty07.com to the correct IP address manually in the time it takes all the servers to propagate to the new IP address.

This is something that GoDaddy should be able to do very quickly on their side.

voytechs
11-28-2007, 09:24 AM
They either post a bandwidth exceeded message, and/or notify by email.

There are errors in the DNS entries. That would have nothing to do with an overage. The domain name is clearly not properly BOUND to the server.

My Timewarner DNS server doesn't know about teaparty07.com:


> teaparty07.com
Server: dns-cac-lb-0.nyroc.rr.com
Address: 24.92.226.9

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to dns-cac-lb-0.nyroc.rr.com timed-out

me3
11-28-2007, 09:24 AM
Again, the point stands that this is why you don't use a budget host with a time critical application. ;)
GoDaddy is not a budget host. They are on the expensive side. Budget hosts don't offer telephone support.

voytechs
11-28-2007, 09:29 AM
GoDaddy is still holding on to the old address while some other DNS servers have already propagated like the cnet.com DNS servers:



> set srchlist=godaddy.com
> teaparty07.com
Server: dns-cac-lb-0.nyroc.rr.c
Address: 24.92.226.9

Non-authoritative answer:
Name: teaparty07.com.godaddy.
Address: 208.109.132.201

> set srchlist=com.
> teaparty07.com
Server: dns-cac-lb-0.nyroc.rr.c
Address: 24.92.226.9

Non-authoritative answer:
Name: c13-ss-2-lb.cnet.com
Address: 216.239.116.65
Aliases: teaparty07.com.com

>


I think the biggest problem right now is that RoadRunner servers haven't synced up yet and they are the ones used by majority of the users out there. Almost eveyone uses road-runner now a days, no matter who their cable or DSL provider is.

JordanL
11-28-2007, 09:30 AM
GoDaddy is not a budget host. They are on the expensive side. Budget hosts don't offer telephone support.

I suppose you're right... I've worked in several different IT departments... I'm used to SANs, fully managed DMZs and multiple failovers.

evadmurd
11-28-2007, 09:32 AM
It's a vast neo-con conspiracy.