FTP troubles


#1

i’ve used FTP before on my friend’s domain, but i never encountered any problems like this.

i bought my domain the mourning of saturday october 6th. it’s now sunday october 7th afternoon. i received an email last night titled “DreamHost Account Approval Notification” that stated the FTP would be active “within the next 30 minutes”.

everytime i try to access my FTP it either says the page cannot be displayed or the server name of address could not be resolved. i also haven’t recieved the email that i was suppose to get after the services were activated with more details.

am i doing something wrong? if not, why is it taking so long? is it because it’s thanksgiving weekend (in canada)? i’m hoping to get my domain up before i go back to school but i can’t even seem to upload anything.


#2

this is a case where it would be a good idea to contact support if you haven’t already.

you should let them know the exact settings you’re using in your FTP program, and the exact error message you’re getting.


#3

yeah, i just heard it could take up to three days before that’s all done. ah well, i suppose it’s for the best. this way i might actually do some homework ^^;

thanks!
*Yohko


#4

This is a fairly common problem…

I’ve found that the secret is to do a workaround (where “example” is your domain name)…

  1. Use the DH contraol Panel to set up the custom domain for which you want to create a website: “example.com”; allow Dream Host to create a directory called example.com, where your HTML docs will live.

  2. Under the same username, use the Control Panel to set up a temporary dreamhost.com subdomain, “example.dreamhost.com” (or an alternate if that one’s taken); allow DH to create a directory called “example.dreamhost.com”.

  3. Begin Web development using the domain example.dreamhost.com, and its directory. All subdomains of dreamhost.com will resolve immediately, so FTP for example.dreamhost.com will be available right away.

  4. After a few days, when the name servers have propagated the name “example.com” (aka “www.example.com”), you can move the files from the directory example.dreamhost.com into the directory example.com, and start using example.com for FTP and www.example.com for looking at the site.

You can also use the webserver name for FTP; instead of example.dreamhost.com, you can use machinename.dreamhost.com (where “machinename” is the name of the web server, like “blanka”).

There are also some occasions when local DNS (/multihoming?) outages, when machinename.dreamhost.com will work for FTP while example.com won’t. I personally leave all of my FTP login paths pre-set to the form machinename.dreamhost.com.

Every time I set up a new domain, this is the way I start building the site, and it’s made things a lot smoother. The only possible drawback is that there will be an extra “logs” folder created for the temporary example.dreamhost.com domain, and it can’t be removed by the user (you and me). But if no more than the default 3 days’ worth of log files were being kept there, the files aren’t counted against your disk space, so it’s a really minor clutter issue. Since the log files are pretty out-of-the-way, it shouldn’t be a problem.

Have fun!

…Bob W.


#5

Just a point of accuracy - the DNS propagation has nothing to do with our location - it has to do with how long it takes for your information to reach the root DNS servers (and in the case of com. net. and org., the ‘gtld’ root servers).

Once it hits these machines, it’s possible that your ISP’s nameserver has already cached a negative response from the authoritive servers for com., net. or whatever. In this way, it can take a while for new information (or changes) to propagate to different ISPs. This doesn’t have to do with your geographic relationship to us, or anything we can control unfortunately.
As mentioned below, the best workaround is to create a blah.dreamhost.com subdomain to mirror the domain and / or to assign a unique IP address to the domain.

HTH.


#6

Will…

When I mentioned “local DNS (/multihoming?)”, I was referring to outages after propagation.

Sometimes DH’s local nameservers (or multihoming setup or whatever it is) goes out, making:

ftp://example.com

unreachable… while:

ftp://machinename.dreamhost.com/

…is still reachable.

That’s why I recommend using machinename.dreamhost.com for FTP.

There have only been three or so such outages that I’ve encountered since I’ve been here, but I figure there’s no reason to switch my FTP client’s prefs back and forth, since machinename.dreamhost.com will work either way…

I’m just lazy.

…Bob W.


#7

[quote]I went out on a limb, and assumed the domain was leased at DH (one
stop shopping). Therefore, it all starts and propagates from DH, and it
has more than nothing to do with your location.

[/quote]

I’m confused. Where the domain is registered has nothing to do with this (well domains registered through us hit the root servers earlier than domains registered through some other registrars, but it has absolutely nothing to do with location). The root DNS servers (as well as the root servers for the generic top level domains) are located all over the place. It is these nameservers that tell you how to find our nameservers, and if they don’t have this information, your site can’t be found.

