DNSSERVER Problems

I am having a problem with dnsserver failing to return the "right" answer.

I have Squid 1.1.22 running on a bastion host that also runs BIND and
functions as an external name server. As the site wanted a split DNS
configuration, BIND only knows about systems that are "visible" to the
Internet. The few internal hosts that system needs to be aware of are
listed in /etc/hosts.

Local name queries are performed using the information resource search
list, /etc/irs.conf. The order for name queries is to search /etc/hosts
and if not found query BIND.

Several of the internal Web servers are accessible to the Internet via
virtual hosts on an external Web server. Through some counter-intuitive
magic the external Web server access the internal Web server to retrieve
the requested data.

A key part of this configuration is that the domain name of the virtual
host and the internal Web server is identical. All that differs is the IP
address and that all data moving between the virtual host and the client
on the Internet is encrypted. A "road warrior" can undock his laptop from
the site's local LAN, go to some remote corner of the globe, and access
data using the same bookmarks that he uses at home.

Cute! What does this have to do with dnsserver?

The problem has more to do with a failing of Netscape 4.5. If the
browser is configured to use the Squid proxy with the local domain name
defined in the exception block and the user enters only a simply host name
in the URI, Netscape sends the request to Squid instead of going directly
to the internal Web server.

Squid hands the host name to dnsserver. It returns the IP address of the
virtual host indicating that it may be going directly to BIND which in
this instance returns a "correct" but "wrong" answer. All of the other
applications that I've tested always return the "right", "correct" answer.

Does dnsserver use the local name resolution routines or does it use a
"homegrown" resolution routine like nslookup or dig to name a couple?

Merton Campbell Crockett
Received on Tue Jun 08 1999 - 19:02:07 MDT