[OT] Re: [plug] redirecting url's

[James Devenish]

In message <1045984684.2172.7.camel at spockster> on Sun, Feb 23, 2003 at
03:18:04PM +0800, Darren wrote:
> how would i achieve your last suggestion ,using dyndns.org to
> webforward i only have the option to forward to an ip address ,at the
> isp the page is it  wn.com.au/xxx which i gather dosnt have its own
> ip. i have been reading and searching but i cant grasp the concept
> .thanks for the help  

Background info:

(1) DNS maps names and addresses. The two commonplace "forward" lookups
for websites are canonical name resolution (from a host's "alias" to its
real name) and address resolution (from a host's "name" to IP address).

An example of CNAME-record resolution followed by A-record resolution:
 www.ucs.uwa.edu.au is an alias for mysource-lha.uwa.edu.au.
 mysource-lha.uwa.edu.au has address 130.95.128.55
Conversely, in this case:
 55.128.95.130.in-addr.arpa domain name pointer mysource-lha.uwa.edu.au.

In some cases, the start of a zone (e.g. wn.com.au) may have an address,
too. For example, the host name www.wn.com.au has the address
203.10.1.20 and wn.com.au does, too. Comparatively, uwa.edu.au has
address 130.95.128.50 which is not the same as www.uwa.edu.au.
(And that is why I have chosen it as an example.)

(2) When you want to access a web site, you need to specify a particular
host and a particular web address. If you want
<http://www.uwa.edu.au/about/>, your computer fetches information about
the address of www.uwa.edu.au, then contacts the host at the address
belonging to mysource-lha.uwa.edu.au, then requests the resource
named /about/ for the site www.uwa.edu.au. Notice that there is some
separation and even independence of those activities.

(3) Web servers often support a "virtual host" mechanism. I have just
described that the host 130.95.128.55 is called mysource-lha and that is
serves resources for www.uwa.edu.au. Well, it also serves resources for
www.ucs.uwa.edu.au. So if you request <http://www.ucs.uwa.edu.au/web>,
your computer fetches information about the address of
www.ucs.uwa.edu.au, then contacts the host at the address belonging to
mysource-lha.uwa.edu.au, then requests the resource named /web for the
site www.ucs.uwa.edu.au. This work because of the virtual host
mechanism:

For both of the those websites (www.uwa.edu.au and www.ucs.uwa.edu.au)
the same IP address, was contacted in each case and that the name of the
host at that address is mysource-lha (not www). In order to make this
work, the site name was sent in your web browser's request and this was
done AFTER a connection had been established with mysource-lha's IP
address.

(4) DynDNS provides some sort of service which makes uses of the above
mechanisms but may also include config interfaces and web page tricks
using DynDNS's own product terminology. This is a bit confusing because
I am not familar enough with DynDNS to know how things are being
presented to you and how these relate to what is actually going on.

Okay, that's the background information from my side. However, I am
lacking some information about your side (which is why I did not attempt
to give more details earlier). What we need to know is whether the scope
of this exercise is the whole of your.name.dyndns.org or whether it is
limited to a few pages nested within that site. I am going to assume the
former because I imagine the solution to the latter would be obvious and
would simply follow on from your pre-existing forum arrangements.

So, continuing...

Here's what I imagine would happen if we forget about having a backup
server or redirects:

 - you use DynDNS to host your domain name information,
 - when people go to look at your site, they enter your web address
   and name->address resolution occurs,
 - people's computers connect to your Linux box and request a
   particular resource at your website.

Now, what happens if your Linux box disappears from the net? Attempts to
connect to your website will experience successful name->address
resolution (assuming DynDNS is alive) but will fail during the
subsequent step of actually attempting to connect to the address of your
Linux box.

To get around this problem, you either need to alter the domain name
resolution so that your website's address resolves to something other
than your Linux box's address OR set up something else at your Linux
box's address. Since the latter is probably not all that useful, you may
need to do the former.

So then, if your website's address is going to resolve to something other
than your Linux box's address, what address will that be? If you choose
www.wn.com.au then people trying to access your website will connect to
www.wn.com.au and then request the website your.name.dyndns.org. What
will happen then? If you have not made arrangements with WN, then people
will get WN's website even though they are using your web address. If
you want them to get a message saying that you site is down, you need to
have WN configure the virtual host support on their web server. Then,
people will connect to www.wn.com.au and when they request
your.name/blah they will immediately get the contents of wn.com.au/xxx!

So, how might this work in practice? Well, it depends on what WN will
let you do. For example, a fairly straightforward method might be this:

 - set up your dyndns to point to WN's server.
 - arrange for WN to host your dyndns domain name as a virtual host.
 - set up your website at WN to connect/proxy to your Linux box (behind
   the scenes) and serve pages from there.
 - set up an error page at WN so that if the proxy attempt fails, a
   helpful error message is displayed.

Now what happens:

 - every time someone looks at your website, they connect to WN's
   servers which in turn connect to your website and return the result
   to the user. The user isn't aware of this behind-the-scenes trickery.
 - if WN's servers cannot connect to your website, the error message
   is displayed.

A different way of going about it would be:

 - set up dyndns to point to your Linux box,
 - arrange the virtual hosting with WN anway,
 - when your box becomes unavailable, change the dyndns to point to WN,
 - when your box becomes available, change the dyndns to point to you.

The obvious problem with this is that if your Linux box in unreachable,
you may not have net access and therefore be unable to configure things
with DynDNS. I do not know enough about your arrangements to know what
to tell you.

Note that there are many industrial-strength ways to going about these
sorts of things but the above example should be possible with just a
few lines of Apache .htaccess configuration.

One last thing: why did I bring up UWA's website as an example? Well,
remember that uwa.edu.au resolves to a different address from
www.uwa.edu.au? So what happens when people plug http://uwa.edu.au into
their browser? They connect to a host called acheron (at UWA) and it
then sends then a redirect that tells their browser to visit
www.uwa.edu.au. Their browers will then do a lookup for www.uwa.edu.au
and connect to mysource-lha. This happens so quickly that most people
probably never realise it's happened. An alternative strategy (which
wouldn't make sense for UWA but might be okay for you) would have been
for acheron to transparently proxy uwa.edu.au requests to www.uwa.edu.au
(which is what I've suggested above).

--end--