for instance, here are the servers for com. (the most popular top level domain).

jazz% dig com. ns

; <<>> DiG 9.2.0rc5 <<>> com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54217
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;com. IN NS

;; ANSWER SECTION:
com. 428040 IN NS D.GTLD-SERVERS.NET.
com. 428040 IN NS E.GTLD-SERVERS.NET.
com. 428040 IN NS F.GTLD-SERVERS.NET.
com. 428040 IN NS G.GTLD-SERVERS.NET.
com. 428040 IN NS H.GTLD-SERVERS.NET.
com. 428040 IN NS I.GTLD-SERVERS.NET.
com. 428040 IN NS J.GTLD-SERVERS.NET.
com. 428040 IN NS K.GTLD-SERVERS.NET.
com. 428040 IN NS L.GTLD-SERVERS.NET.
com. 428040 IN NS M.GTLD-SERVERS.NET.
com. 428040 IN NS A.GTLD-SERVERS.NET.
com. 428040 IN NS B.GTLD-SERVERS.NET.
com. 428040 IN NS C.GTLD-SERVERS.NET.

OK so we have to look here to find a zone in com.

Here are the nameservers for dreamhost.com.

jazz% dig ns @b.gtld-servers.net dreamhost.com .

; <<>> DiG 9.2.0rc5 <<>> ns @b.gtld-servers.net dreamhost.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57111
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;dreamhost.com. IN NS

;; ANSWER SECTION:
dreamhost.com. 172800 IN NS NS2.NEWDREAM.NET.
dreamhost.com. 172800 IN NS NS.NEWDREAM.NET.

;; ADDITIONAL SECTION:
NS2.NEWDREAM.NET. 172800 IN A 216.240.131.131
NS.NEWDREAM.NET. 172800 IN A 207.155.127.155

Now let’s say we want to find the mail exchanger for dreamhost.com; we will check there.

jazz% dig dreamhost.com mx @ns.newdream.net

; <<>> DiG 9.2.0rc5 <<>> dreamhost.com mx @ns.newdream.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24960
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
;dreamhost.com. IN MX

;; ANSWER SECTION:
dreamhost.com. 7200 IN MX 0 gollum.dreamhost.com.
dreamhost.com. 7200 IN MX 0 dot.dreamhost.com.

;; AUTHORITY SECTION:
dreamhost.com. 7200 IN NS ns.newdream.net.
dreamhost.com. 7200 IN NS ns2.newdream.net.
dreamhost.com. 7200 IN NS ns3.newdream.net.

Now of course your computer’s resolver does this very quickly. Usually it consults your ISP’s nameserver, which makes the recursive queries. Since your ISP’s nameserver most likely gets a lot of queries for com. it only has to consult the root servers every 2 days or so (or when the time to live expires) to find out where to go for ‘com.’ domains. Similarly, if it’s cached a record for dreamhost.com, it doesn’t need to check with one of the GTLD servers.

So once a domain is registered, the nameserver records must go to the root servers (or the authoritative server for the top level domain; in many cases, the GTLD servers). cx. or edu. would have different servers.

[quote]When I mentioned “local DNS (/multihoming?)”, I was referring to
outages after propagation.

Sometimes DH’s local nameservers (or multihoming setup or whatever it
is) goes out
[/quote]

[…]

You’re losing me again.

What exactly do you mean? The servers for ‘blah.dreamhost.com’ are the same as the ones for ‘yourdomain.com’. Sometimes you may experience inconsistent performance for the first few days. This is normal and has nothing to do with outages on our side.

Any outages on our side would affect ‘blah.dreamhost.com’ as much as ‘yourdomain.com’.


#8

[/quote]

Uh… I didn’t say that.

Ardco (another Bob) did.

[quote]Sometimes DH’s local nameservers (or multihoming setup or whatever it
is) goes out
[/quote]

[…]

[/quote]

Now that I said.

[quote]You’re losing me again.

What exactly do you mean? The servers for ‘blah.dreamhost.com’ are the
same as the ones for ‘yourdomain.com’. Sometimes you may experience
inconsistent performance for the first few days. This is normal and has
nothing to do with outages on our side.

Any outages on our side would affect ‘blah.dreamhost.com’ as much as
yourdomain.com’.

[/quote]

Well, that’s not always the case in the real world…

