On 05/21/2012 11:18 AM, Eric Shubert wrote:
On
05/21/2012 11:14 AM, Cecil Yother, Jr. wrote:
On 05/21/2012 11:12 AM, Eric Shubert wrote:
On 05/21/2012 10:59 AM, Cecil Yother,
Jr. wrote:
I am not sure I quite understand why
it doesn't work and a resolver is
needed. If I do a dig it answers to the proper IP. It
stands to reason
that I should be able to access that server through a web
browser, and
it cannot. What is a resolver going to tell my system that
it already
doesn't know ?
On 05/21/2012 10:52 AM, Eric Shubert wrote:
I don't think so. I don't think you
should have the same name twice in
your hosts file. I'm not sure off hand which address linux
would
return in this case. (How would it know when to return
which one?)
What makes this work is that one resolver (your local
resolver) is
used when connected to the LAN which returns the LAN
address
corresponding to the name, and a different resolver
(internet
authoritative dns) is used when connected to the WAN.
A firewall such as IPCop can be used as a local resolver
to provide
the local addresses (recommended method). This can also be
implemented
in a single bind host using the split horizon feature, but
that's a
bit tricky.
--
Did doesn't look at /etc/hosts.
If your dig answers with the proper IP, you should be ok.
Yes, it does. So that's why I'm a bit confused.
--
What exactly is confusing?
It resolves to the correct address, but will not answer. I just
added the LAN address, ie.
Listen 192.168.0.168:80
to the httpd.conf file and now it answers and I'm able to access
the pages, but it's not answering them via the WAN.
--
 |
