|
On 25 Mar 2001 15:44:17 -0600, lvs wrote:
> Why are you setting up multiple eth aliases if you are using virtual
> hosts?
> The whole point of virtual hosts is to have 1 IP shared by multiple
> domains and have apache parse out the host from the HTTP header...
>
> Have you tried just having one VIP?
>
> Are all of your real servers configured with the same virtual-host
> directives?
>
> Curtis
>
>
That is not the whole reason for virtual hosts. In fact the
documentation at apache.org says they recommend ip based virtual hosts.
To make matters worse I am setting this up at a university. I am working
within a research group thier and we do not have control over our dns so
i can not change my dns for testing purposes I have to go through
bureacratic chain of command.
I had immediatly dismissed name based virtual hosts because of this. But
I guess it might be worth a shot. My question then becomes what happens
when apache on one of the real servers goes to look up the ip address of
one of its name based virtual hosts and it gets the IP on hte public
side of the director which will not match it 192.168.x.x address? And
what happens if the client requests the web page by ip directly? My
virtual host directives on the real servers are exactly the same except
that the ip addresses are different. Is that what you mean? For example
one realserver1 a virtual host directive looks like:
<VirtualHost 192.168.1.1>
ServerName www.abc.dom
ServerAdmin dfe@xxxxxxx
DocumentRoot /www/abc
</VirtualHost>
and on realserver2 it looks like
<VirtualHost 192.168.1.2>
ServerName www.abc.dom
ServerAdmin dfe@xxxxxxx
DocumentRoot /www/abc
</VirtualHost>
I appreciate your comments i hope i do not come across as argumentative.
If apache won't puke with the dns problems it will probably be my plan
of attack. Are you running a web farm with lvs-nat and name based
virtual hosts?
A rather lengthy excerpt from relevant apache docs follows...
From:
http://httpd.apache.org/docs/vhosts/ip-based.html
"It is recommended that you use an IP address instead of a hostname (see
DNS caveats). "
Where DNS caveats (http://httpd.apache.org/docs/dns-caveats.html)
Apache HTTP
Server
Issues Regarding DNS
and Apache
This page could be summarized with the statement: don't require Apache
to use DNS for any parsing of the configuration files. If Apache has to
use DNS to parse
the configuration files then your server may be subject to reliability
problems (it might not boot), or denial and theft of service attacks
(including users able to steal
hits from other users).
A Simple Example
Consider this configuration snippet:
<VirtualHost www.abc.dom>
ServerAdmin webgirl@xxxxxxx
DocumentRoot /www/abc
</VirtualHost>
In order for Apache to function properly it absolutely needs to have two
pieces of information about each virtual host: the ServerName and at
least one IP address
that the server responds to. This example does not include the IP
address, so Apache must use DNS to find the address of www.abc.dom. If
for some reason DNS
is not available at the time your server is parsing its config file,
then this virtual host will not be configured. It won't be able to
respond to any hits to this virtual
host (prior to Apache version 1.2 the server would not even boot).
Suppose that www.abc.dom has address 10.0.0.1. Then consider this
configuration snippet:
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@xxxxxxx
DocumentRoot /www/abc
</VirtualHost>
Now Apache needs to use reverse DNS to find the ServerName for this
virtualhost. If that reverse lookup fails then it will partially disable
the virtualhost (prior to
Apache version 1.2 the server would not even boot). If the virtual host
is name-based then it will effectively be totally disabled, but if it is
IP-based then it will
mostly work. However if Apache should ever have to generate a full URL
for the server which includes the server name then it will fail to
generate a valid URL.
Here is a snippet that avoids both of these problems.
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@xxxxxxx
DocumentRoot /www/abc
</VirtualHost>
Denial of Service
There are (at least) two forms that denial of service can come in. If
you are running a version of Apache prior to version 1.2 then your
server will not even boot if
one of the two DNS lookups mentioned above fails for any of your virtual
hosts. In some cases this DNS lookup may not even be under your control.
For example,
if abc.dom is one of your customers and they control their own DNS then
they can force your (pre-1.2) server to fail while booting simply by
deleting the
www.abc.dom record.
Another form is far more insidious. Consider this configuration snippet:
<VirtualHost www.abc.dom>
ServerAdmin webgirl@xxxxxxx
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.dom>
ServerAdmin webguy@xxxxxxx
DocumentRoot /www/def
</VirtualHost>
Suppose that you've assigned 10.0.0.1 to www.abc.dom and 10.0.0.2 to
www.def.dom. Furthermore, suppose that def.com has control of their own
DNS. With this
config you have put def.com into a position where they can steal all
traffic destined to abc.com. To do so, all they have to do is set
www.def.dom to 10.0.0.1. Since
they control their own DNS you can't stop them from pointing the
www.def.com record wherever they wish.
Requests coming in to 10.0.0.1 (including all those where users typed in
URLs of the form http://www.abc.dom/whatever) will all be served by the
def.com virtual
host. To better understand why this happens requires a more in-depth
discussion of how Apache matches up incoming requests with the virtual
host that will
serve it. A rough document describing this is available.
The "main server" Address
The addition of name-based virtual host support in Apache 1.1 requires
Apache to know the IP address(es) of the host that httpd is running on.
To get this
address it uses either the global ServerName (if present) or calls the C
function gethostname (which should return the same as typing "hostname"
at the command
prompt). Then it performs a DNS lookup on this address. At present there
is no way to avoid this lookup.
If you fear that this lookup might fail because your DNS server is down
then you can insert the hostname in /etc/hosts (where you probably
already have it so that
the machine can boot properly). Then ensure that your machine is
configured to use /etc/hosts in the event that DNS fails. Depending on
what OS you are using
this might be accomplished by editing /etc/resolv.conf, or maybe
/etc/nsswitch.conf.
If your server doesn't have to perform DNS for any other reason then you
might be able to get away with running Apache with the HOSTRESORDER
environment
variable set to "local". This all depends on what OS and resolver
libraries you are using. It also affects CGIs unless you use mod_env to
control the environment. It's
best to consult the man pages or FAQs for your OS.
Tips to Avoid these problems
use IP addresses in <VirtualHost>
use IP addresses in Listen
use IP addresses in BindAddress
ensure all virtual hosts have an explicit ServerName
create a <VirtualHost _default_:*> server that has no pages to
serve
To make matters worse I am setting this up at a university. I am working
within a research group thier and we do not have control over our dns so
i can not change my dns for testing purposes I have to go through
bureacratic chain of command.
--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
| Douglas F. Elznic |
| <dfelznic (at) syr.edu> |
| |
| O r g |
| e. Anize.org |
| z i n |
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
|