There have been several times when – long after a domain has been set up and propagated – when ftp://example.com is not reachable, but ftp://machine.dreamhost.com (the machine that example.com lives on) is reachable. Same for Telnet and mail.

I have no technical explanation for it; I only have anecdotal evidence. I figured it had something to do with the way you multihome the machines and domains.

Hey… I’ll bet machine.dreamhost.com has an assigned IP number while example.com oftentimes doesn’t. That would mean that while IP-based NS was working, the multihoming scheme wasn’t.

Again, I don’t technically know how you do the multihoming thing, but that sounds to me like what happens during those outages.

…Bob W.


#9

…and some things are beyond DH control.

We’re working on that. World domination is slated for some time after toppling Microsoft and banning Britney Spears from distribution.

Suffice to say, this could make the time it took to get DH2 released look pretty quick by comparison.

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#10

[quote]Uh… I didn’t say that.

Ardco (another Bob) did.

[/quote]

first two wills and now two bobs. at least wil and i have different spellings :
sorry for getting my bobs mixed up.

all domains have an assigned IP address. the setup is exactly the same as for ‘machine.dreamhost.com’. reverse DNS may not work for most domains, but this isn’t really a concern as far as what we’re discussing here.
next time this happens, please let us know immediately. however barring any specific problems with the domain (ie lapsed registration, still within the period the DNS info is propagating, disabling / re-enabling a service, or possibly a service that’s being moved to a different machine) this is definitely not something that should be happening.

if your domain is moved, it’s possible that the old IP address would be unreachable, but it should almost always resolve to something, and should generally be reachable (if not the correct machine). generally we leave both services active during a move to a different machine or webserver.

if anything like this does happen to anyone, they should immediately contact support. if your OS has nslookup or ping, you can try to do an nslookup on your site or ping it, and let us know what IP address your computer is resolving the name to.


#11

[quote]We’re working on that. World domination is slated for some time
after toppling Microsoft and banning Britney Spears from distribution.

[/quote]

Hey!! Britney stays!


#12

[quote]

[quote]Uh… I didn’t say that.
[/quote]

[quote]Ardco (another Bob) did.
[/quote]

first two wills and now two bobs. at least wil and i have different
spellings

[/quote]

And thanks for that.

[quote]: sorry for getting my bobs mixed up.

[/quote]

'Sokay! A tip-- Ardco’s .sig is “Bob” while mine is “…Bob W.”

[quote]all domains have an assigned IP address.

[/quote]

'Scuse me? If all domains already have an assigned IP address, why would we have to pay extra if we want an IP address? Or are we talking about a static IP being the kind you have to pay extra for?

I’d guess that if a domain’s IP address isn’t static, then that provides an additional possible point of failure-- in whatever mechanism that dynamically assigns them… or in the process of moving domains and/or IPs whenever intermittent reallocation is needed.

[quote]this is
definitely not something that should be happening.

[/quote]

Yeah, I’d say that’s pretty accurate.

[quote]if your domain is moved, it’s possible that the old IP address would be
unreachable, but it should almost always resolve to something, and should
generally be reachable (if not the correct machine). generally we leave
both services active during a move to a different machine or webserver.

[/quote]

These have occurred, IIRC, at times when no changes were being made. Or at least there were no changes that users were told about. This is one reason why all changes need to be preceeded by an announcement.

BTW-- You guys were improving your communication for a while, but it’s slipped a little of late. More announcements are being made after a change is made (yes, pre-planned changes), and that doesn’t really do a lot of good. And less info is being given than was being given after I griped at you folks before. Start date, start time, estimated event length / estimated end date & time, specific machines involved… One or more of these are often being left out again.

Sorry for getting slightly OT, but I think you guys need to be periodically reminded of this stuff. (Just doing my job. )

[quote]if anything like this does happen to anyone, they should immediately
contact support. if your OS has nslookup or ping, you can try to do an
nslookup on your site or ping it, and let us know what IP address your
computer is resolving the name to.

[/quote]

On one occasion, I believe did contact support, but IIRC, by the time they responded, the problem was gone (a matter of an hour or two). And in a couple of the cases, I did do traceroutes, etc., but didn’t think the IP address was of interest, since my accounts supposedly don’t include an IP.

Next time it happens, I’ll send you the info.

Thanks…

…Bob W.


#13

