Reverse ip lookup problem?

I am investigating a problem on my LAN - some operations seemed very
slow.
There are 3 machines on the LAN. Two (leo.galaxy and orion.galaxy) are
only connected to the LAN. The third (ursa.galaxy) is the
firewall/gateway and has a connection thru a cable modem to the
internet.
The test: on orion, I do: telnet leo 25. Port 25 is the smtp port and
leo is set up to run exim. I am running iptraf on leo to see what
happens. Both leo and orion are in /etc/hosts on all 3 machines. So I
do not expect to see any traffic to my ISP's DNS.
Here is what I see (iptraf log):
----start log extract-----
Fri Oct 8 19:12:39 2004; UDP; eth0; 56 bytes; from leo.galaxy:59023
to ns1.ggamaur.net:domain
Fri Oct 8 19:12:44 2004; UDP; eth0; 56 bytes; from leo.galaxy:59024
to ns2.ggamaur.net:domain
Fri Oct 8 19:12:49 2004; UDP; eth0; 49 bytes; from leo.galaxy:59025
to ns1.ggamaur.net:domain
Fri Oct 8 19:12:54 2004; UDP; eth0; 49 bytes; from leo.galaxy:59026
to ns2.ggamaur.net:domain
Fri Oct 8 19:12:59 2004; UDP; eth0; 49 bytes; from leo.galaxy:59025
to ns1.ggamaur.net:domain
Fri Oct 8 19:13:04 2004; UDP; eth0; 49 bytes; from leo.galaxy:59026
to ns2.ggamaur.net:domain
Fri Oct 8 19:13:09 2004; TCP; eth0; 60 bytes; from leo.galaxy:36716
to orion.galaxy:auth; first packet (SYN)
--------end log extract----
The ISP's DNS are ns{1,2}.ggamaur.net so what seems to be happening is
that something on leo (exim?) is doing a lookup, then times out after
40 seconds. The lookup is completely pointless because after it fails,
exim continues anyway (and I see its prompt on orion). But my question
is, why is it going to the nameserver anyway? Here's the relevant part
of /etc/hosts:
127.0.0.1 localhost
192.168.1.9 ursa.galaxy ursa
192.168.1.5 orion.galaxy orion
192.168.1.11 leo.galaxy leo

And here's /etc/nsswitch.conf:

passwd: compat
group: compat
shadow: compat

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

And here's /etc/host.conf :
order hosts,bind
multi on


Both leo and orion are running Debian sarge. Here's the output of
uname -a on leo:
Linux Leo 2.6.3-1-k7 #2 Tue Feb 24 20:39:50 EST 2004 i686 GNU/Linux

Everything is up-to-date, I did apt-get update and upgrade about a
week ago.

The consequence of this problem is that a lot of things take 40
seconds longer than they should, this being how long it takes for
queries (which should never happen) to time out 5 times on both of the
ISP's two nameservers.

Any ideas, anyone?


Retlak

Where your telnetd is invoked from?
In other words, what process listens the port 23
and how is it configured?

Tcpd is known to make a reverse DNS query, see tcpd(8).
Other "internet super-server" soft (e.g. xinetd) may also do this.


--
qq~~~~\ [ úá IP âåú ãåîúõòù ] [ Read Usenet in the proper place ]
/ /\ \ [ FAQ you ] € http://www.comtv.ru/~av95/chainik.html
\ /_/ /
\____/ Linux console notes http://www.comtv.ru/~av95/linux/console/

