"The Linux Gazette...making Linux just a little more fun!"

---

The Answer Guy

By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/

---

Telnetd and pausing

From Clive Flint on Thu, 25 Feb 1999

Hi,

I have made a Linux server using a Tulip dt5/100 machine with 40Mb Memory, a 16Mb swap file and a 1Gb hard disk.

I have a problem that when I try to telnet into the machine it doesn't respond for about 30-40 seconds. Once it has responded then it will talk quite normally.

If I then start another telnet session on my pc it again pauses for the 30-40 seconds. Is there any reason and is there anything that can be done.

This is a classic problem. TCP Wrappers (/sbin/tcpd) is attempting to check the consistency of your name and IP address using its "double reverse DNS lookup."

I've described this before but the short form is: tcpd does a reverse lookup to associate a name with your IP address. It then does a forward lookup on that purported name and scans the responses for your IP address. A properly maintained domain will have consistent forward and reverse mappings.

The reason Wietse Venema (author of TCP Wrappers) does this is to allow you to use host and domain names in your /etc/hosts.allow and /etc/hosts.deny files while reducing the risks inherent in that.

Consider the case of someone who controls any reverse DNS domain (that is anyone who "owns" or has subverted any nameserver to which a range of IP address PTR records as been delegated). It is trivial for them to return any name they like in response to reverse DNS requests. However, it would be non-trivial for an outsider to modify your forward DNS zones (and, if they could they could use "man-in-the-middle" attacks against most common prototols to disrupt your system in many creative ways).

So, tcpd uses a "double reverse" method.

The easy solution for real IP addresses which have been properly delegated to you by your ISP or through the IANA (or your national address registry) is to simply update your reverse zone maps to match the forward ones.

The reason this only affect the initial connections, and that it only affects a limited set of services is because tcpd is only active for those services which are listed in the /etc/inetd.conf as being launched by tcpd with lines like:

ftp	stream	tcp	nowait	root	/usr/sbin/tcpd	in.ftpd

(You'd see similar affects from programs that are linked with "libwrap" --- a compiler library which implements the same set of host access checks as TCP Wrappers).

The reason your web services aren't affected is because they aren't launched through inetd and they aren't compiled with libwrap. (And they don't do these double reverse lookups).

ip numbers
192.9.200.1 clive.clara.net (linux server)
192.9.200.100 cef1 (winnt machine)
192.9.200.101 clivemob (win98 machine)

I believe you should be using RFC1918 addresses for these systems since the real address for clive.net seem to cluster in the 195.8.69.* range and a reverse lookup of 192.9.200.0 suggests that those are not assigned at this time.

I'm assuming that you've just "picked these out of a hat" --- that they haven't been delegated to you. This also suggests that you're using masquerading or a set of applications proxies (such as SOCKS, DeleGate, Danta, etc) to access the 'net.

You could configure your nameserver for "split" DNS or you could configure an internal nameserver (used by all your internal systems). Another technique is to simply put the appropriate entries in your /etc/hosts file. This will bypass DNS (and reverse DNS) queries for most services. The 'gethostbyaddr()' library function will find the IP address and name in the /etc/hosts file first (under most common configurations).

(That might fail if you've changed your /etc/hosts.conf (libc5) or /etc/nsswitch.conf (glibc). However, it's incredibly unlikely that you've touched either of those files).

The server is running dhcp service and that works fine. If I web to it it responds immediately with no delay.

Like I said --- this only affects TCP wrapped services (and others that would do similar consistency checks.

Any help would be gratefully received.

Try adding the appropriate IP addresses to the /etc/hosts files on the involved servers.

---

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 38 March 1999

---

				1	2	3	4	5	6	7	8	9	10	11
				12		14		16	17	18	19		21	22
				23	24		26		28	29	30	31	32

---