Disable ns reverse lookup for telnet

Diego Balgera

unread,

Dec 3, 2001, 8:49:00 AM12/3/01

to

Hi,
when I telnet an host, its telnet daemon performs a reverse lookup to know
the name of the telnetter. This cause a certain delay to have the prompt,
and sometimes the connection fails.
Do you know how to disable this dns reverse lookup?
Note that the dns must stay enabled in nsswitch.conf, otherwise that host
won't use the dns anymore, and it is
needed for other purposes. And I cannot solve the telnetter ip address into
the name, since I can't know all the possible ip addresses to reverse-solve
into the names.

For example: the telnetter is 172.24.50.78, I need to disable the query to
78.50.24.172.in-addr.arpa (as stated below).
Nov 19 17:08:14 nut named[23358]:
XX+/192.168.176.13/78.50.24.172.in-addr.arpa/PTR/IN

The environment: linux mandrake 7.1.

Any idea?
Thank you in advance.
Diego.

Carles Arjona

unread,

Dec 3, 2001, 6:32:05 PM12/3/01

to

Diego Balgera wrote:
>
> when I telnet an host, its telnet daemon performs a reverse lookup to know
> the name of the telnetter. This cause a certain delay to have the prompt,
> and sometimes the connection fails.
> Do you know how to disable this dns reverse lookup?

Reverse DNS lookups are not made by telnetd but by tcpd.

man tcpd

HOST NAME VERIFICATION
The authentication scheme of some protocols (rlogin, rsh)
relies on host names. Some implementations believe the
host name that they get from any random name server; other
implementations are more careful but use a flawed algo
rithm.

tcpd verifies the client host name that is returned by the
address->name DNS server by looking at the host name and
address that are returned by the name->address DNS server.
If any discrepancy is detected, tcpd concludes that it is
dealing with a host that pretends to have someone elses
host name.

--
Regards,

Carles Arjona nosp...@bigfoot.com ( nospammer IS my real username ).

Dean Thompson

unread,

Dec 4, 2001, 6:45:47 AM12/4/01

to

Hi!,

Two quick ways around this problem include:
* Adding a /etc/hosts entry for the machine 172.24.50.78 on the machine
which you are connecting too
* You should be able to go into the /etc/xinet.d/telnet file if Mandrake
7.1 supports xinetd and remove the references to USERID and HOSTID

This should hopefully, solve your problem.

See ya

Dean Thompson

Diego Balgera

unread,

Dec 5, 2001, 6:19:02 AM12/5/01

to

> Two quick ways around this problem include:
> * Adding a /etc/hosts entry for the machine 172.24.50.78 on the machine
> which you are connecting too
> * You should be able to go into the /etc/xinet.d/telnet file if
Mandrake
> 7.1 supports xinetd and remove the references to USERID and HOSTID
>
> This should hopefully, solve your problem.

Hi Dean,
thank you for your answer.
I agree with the validity of the 1st workaround, unfortunately it doesn't
apply since I can't know every possible ip address of the telnetter.
Coming to the second point: in.telnetd relies on xinetd, but it is not clear
to me what I have to comment out from /etc/xinetd.d/telnet. (the content
follow). Any idea?

Thank you again. Diego.

/etc/xinetd.d/telnet

# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}

Dean Thompson

unread,

Dec 5, 2001, 9:29:19 AM12/5/01

to

Hi!,

Diego Balgera wrote:
>
>> Two quick ways around this problem include:
>> * Adding a /etc/hosts entry for the machine 172.24.50.78 on the machine
>> which you are connecting too
>> * You should be able to go into the /etc/xinet.d/telnet file if
>> Mandrake 7.1 supports xinetd and remove the references to USERID and
>> HOSTID
> >
> > This should hopefully, solve your problem.
>
> Hi Dean,
> thank you for your answer.
> I agree with the validity of the 1st workaround, unfortunately it doesn't
> apply since I can't know every possible ip address of the telnetter.
> Coming to the second point: in.telnetd relies on xinetd, but it is not
> clear to me what I have to comment out from /etc/xinetd.d/telnet. (the
> content follow). Any idea?

Damn, it would appear that the /etc/xinetd.d/telnet file doesn't have the
HOSTID logging in it. One thing to test, and you can give it ago is to modify
the /etc/xinetd.conf file and command out the line: log_on_success = HOST PID
or replace it with: log_on_success = PID.

You will need to restart the xinetd daemon. See whether this changes
anything.