(E-Mail Removed) (Retlak) writes:

]I am investigating a problem on my LAN - some operations seemed very
]slow.
]There are 3 machines on the LAN. Two (leo.galaxy and orion.galaxy) are
]only connected to the LAN. The third (ursa.galaxy) is the
]firewall/gateway and has a connection thru a cable modem to the
]internet.
]The test: on orion, I do: telnet leo 25. Port 25 is the smtp port and
]leo is set up to run exim. I am running iptraf on leo to see what
]happens. Both leo and orion are in /etc/hosts on all 3 machines. So I
]do not expect to see any traffic to my ISP's DNS.
]Here is what I see (iptraf log):
]----start log extract-----
]Fri Oct 8 19:12:39 2004; UDP; eth0; 56 bytes; from leo.galaxy:59023
]to ns1.ggamaur.net:domain
]Fri Oct 8 19:12:44 2004; UDP; eth0; 56 bytes; from leo.galaxy:59024
]to ns2.ggamaur.net:domain
]Fri Oct 8 19:12:49 2004; UDP; eth0; 49 bytes; from leo.galaxy:59025
]to ns1.ggamaur.net:domain
]Fri Oct 8 19:12:54 2004; UDP; eth0; 49 bytes; from leo.galaxy:59026
]to ns2.ggamaur.net:domain
]Fri Oct 8 19:12:59 2004; UDP; eth0; 49 bytes; from leo.galaxy:59025
]to ns1.ggamaur.net:domain
]Fri Oct 8 19:13:04 2004; UDP; eth0; 49 bytes; from leo.galaxy:59026
]to ns2.ggamaur.net:domain
]Fri Oct 8 19:13:09 2004; TCP; eth0; 60 bytes; from leo.galaxy:36716
]to orion.galaxy:auth; first packet (SYN)
]--------end log extract----
]The ISP's DNS are ns{1,2}.ggamaur.net so what seems to be happening is
]that something on leo (exim?) is doing a lookup, then times out after
]40 seconds. The lookup is completely pointless because after it fails,
]exim continues anyway (and I see its prompt on orion). But my question
]is, why is it going to the nameserver anyway? Here's the relevant part
]of /etc/hosts:
]127.0.0.1 localhost
]192.168.1.9 ursa.galaxy ursa
]192.168.1.5 orion.galaxy orion
]192.168.1.11 leo.galaxy leo

]And here's /etc/nsswitch.conf:

]passwd: compat
]group: compat
]shadow: compat

]hosts: files dns
]networks: files

]protocols: db files
]services: db files
]ethers: db files
]rpc: db files

]netgroup: nis

]And here's /etc/host.conf :
]order hosts,bind
]multi on


]Both leo and orion are running Debian sarge. Here's the output of
]uname -a on leo:
]Linux Leo 2.6.3-1-k7 #2 Tue Feb 24 20:39:50 EST 2004 i686 GNU/Linux

]Everything is up-to-date, I did apt-get update and upgrade about a
]week ago.

]The consequence of this problem is that a lot of things take 40
]seconds longer than they should, this being how long it takes for
]queries (which should never happen) to time out 5 times on both of the
]ISP's two nameservers.
oThe new getaddrinfo routines (which are IPV6 ready instead of the
gethostbyaddr etc routines) seem to query the internet even if they find
the name in /etc/hosts. I have no idea why. I found this with ssh. Mandrake
could not replicate the problem, and I have ot pushed it, so I pass the
torch to you.
Does exim use getaddrinfo rather than gethostbyname or gethostbyaddr? If
not my comments are irrelevant. If it does, use strace to narrow it down.

Innocenti Maresin <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Where your telnetd is invoked from?
> In other words, what process listens the port 23
> and how is it configured?
>
> Tcpd is known to make a reverse DNS query, see tcpd(8).
> Other "internet super-server" soft (e.g. xinetd) may also do this.

As I said, "I do: telnet leo 25. Port 25 is the smtp port and leo is
set up to run exim." The relevant line in my /etc/inetd.conf on leo
is:
smtp stream tcp nowait mail /usr/sbin/exim exim
-bs

Maybe exim makes a reverse DNS query, but the question is, why would a
reverse DNS query go to a nameserver when the connecting machine is in
/etc/hosts? NB /etc/host.conf has got "order hosts,bind" which means
to look in /etc/hosts before trying a DNS server (see the original
post).

(E-Mail Removed) (Bill Unruh) wrote in message news:<ck9fvk$95m$(E-Mail Removed)>...

> oThe new getaddrinfo routines (which are IPV6 ready instead of the
> gethostbyaddr etc routines) seem to query the internet even if they find
> the name in /etc/hosts. I have no idea why. I found this with ssh. Mandrake
> could not replicate the problem, and I have ot pushed it, so I pass the
> torch to you.
> Does exim use getaddrinfo rather than gethostbyname or gethostbyaddr? If
> not my comments are irrelevant. If it does, use strace to narrow it down.

Thanks for pointing me to strace. What a fascinating program!
I put strace with appropriate args to start exim in inetd.conf,
capturing a log file, and did the test again. From the log file, exim
does the following:
Opens and reads /etc/exim.conf
Opens, reads, then closes /etc/resolv.conf
Opens, reads, then closes /etc/nsswitch.conf
Opens, reads, then closes /etc/host.conf, and the contents "order
hosts,bind\nmulti on\n" appears in the logfile!
opens, reads, then closes /etc/hosts
opens a socket and connects to the ISP's nameserver!!