'Scuse me? If all domains already have an assigned IP address,
why would we have to pay extra if we want an IP address? Or are
we talking about a static IP being the kind you have to pay extra for?

[/quote]

A unique IP is the kind you have to pay for.

[quote]I’d guess that if a domain’s IP address isn’t static, then that provides
an additional possible point of failure-- in whatever mechanism that
dynamically assigns them… or in the process of moving domains
and/or IPs whenever intermittent reallocation is needed.

[/quote]

Sort of. However not unique ! = dynamic. not unique in this case means just that your IP is shared. We do change or reassign these occasionally, but for the most part it’s not that your IP address will change, but simply that it’s not yours (ie http://123.123.123.123/ won’t lead to your site or resolve in reverse to your site’s name).
Similarly, unique ! = static. We don’t guarantee that a unique IP won’t change; simply that it is unique to your site.

Of course problems do crop up - I definitely wasn’t trying to suggest that they don’t - but they shouldn’t happen in most cases, and if they do happen, please try to provide us with as much info as possible so that we can try to figure out what’s going on.


#14

[quote]The bobs have different spellings too: Bob, and Bob W. I could use
Bob S., but then “bobs” could be confusing…

[/quote]

Yeah - I might have to think it was some sort of evil collaboration between the two of you… :>


#15

Will wrote:

[quote]Bob W. wrote:

[quote]'Scuse me? If all domains already have an assigned IP address,
why would we have to pay extra if we want an IP address? Or are
we talking about a static IP being the kind you have to pay extra for?
[/quote]

A unique IP is the kind you have to pay for.

[/quote]

But, you mean an IP that is unique AND static. Si?

I would think that if I pay for an IP, it would have to be static… Allowing reliable access even when NS is down.

Sort of. However not unique ! = dynamic. not unique in this case means
just that your IP is shared.

[/quote]

Exactly.

But you said “all domains have an assigned IP address”. That implies uniqueness/staticness. Thus the confusion.

And the “sharing” would be where the problem is. That’s the point at which the multihoming I was talking about takes place. Non?

In other words, at any given moment, one IP number could lead to several different domains, yes?

Or are you talking about “shared” in the sense that anyone might get any particular single IP within your netblock at any particular moment? In other words, does every single domain you host, at any given moment, have a separate, unique (but not necessarily static) IP?

If that’s the case, then – if I understand the concept correctly – it’s not exactly multihoming we’re talking about.

(Sorry that this may be getting OT for the Beginners’ Forum…)

…Bob W.


#16

Will shuddered:

[quote]Yeah - I might have to think it was some sort of evil
collaboration between the two of you… :>

[/quote]

MWAH-HAHahahahahahahaaaaaa!

Then again, you might think he was representing the a capella singing group known as “The Bobs”.

…Bob W.


#17

[quote]But, you mean an IP that is unique AND static. Si

[/quote]

no. we just guarantee that it’s unique. we try not to change them often but there is no guarantee that we won’t change it. this doesn’t mean that it’s dynamic (ie we’re not changing it every week or anything) but if we were to move you to a machine at a different location we’d have to change it (for example).

[quote]I would think that if I pay for an IP, it would have to be static… Allowing
reliable access even when NS is down.

[/quote]

well if our nameservers were down, a site with a unique IP would go down still unless you knew the IP address and typed it into your browser. while i do know a few IP addresses by heart (my home computer, my work computer, my mail server etc. etc.) i don’t as a general rule make a practice of remembering them…

[quote]But you said “all domains have an assigned IP address”. That implies
uniqueness/staticness. Thus the confusion

[/quote]

hrmm well that’s not how i meant it. the domains are assigned an IP address. however other domains are also assigned the same IP address.

[quote]And the “sharing” would be where the problem is. That’s the point at
which the multihoming I was talking about takes place. Non?

[/quote]

well i’m still not sure what you mean by ‘multihoning’. the sharing would not be where the problem was though.

[quote]In other words, at any given moment, one IP number could lead to
several different domains, yes?
Or are you talking about “shared” in the sense that anyone might get any
particular single IP within your netblock at any particular moment? In
other words, does every single domain you host, at any given moment,
have a separate, unique (but not necessarily static) IP?

[/quote]

no. most domains share an IP with a number of different domains, and this IP address doesn’t change often. this is not the cause for the problems you’re describing however.

each machine has about 20 or so webservers, and each webserver has a unique IP. each of these webservers has (i’m just guessing) 30 or so domains on it. this number could be more or less. so probably about 30 domains share one IP address.

if i type ‘ftp yourdomain.com’ or ‘ftp mydomain.com’ we can both ftp to the same IP address at the same time if these two domains share an IP address. Mail and web stuff are the only points where a translation must be made; however this is trivial (unless you’re using a really, really, really old browser that doesn’t support name based virtual hosting).

i hope that makes sense sort of… it’s difficult to explain.


#18

[quote]Enough already. Thanks for the demonstration. You’re confused! Did I
change channels? I thought this was the beginner’s forum

[/quote]

sorry… i was trying to illustrate a point. the DNS isn’t actually that complex but it’s a bit hard to explain. i will try to explain in a more understandable manner at some later point (and not in the beginners’ forum) :stuck_out_tongue:

[quote]It starts with submitting a request into a web form/server in California. It
eventually propagates to the rest of the world… I don’t think that conflicts
with anything you’re saying, except you just don’t like the geographical
reference to California, I guess, but that is where the DH server that
accepts the request is located, isn’t it?!

[/quote]

that’s technically true but it’s irrelevant. we register domains through opensrs, which is a company based in canada, so we send the information to them. they, in turn, update (probably hourly or daily) the root DNS servers with the nameserver information (which is the information that needs to ‘propagate’). So this hits the various root servers which are located around the world in various locations (mostly in the US but not completely). From here, it can take a variable amount of time for this to hit peoples’ isps. While geography may play a factor in when an individual person is able to view your site, there are many other factors, some of which are probably more important (the way this individual’s isp’s nameservers are configured for instance).

So geography plays a role, but not the only role. I guess imagine roots spreading out from many trees rather than roots spreading out from one central tree.

The information you received was probably based on a somewhat limited understanding of the principles behind this (god i hope i didn’t write that one) and also is designed to explain the process in fairly simple terms. I’ll admit i’ve probably explained this in a similar manner at some time - it’s one of the most common questions support gets and it’s difficult to acquire an understanding of the way DNS information propagates.

Generally if a domain is taking an extra long time to propagate for someone, it’s due to the way their ISP’s DNS servers are setup, and to pure chance. The DNS relies on caching extensively, so sometimes a wrong or negative answer can be cached for a long time

I hope i’m making myself a little clear. I’m not trying to be deliberately stubborn here; it’s not really an issue of great import. I was just trying to clarify a nit-picky little point.


#19

Hi, Will…

You wrote:

[quote]Bob wrote:

[quote]But, you mean an IP that is unique AND static. Si
[/quote]

no. we just guarantee that it’s unique. we try not to change them often
but there is no guarantee that we won’t change it. this doesn’t mean that
it’s dynamic (ie we’re not changing it every week or anything) but if we
were to move you to a machine at a different location we’d have to change
it (for example).

[/quote]

Gotcha… But I don’t recall seeing that at other hosts. Generally, when you pay for an IP number, you pay for a static one. If moves are made, the number moves with you. Machine moves are usually within the same data center, so it’s usually not a problem.

well if our nameservers were down, a site with a unique IP would go down
still unless you knew the IP address and typed it into your browser.

[/quote]

And that’s exactly what I do…

[quote]while
i do know a few IP addresses by heart (my home computer, my work computer,
my mail server etc. etc.) i don’t as a general rule make a practice of
remembering them…

[/quote]

Me neither. That’s why I tend to write them down.

I have seen DNS problems (Net-wide and more local to another host) last for a day or more, during which I was able to continue working on a website under development by using the IP number. If I hadn’t had a static IP number (at least static for that period of time), I would have lost those days of development time.

Naturally, the public generally won’t know the IP number of a certain site, but if you’re working on a site, or others you work with need access when DNS is down, that number is important.

uniqueness/staticness. Thus the confusion

hrmm well that’s not how i meant it. the domains are assigned an IP
address. however other domains are also assigned the same IP address.

[/quote]

That’s clear now. Thanks.

the multihoming I was talking about takes place. Non?

well i’m still not sure what you mean by ‘multihoning’. the sharing would
not be where the problem was though.

[/quote]

[quote]no. most domains share an IP with a number of different domains, and this
IP address doesn’t change often. this is not the cause for the problems
you’re describing however.

each machine has about 20 or so webservers, and each webserver has a
unique IP. each of these webservers has (i’m just guessing) 30 or so
domains on it. this number could be more or less. so probably about 30
domains share one IP address.

[/quote]

And that’s what is called “multihoming”, IIRC (the admins may call it something else, but from what I understand, that’s what it’s called). Multihoming is when single IP number serves more than one machine, or more than one domain on a machine.

And… Yes, from what I can see, this would have to be where the problem lies.

Once you get past the DNS stage, and past the IP stage, you’re into multihoming. If the server is reachable by IP number and by regular DNS using machinename.dreamhost.com, but isn’t reachable via example.com, the only stage that’s left is the multihoming setup. That’s the stage – the “name-based hosting” stage – at which requests coming into a single IP, but for different domain names, are guided to the proper machines and/or directories for those domains.

[quote]if i type ‘ftp yourdomain.com’ or ‘ftp mydomain.com’ we can both ftp to
the same IP address at the same time if these two domains share an IP
address. Mail and web stuff are the only points where a translation must
be made; however this is trivial (unless you’re using a really, really,
really old browser that doesn’t support name based virtual hosting).

i hope that makes sense sort of… it’s difficult to explain.

[/quote]

No, you’ve explained it clearly this time.

But I do believe you’re mistaken about multihoming not being the problem. As far as I can tell, it’s the only possible point of failure. Whether it’s a hardware problem, an NFS problem, or whatever, it’s ocurring during the multihoming stage.

What else could it be, given the symptoms?

(BTW-- Let me know if you want to take this conversation to another forum…)

…Bob W.


#20

[quote]But I do believe you’re mistaken about multihoming not being the
problem. As far as I can tell, it’s the only possible point of failure.

[/quote]

How so? it’s not something that can really ‘break’. It can be misconfigured like anything else, of course, but it doesn’t really ‘break’. It’s possible that the DNS information for your site might be outdated, and you might be directed to the wrong machine or webserver, but that is possible regardless of whether or not the domain is on a static IP or not.

[quote]If the server is reachable by IP number and by regular DNS using
machinename.dreamhost.com, but isn’t reachable via example.com,
the only stage that’s left is the multihoming setup.
[/quote]

Not exactly. What if the DNS is screwed up for example.com? I have never seen a scenario like the one you’ve described where there wasn’t a DNS problem. The ‘multihoming’ ONLY has to do with web stuff and the reception of mail. For instance:

aura% host robfrank.com
robfrank.com has address 216.240.131.171

aura% host 216.240.131.171
171.131.240.216.in-addr.arpa domain name pointer basic-booger.slappy.dreamhost.com.

there are any number of other dreamhost sites on this IP. However if I connect to this IP, it’s always going to connect me to the machine that robfrank.com is on (although it’s not the machines’ main IP address). If I were moved to another machine, going to ‘robfrank.com’ would take me to one or the other (depending on how quickly the change propagates to my ISP). In fact it might take me to one, and then the other. It might resolve soulrebels.com and www.soulrebels.com differently for a day or two. But you would always be able to connect to one machine or another unless the DNS for the domain was messed up – and this is taking into consideration the infrequent event of the domain being moved to a different machine.
Further, we generally keep the site running on both machines or webservers during a move (note by webserver I don’t mean machine - we have about 20 or 30 webservers running on each machine).

So while I’m not doubting the situations you describe, I am doubting the reasons you’re suggesting. Obviously I can’t prove this since these situations are long past…

I believe people generally refer to hosting more than one domain on an IP address ‘virtual hosting’ (you lump hosting different sites on one machine with multiple IP addresses in with this, although i wouldn’t really, since it’s a 1:1 ratio of machine to IP address).

In any event, FTP, telnet, POP, IMAP and outgoing SMTP (in our specifc case anyway) are completely and totally not related to the ‘multihoning’ process. Your computer may resolve a name to an incorrect or outdated value, but the translation takes place before it reaches our machine.

For instance, if I say:
aura% ftp robfrank.com

my computer does the lookup for 'robfrank.com
and then connects to this address:

Connected to robfrank.com.
220 ProFTPD 1.2.0pre10 Server (DreamHost FTP) [slappy.dreamhost.com]
Name (robfrank.com:william):
the FTP server doesn’t check to see what name I requested since it doesn’t care. So if the DNS server(s) that my computer uses to resolve hostnames into IP addresses had an outdated or incorrect value, then I would connect to the wrong place.