Re: [cobalt-users] RE: Advantage of Running DNS on RAQ4i

[Jeff Lasman <jblists@xxxxxxxxxxxxx>]

Brian Coughter wrote:

> There is a definite advantage to running your own DNS server on your RAQ.

There is, but you wouldn't know it from your reply... I'll explain
further inline...

> First of all, you should probably have at least a T1 line to host even a few
> sites.  There's no such thing as enough bandwidth.

I started hosting in 1994 on an ISDN line.  In June of this year I
bought an ISP that was hosting on a 128k Frame Relay line.  None of the
customers complained in either case.  The amount of bandwidth you need
depends on what you're hosting, and is certainly NOT an issue in this
particular post at all, so why did you bring it up to cloud the issue?

> Now, lets say you have an outside source providing you with DNS services
> that point to the IP address of your RAQ (this allows name resolution). The
> original request sent from a viewer in New York is sent to the DNS server
> (i.e. Joe Hosting in California) where it gets resolved, then the DNS server
> sends an IP address back to the viewer in New York.  From there, the
> viewer's browser requests the desired data from your RAQ in Virginia (or not
> - example only).  Your RAQ then sends the requested HTML page back to the
> Viewer's browser in New York.  Finally it's done.

Sorry, your example is just totally crazy.  If he's hosting in Virginia
(and there's no reason to host in any particular geographic location
unless the majority of the sites' hits will come from proximate
locations), then he'll probably get DNS from his provider.

What difference does it make if the DNS is returned from his provider's
system or his?

Even if bought DNS services from me (and yes, I'm in California), how
much more time would it take for the site visitor from New York to query
the DNS server in California vs the DNS server in (for example)
Virginia?

Considering that DNS uses only ONE packet in each direction, and the
answer is always in milliseconds, putting DNS on his (perhaps heavily
loaded) server might actually make DNS resolution take longer,
considering his server is busy thrashing it's hard-disk and using it's
memory serving up sites while our DNS servers in California are
specialized servers with tons of memory; all they do is server up those
single-packet DNS replies.

And what about the users in California, the users in Washington, the
users in Japan, the users in Australia... they'd get (only slightly,
measured in milliseconds) faster DNS from us than from his system in
Virginia.

> Do you see the huge path this DNS example is taking?  The longer the path
> the more time it takes to get the end result (the HTML page).  Therefore,
> running DNS on your server is a great idea.  By doing so, you cut out a big
> step in the DNS circle and things start to happen quicker.

What big step?  Do you think that if DNS and and the site are hosted on
the same machine you somehow cut out the (several millisecond) step of
sending the DNS back to the user's system?  That's not true at all.  The
round-trip still gets taken.

> Just be sure you know how to setup DNS.

At least on this we agree.

> This returns me to my first statement.  Run a T1 line minimum with a
> backbone provider such as UUNET (straight pipe - no frame clouds).

Whatever.  I won't even bother to point out that this has nothing to do
with the question (whoops; just did <wry grin>).

> The
> reason being is simply due to network latency.  A good line will help reduce
> troubleshooting issues in the future ­ take my word for it.

While this is reasonable information, it's not always possible, and it's
not germaine to the question at all.

> Need a reliable T1 or other data line?
> Call Doug Hargrove at UUNET
> (800) 488-6384 x64015
> dhargrove@xxxxxx
> Tell him I sent ya!

Oh, now I see.  You're spamming our list.

Jeff
-- 
Jeff Lasman <jblists@xxxxxxxxxxxxx>
nobaloney.net
P. O. Box 52672
Riverside, CA  92517
voice: (909) 787-8589  *  fax: (909) 782-0205