So, it's reading all the right files, that tell it to use /etc/hosts,
and it's reading /etc/hosts. But then it's ignoring the contents and
connecting to the nameserver anyway.
The exact content of the logfile, from the point where it reads
exim.conf up to the point where it connects to the nameserver, follows
in case you or anyone can see anything useful I overlooked.
----cut here-----
open("/etc/exim/exim.conf", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=430, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=430, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "#Main (global) configuration set"..., 4096) = 430
uname({sys="Linux", node="Leo", ...}) = 0
gettimeofday({1097402473, 24045}, NULL) = 0
getpid() = 13327
open("/etc/resolv.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=63, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40019000
read(4, "search galaxy\nnameserver 213.160"..., 4096) = 63
read(4, "", 4096) = 0
close(4) = 0
munmap(0x40019000, 4096) = 0
socket(PF_UNIX, SOCK_STREAM, 0) = 4
connect(4, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) =
-1 ENOENT (No such file or directory)
close(4) = 0
open("/etc/nsswitch.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40019000
read(4, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
read(4, "", 4096) = 0
close(4) = 0
munmap(0x40019000, 4096) = 0
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=45416, ...}) = 0
old_mmap(NULL, 45416, PROT_READ, MAP_PRIVATE, 4, 0) = 0x402ff000
close(4) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libnss_files.so.2", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\ 33\0\000"...,
512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size=35140, ...}) = 0
old_mmap(NULL, 38520, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0x4030b000
old_mmap(0x40314000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x8000) = 0x40314000
close(4) = 0
munmap(0x402ff000, 45416) = 0
open("/etc/host.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x402ff000
read(4, "order hosts,bind\nmulti on\n", 4096) = 26
read(4, "", 4096) = 0
close(4) = 0
munmap(0x402ff000, 4096) = 0
open("/etc/hosts", O_RDONLY) = 4
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=517, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x402ff000
read(4, "127.0.0.1\tlocalhost\n192.168.1.9\t"..., 4096) = 517
read(4, "", 4096) = 0
close(4) = 0
munmap(0x402ff000, 4096) = 0
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=45416, ...}) = 0
old_mmap(NULL, 45416, PROT_READ, MAP_PRIVATE, 4, 0) = 0x402ff000
close(4) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libnss_dns.so.2", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2 60\r\0"...,
512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size=13424, ...}) = 0
old_mmap(NULL, 16328, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0x40315000
old_mmap(0x40318000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x2000) = 0x40318000
close(4) = 0
munmap(0x402ff000, 45416) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("213.160.40.2")}, 28) = 0
send(4, "a\214\1\0\0\1\0\0\0\0\0\0\3Leo\6galaxy\0\0\34\0\1 ", 28, 0) =
28
gettimeofday({1097402473, 26934}, NULL) = 0
--cut here-----
Note: 213.160.40.2 is one of the ISP's nameservers.

On 9 Oct 2004 16:28:05 -0700, Retlak <(E-Mail Removed)> wrote:
> Innocenti Maresin <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> Where your telnetd is invoked from?
>> In other words, what process listens the port 23
>> and how is it configured?
>>
>> Tcpd is known to make a reverse DNS query, see tcpd(8).
>> Other "internet super-server" soft (e.g. xinetd) may also do this.
>
> As I said, "I do: telnet leo 25. Port 25 is the smtp port and leo is
> set up to run exim." The relevant line in my /etc/inetd.conf on leo
> is:
> smtp stream tcp nowait mail /usr/sbin/exim exim
> -bs
>
> Maybe exim makes a reverse DNS query, but the question is, why would a
> reverse DNS query go to a nameserver when the connecting machine is in
> /etc/hosts? NB /etc/host.conf has got "order hosts,bind" which means
> to look in /etc/hosts before trying a DNS server (see the original
> post).

Anything configured to use tcpwrappers will use "all" means possible to
verify a connecting client (including DNS). Although that may depend upon
the contents of /etc/hosts.allow and hosts.deny. My sendmail and sshd
were configured with tcpwrappers, and I imagine your exim is too.

When I first got DSL, their nameservers were slow. So when I set up bind9
to do my own DNS, I added forward and reverse zones for my private LAN
names/IPs. Therefore, no delays for local ssh or mail.

