Andy Furnell wrote:
> Hello Simon,
>
> Saturday, March 24, 2001, 7:40:40 AM, you wrote:
>
> SG> From: "denny @ d - Rex . net" <[email protected]>
>
>>> because the cost of ip addresses,
>>> why not implement NAT/ipchain in VSD, so that each virtual domain
>>> have one local ip (192.168.x.x) instead of real ip.
>>> all share only one (or two for dns) real ip and then VSD decide
>>> which local ip to use.
>>>
>>> this will also make the whole system more SECURE.
>>> because virtual host do not have real ip, it's invisible to outsider.
>>> this way, VSD automagically function as a firewall too.
>
> SG> How would VSD decide which local ip to use?
>
> SG> HTTP/1.1 is the only protocol which sends a hostname with the request (and
> SG> that's at the application level anyway). For all other protocols the only
> SG> thing VSD has to work with is the destination ip. If the destination ip is
> SG> the same for every virtual server, it can't tell them apart. So every
> SG> virtual server must have its own real ip.
>
> Couldn't this be done with a little modification to the named? How
> about running some sort of server-side cookie implementation which
> would cache the hostname being looked up, and then running an
> internally authoritative name server for these requests? I saw some
> discussion on the possibility of doing this with DJBDNS a little while
> ago, and whilst it's slightly unconventianal (and horrendously
> complicated, as well as being not terribly reliable) it could help
> address fVSD's major weakness...
No, probably not (and it's certainly not a sepcification friendly way to
accomplish this--and thus a frequently incompatible way). DNS is a
multi-tiered caching protocol. Your server and your local DNS have no
bearing on the request coming in. The requester receives their DNS
lookup information from their DNS server, which possibly has a cached
copy of the information (it takes, usually, a couple of days for DNS
changes to be propogated--or you accept a significant hit on DNS
performance by setting refreshes to some obscenely low number). So the
request comes into your server on an IP, /not/ a hostname.
So the problems with this idea:
You'd have to force refresh time to be near-zero, in order to avoid
folks getting the wrong page from your VSD server.
You have to figure out a way to 'mark' the DNS information such that
your vsd can interpret the IP requested as the correct one and map it to
the internal address. As far as I know, there is not a standards
compliant way to achieve this, and requires a modified DNS server
(possibly requires all DNS servers in the chain to be modified to
support the extra field).
I may be missing something here. But I've never heard of DNS being used
for anything of this sort, other than rudimentary load balancing. This
tactic works via round robin selection among multiple real IPs. It
would not work for a single IP with local IPs behind it, which is what
is proposed here.
I encourage someone to prove me wrong, as it would certainly be nice.
But as far as I can tell, it just isn't possible without an L7 director
replacing the vsd. And even then--someone has mentioned, correctly,
that most protocols do not contain hostname information in the request,
so it only works for HTTP 1.1 compliant servers and clients, everything
else still has to be IP accessible. Maybe just having a web server
environment to match FreeVSD and everything else (Mail, ftp, etc.) in a
standard virtual service environment is good enough. All that being
said, the choice for a HTTP L7 director fall down to either TUX, or
Squid to take the place of the vsd. Either would require some
modifications and enhancements to work correctly in this environment
(squid would require fewer mods than TUX as it is already suitable for
accelerating servers on multiple IPs).
Hope this clarifies the situation some.
--
Joe Cooper <[EMAIL PROTECTED]>
Affordable Web Caching Proxy Appliances
http://www.swelltech.com
