/etc/host.conf has "order hosts,bind"
/etc/nsswitch.conf has "hosts: files dns nisplus"
/etc/hosts contains:
127.0.0.1 localhost
192.168.10.254 janus
192.168.10.1 jhg
192.168.10.2 joyce
This machine (janus) is dual-homed on my local network and my
cable-modem connection.
Any attempt to do reverse DNS on one of the 192.168.10.* addresses
causes a query to be sent to the cable company's domain server,
which of course returns NXDOMAIN. Such queries are NOT resolved
from /etc/hosts (verified by watching IP stream with ethereal
sniffer).
A quick scan of Google (ex Deja) shows hundreds of posts dating
from 1996 to the present on this subject.
Can anyone shed some light on this problem?
Are there any debugging flags I can turn on without rebuilding the
kernel that would trace the name resolution process and perhaps
localize the problem?
--
Jim Garrison (j...@acm.org)
PGP Keys at http://www.acm.org/~jhg RSA 0x04B73B7F DH 0x70738D88
> Brand new RH 7.1 install.
>
> /etc/host.conf has "order hosts,bind"
> /etc/nsswitch.conf has "hosts: files dns nisplus"
> Any attempt to do reverse DNS on one of the 192.168.10.* addresses
> causes a query to be sent to the cable company's domain server,
> which of course returns NXDOMAIN. Such queries are NOT resolved
> from /etc/hosts (verified by watching IP stream with ethereal
> sniffer).
> Are there any debugging flags I can turn on without rebuilding the
> kernel that would trace the name resolution process and perhaps
> localize the problem?
Depends on the tool or API used to do the reverse query. It's not in the
kernel, it's going to be in the C or resolver library. You could rebuild
the library with debugging enabled.
An easy workaround is to install a simple DNS server and set up a reverse
domain for your LAN addresses. Install the BIND RPM and the caching-
nameserver RPM. Change resolv.conf to use localhost as your nameserver.
Then add the reverse domain to named.conf and the zone file in /var/named.
For more info on this, check the BIND resources at ISC
(http://www.isc.org).
--
Kenneth Porter
http://www.sewingwitch.com/ken/
Remove 'invalid' for correct email address
>
>Depends on the tool or API used to do the reverse query. It's not in the
>kernel, it's going to be in the C or resolver library. You could rebuild
>the library with debugging enabled.
>
I've seen wu-ftpd using the resolver library directly instead of using
gethostbyxxx, and therefore will use DNS regardless of /etc/nsswitch.conf.
The existense of /etc/resolv.conf seems to be ther trigger.
Villy
> /etc/host.conf has "order hosts,bind"
> /etc/nsswitch.conf has "hosts: files dns nisplus"
> /etc/hosts contains:
>
> 127.0.0.1 localhost
> 192.168.10.254 janus
> 192.168.10.1 jhg
> 192.168.10.2 joyce
>
> This machine (janus) is dual-homed on my local network and my
> cable-modem connection.
>
> Any attempt to do reverse DNS on one of the 192.168.10.* addresses
> causes a query to be sent to the cable company's domain server,
> which of course returns NXDOMAIN. Such queries are NOT resolved
> from /etc/hosts (verified by watching IP stream with ethereal
> sniffer).
This is correct and the reason for the requests to be sent to the company's
domain server is because the /etc/hosts file does not provide a "complete"
reverse DNS solution. Some utilities will actually connect to the nameservers
and expect them to perform reverse lookups based on their data skipping past
the /etc/hosts file.
I am not exactally sure what daemons you are using to trigger these reverse
DNS queries, but you may actually have to establish a DNS server on your
network and provide the reverse lookup zones yourself.
See ya
Dean Thompson
--
+____________________________+____________________________________________+
| Dean Thompson | E-mail - Dean.T...@csse.monash.edu.au |
| Bach. Computing (Hons) | ICQ - 45191180 |
| PhD Student | Office - <Off-Campus> |
| School Comp.Sci & Soft.Eng | Phone - +61 3 9903 2787 (Gen. Office) |
| MONASH (Caulfield Campus) | Fax - +61 3 9903 1077 |
| Melbourne, Australia | |
+----------------------------+--------------------------------------------+
The most obnoxious result is that connections to janus
via ftp from other hosts in the local network see at least a
5-second delay while ftpd attempts to lookup the IP address
and has to wait for the name server.
Dean Thompson wrote:
>
> Hi Jim,
>
> > /etc/host.conf has "order hosts,bind"
> > /etc/nsswitch.conf has "hosts: files dns nisplus"
> > /etc/hosts contains:
> >
> > 127.0.0.1 localhost
> > 192.168.10.254 janus
> > 192.168.10.1 jhg
> > 192.168.10.2 joyce
> >
> > This machine (janus) is dual-homed on my local network and my
> > cable-modem connection.
> >
> > Any attempt to do reverse DNS on one of the 192.168.10.* addresses
> > causes a query to be sent to the cable company's domain server,
> > which of course returns NXDOMAIN. Such queries are NOT resolved
> > from /etc/hosts (verified by watching IP stream with ethereal
> > sniffer).
>
> This is correct and the reason for the requests to be sent to the company's
> domain server is because the /etc/hosts file does not provide a "complete"
> reverse DNS solution. Some utilities will actually connect to the nameservers
> and expect them to perform reverse lookups based on their data skipping past
> the /etc/hosts file.
>
> I am not exactally sure what daemons you are using to trigger these reverse
> DNS queries, but you may actually have to establish a DNS server on your
> network and provide the reverse lookup zones yourself.
--
James Garrison Athens Group, Inc.
mailto:j...@athensgroup.com 5608 Parkcrest Dr
http://www.athensgroup.com Austin, TX 78731
PGP: RSA=0x04B73B7F DH/DSS=0x70738D88 (512) 345-0600 x150
> This behavior seems to be different from prior versions of Linux.
>
> The most obnoxious result is that connections to janus
> via ftp from other hosts in the local network see at least a
> 5-second delay while ftpd attempts to lookup the IP address
> and has to wait for the name server.
Yes, with the introduction of the newer distributions of Linux, the reverse
DNS lookup has become more important with the increase of IP spoofing which is
going around at the moment. In the previous versions, it use to be an option
for which a daemon could be wrapped with tcp-wrappers. Today, it seems that
most of this wrapping is now embeded with the internet manager handling the
incoming connection or the daemon itself.