(E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...
> On 9 Oct 2004 16:28:05 -0700, Retlak <(E-Mail Removed)> wrote:
> > Innocenti Maresin <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> >> Where your telnetd is invoked from?
> >> In other words, what process listens the port 23
> >> and how is it configured?
> >>
> >> Tcpd is known to make a reverse DNS query, see tcpd(8).
> >> Other "internet super-server" soft (e.g. xinetd) may also do this.
> >
> > As I said, "I do: telnet leo 25. Port 25 is the smtp port and leo is
> > set up to run exim." The relevant line in my /etc/inetd.conf on leo
> > is:
> > smtp stream tcp nowait mail /usr/sbin/exim exim
> > -bs
> >
> > Maybe exim makes a reverse DNS query, but the question is, why would a
> > reverse DNS query go to a nameserver when the connecting machine is in
> > /etc/hosts? NB /etc/host.conf has got "order hosts,bind" which means
> > to look in /etc/hosts before trying a DNS server (see the original
> > post).
>
> Anything configured to use tcpwrappers will use "all" means possible to
> verify a connecting client (including DNS). Although that may depend upon
> the contents of /etc/hosts.allow and hosts.deny. My sendmail and sshd
> were configured with tcpwrappers, and I imagine your exim is too.

But, as you can see from the extract I gave from my /etc/inetd.conf
file, exim is *not* using tcp wrappers. To use tcp wrappers, the line
would be something like:
smtp stream tcp nowait mail /usr/sbin/tcpd exim -bs
~~~~~~~~~~~~~~

My inetd.conf does **not** contain that. Please see above.

On 12 Oct 2004 08:47:07 -0700, Retlak <(E-Mail Removed)> wrote:
> (E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...
>> On 9 Oct 2004 16:28:05 -0700, Retlak <(E-Mail Removed)> wrote:
>> > Innocenti Maresin <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> >> Where your telnetd is invoked from?
>> >> In other words, what process listens the port 23
>> >> and how is it configured?
>> >>
>> >> Tcpd is known to make a reverse DNS query, see tcpd(8).
>> >> Other "internet super-server" soft (e.g. xinetd) may also do this.
>> >
>> > As I said, "I do: telnet leo 25. Port 25 is the smtp port and leo is
>> > set up to run exim." The relevant line in my /etc/inetd.conf on leo
>> > is:
>> > smtp stream tcp nowait mail /usr/sbin/exim exim
>> > -bs
>> >
>> > Maybe exim makes a reverse DNS query, but the question is, why would a
>> > reverse DNS query go to a nameserver when the connecting machine is in
>> > /etc/hosts? NB /etc/host.conf has got "order hosts,bind" which means
>> > to look in /etc/hosts before trying a DNS server (see the original
>> > post).
>>
>> Anything configured to use tcpwrappers will use "all" means possible to
>> verify a connecting client (including DNS). Although that may depend upon
>> the contents of /etc/hosts.allow and hosts.deny. My sendmail and sshd
>> were configured with tcpwrappers, and I imagine your exim is too.
>
> But, as you can see from the extract I gave from my /etc/inetd.conf
> file, exim is *not* using tcp wrappers. To use tcp wrappers, the line
> would be something like:
> smtp stream tcp nowait mail /usr/sbin/tcpd exim -bs
> ~~~~~~~~~~~~~~
>
> My inetd.conf does **not** contain that. Please see above.

If exim was compiled with tcpwrappers (built-in), whether it attempts to
resolve client IPs does not matter how it was launched. My sendmail and
sshd have built-in tcpwrappers even though they are not launched by inetd
(or xinetd) and do not run under tcpd (just launched by their own
filenames). That became apparent when I had to put sendmail in
hosts.allow for it to work, if my default was to deny all.

ipv6 can complicate matters too, where even if forward and reverse ipv4
DNS matches /etc/hosts, a daemon may warn that the identical names it
lists are not a match.

(E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...
> On 12 Oct 2004 08:47:07 -0700, Retlak <(E-Mail Removed)> wrote:
> > (E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...

> >> Anything configured to use tcpwrappers will use "all" means possible to
> >> verify a connecting client (including DNS). Although that may depend upon
> >> the contents of /etc/hosts.allow and hosts.deny. My sendmail and sshd
> >> were configured with tcpwrappers, and I imagine your exim is too.
> >
> > But, as you can see from the extract I gave from my /etc/inetd.conf
> > file, exim is *not* using tcp wrappers. To use tcp wrappers, the line
> > would be something like:
> > smtp stream tcp nowait mail /usr/sbin/tcpd exim -bs
> > ~~~~~~~~~~~~~~
> >
>
> If exim was compiled with tcpwrappers (built-in), whether it attempts to
> resolve client IPs does not matter how it was launched. My sendmail and
> sshd have built-in tcpwrappers even though they are not launched by inetd
> (or xinetd) and do not run under tcpd (just launched by their own
> filenames). That became apparent when I had to put sendmail in
> hosts.allow for it to work, if my default was to deny all.
>
> ipv6 can complicate matters too, where even if forward and reverse ipv4
> DNS matches /etc/hosts, a daemon may warn that the identical names it
> lists are not a match.

David - you are right. I just built exim from source and there is
indeed a build option one can set to use tcpwrappers from within Exim.
And, when I built exim (same version I am using, 3.36), not selecting
that option - the problem goes away. So it is almost certain that this
is the problem. Thanks!

I don't understand why Debian would build their exim package in this
way. Somebody who wants to use tcpwrappers can always do it with the
inetd.conf mechanism, if exim itself is built without it. Building
exim with tcpwrappers seems to remove flexibility. But at least with
free software one has the option of building the app oneself instead
of going with the standard package.