[svlug] Re: Re: virtual domain names inside the LAN

[Ira Abramov]

Quoting Daevid Vincent, from the post of Tue, 27 Aug:
> After re-reading this, I am still a bit confused. I get what your
> saying, I just don't get why it works like that.

that's how the RFCs say it should, that's how TCP/IP and DNS resolution
work.

> It seems to me that if people outside my LAN get routed to the right IP
> (12.228.95.58) and then Apache handles it from there, how come it isn't

wrong. the people outside contact 12.228.95.58 which is NOT your
server's IP, it is the IP of the external leg of the router. the router
mangles the destination address of the packet and sends it on to the
linux box as IF it was originally meant for it (that's called PAT
usually - Port Address Translation, or DNAT in iptables jargon), then
the linux recieves it as it it was sent to 192.168.0.254, and then the
apache handles it.

> the case that when Lynx on my Linux box (192.168.0.254) makes the
> request, it goes out to the DNS server, doesn't it get returned the same
> IP 12.228.95.58 as everyone else, and therefore shouldn't it go to
> 12.228.95.58 and then Apache handles it again like any other request?

well, just try, from within the LAN, to telnet to 12.228.95.58, port 80.

depending on the way your NAT is configured (or indeed the type of
packet filter/firewall), this may not be allowed. the NAT is probably
configured to implement this PAT rule of packets coming in from eth0
destined for eth1 (I'm guessing the interfaces ofcourse), but consideres
packets from eth1 that go back out on eth1 after translation as errors.
the case is expecially problematic with packets exiting the same host
(by the time the packet gets to the host, it looks like it came from
192.168.0.254 to 192.168.0.254 but not on the lo interface. if it tries
to reply, the address is local so it won't reply through the router to a
local address, but then it will not find any socket waiting for such a
reply (because technically you were expecting an answer from
12.228.95.58 and not 192.168.0.254).

the bottom line - serving from behind a PAT/NAT firewall to both local
users and the 'Net at large is a problem.

> 192.168.0.254	www.marq.org ftp.marq.org marq.org marq 192.168.0.254
> www.VRExhibits.com ftp.VRExhibits.com VRExhibits.com
> 
> Can I stack the same IP like that or does it have to be on one long
> line? 

I don't think you can have multiple lines with the same key, certainly
for reverse resolution. I think it's a safe bet it needs to be 1-to-1

> And do I need to have all four permutations of each domain (www. ftp.
> .com name)? 

if you really need to use them all...

afterall, remember they are just names pointing to an address. you have
seen one you have seen them all.

> Should the IP be 127.0.0.1 or 192.168.0.254 for all the virtual
> domains?

any address that apache listens on (in your case, both are correct)

another thing you can do is add another record to all those zone files:

direct IN A 192.168.0.254

and add a host alias for direct.<whatever>.com in your apache. that way
you don't need to do /etc/hosts magic, but just get to the same sites
via different names. this will ofcourse fail if you give absolute links
in any of the sites.


The very last idea that pops into mind is a wild speculation and I have
never tried it - Apache has a proxy module. try to enable it and have
lynx use it. maybe it's smart enough to reply to proxy requests for one
of it's local alias hosts without going out and trying to get the packet
translated by the router, since afterall it has access to the same
config files. wild speculation, but has a good chance of working.

other than that and a BIND9 setup I'm dried up of ideas. It's 3am here,
so we'll talk again tomorrow if that didn't work.

-- 
Keepin' it real
Ira Abramov

http://ira.abramov.org/email/ This post is encrypted twice with ROT-13.
Documenting or attempting to crack this encryption is illegal.