apache mod_proxy DNS FUBAR?

[Mark T. Valites]

I thought I remembered seeing someone on the list mention they had
mod_proxy experience with apache once. I think there may be some funk with
mod_proxy and DNS. Read on if you're interested - as complicated of a
setup and as long of an email it may appear to be, it should really be a
simple, elegant solution.

In my house, I have a couple machines always running:

The first is a sparc64 OpenBSD 3.4 firewall/NAT server (FW).
Second is a x86 Debian GNU/Linux nfs/web (Apache 1.3.28)/dhcp/etc server (web2).
Third is a x86 OpenBSD 3.2 web (Apache/1.3.26)/etc server (web1).

My housemate is a web developer who has always hosted a couple "play"
domains off WEB1. Ports 25 and 80 on FW redirect to the corresponding
ports 25 and 80 on WEB1.

A couple weeks ago, I set up exim on WEB2 with mailman for *one* of my
domains. We configured the mailer tables for sendmail on WEB1 to
redirect mail destined to my domains to route to WEB2's IP. This took
care of email. Next we set up mod_proxy in apache to redirect http
requests for my domain to WEB2's *IP*. Warning Bells may be going off at
this point.

(I have shell, but not root on WEB2. I do not have read access to
httpd.conf or else I'd paste in the relevant mod_proxy sections. Apologies
ahead of time.)

This all worked fine until yesterday, when I needed to free a disk up from
my primary web server that hosts a couple domains. We figured it would be
easy to add another mod_proxy entry for a 2nd domain to proxy through WEB1
to a new named based virtual host on web2. After adding a new entry for a
2nd domain to proxy to the *IP* of the new virtual host on WEB2, we found
out that this was a problem since we'd get the default virtual host served
from WEB2.

At this point, I set up dnsmasq on my firewall and added entries for my
virtual hosts to the hosts file. Machines within my house all correctly
resolve my domains to the priivate IP of WEB2 instead of the IP of the
external interface of my firewall, like the rest of the world.

<For those unfamiliar with dnsmasq>
dnsmasq is a slick little program that forwards DNS requests to the DNS
server listed in /etc/resolv.conf. On top of that, it will also serve up
DNS to my entire house for entries in my /etc/hosts file on the dnsmasq
machine. Linksys routers use this same program. It's a lot quicker
than setting up a small caching BIND server. My DHCP server tells all
clients to use the internal address of FW for their DNS server &
therefore I don't have to maintain a separate/etc/hosts files on each
machine.
</For those unfamiliar with dnsmasq>

Within the LAN, entering the url of any domain served from my web server
into a web browser works just fine since the DNS directs the http request
directly to WEB2.

>From outside the LAN in the real world, things don't work quite as well.
mod_proxy on WEB1 gets stupid & appears to not be able to resolve the
domains it should be proxying to WEB2. I get the following error:

Proxy Error
The proxy server could not handle the request GET/.

Apache/1.3.26 Server at www.valites.net Port 80

(note the version - it's actually coming off of WEB1)

I know the problem is mod_proxy and not apache on WEB2 because I've got pf
set up for forward all traffic made to port 8080 of the external interface
of my FW to port 80 of WEB2 & it works just fine.

(http://www.valites.net:8080)

1. http request for www.valites.net->DNS servers
2. my DNS server returns the IP of external interface of my firewall
3. my firewall redirects the traffic on port 80 to a web server on my LAN
4. based on the host header, the webserver realizes its supposed to proxy
the http request to somewhere else
5. the first web server attempts to look up the DNS entry for the host
it's trying to proxy

At this point, the DNS request should hit my dnsmasq machine, which will
return the IP address of the WEB2. Problem is, the DNS request never gets
made to the dnsmasq box. I'm going nuts here - does anyone know if
mod_proxy does something stupid with DNS?

PS. I know I could, but I really don't want to set up IP based virtual
hosts.

-- 
Mark T. Valites
Unix Systems Analyst
Computing & Information Technology
SUNY Geneseo
>--))> >--))>