Please help! Pretty please? (DNS trouble, I think)

Hi,

I'm so damn frustrated by how utterly clueless I am about
what could be the reason of this behaviour that I can't
even begin to imagine how it is physically possible that
it happens.

Here's what's happening:

I log on to the server (it's a "dedicated server" that
we're renting from a web hoster -- it has "direct"
connection to the net, with a static IP address), and
type the command:

$ telnet localhost 5555

For about ten seconds I have no reply. Then, I get the
expected:

Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

(there's nothing listening on that port, and there is no
iptables rules affecting that port either)

If I type:

$ telnet 127.0.0.1 5555

Then I get the expected response in zero time.


The file /etc/hosts contains the following: (I changed
the actual IP addresses and names, but other than that
this is verbatim what the /etc/hosts file contains)

--- FILE CONTENTS BEGIN ---
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
1.2.3.4 www.domain.com
1.2.3.5 secure.domain.com
1.2.3.6 mail.domain.com
--- FILE CONTENTS END ---

The file /etc/host.conf contains a single line:

order hosts,bind


Can you think of something that could explain this
behaviour?? I'm tempted to think that it's our hoster's
DNS servers fault (I tried telnetting port 53 of their
DNS servers, and it did take some time to reply); but
the thing is that I can not understand or justify how
could that affect the behaviour of a connection to
localhost. I mean, that even if their DNS were slow,
or misconfigured, or even completely down, I still don't
see how that would produce a delay in establishing a
connection to *localhost*.

Could someone please enlighten me?

Thanks,

Carlos
--

Carlos Moreno <(E-Mail Removed)> wrote:
>
> I log on to the server (it's a "dedicated server" that
> we're renting from a web hoster -- it has "direct"
> connection to the net, with a static IP address), and
> type the command:
>
> $ telnet localhost 5555
>
> For about ten seconds I have no reply. Then, I get the
> expected:
>
> Trying 127.0.0.1...

Your resolver is broke. Your /etc/hosts is bust. "localhost"
must resolve immediately via /etc/hosts.

> telnet: connect to address 127.0.0.1: Connection refused

>
> (there's nothing listening on that port, and there is no
> iptables rules affecting that port either)

Nothing surprising, then.

> $ telnet 127.0.0.1 5555
>
> Then I get the expected response in zero time.

There you are - broken /etc/hosts. It's a name resolution issue.
And hosts.allow probably doesn't allow your access from your hostname,
nor does xinetd. Read logs and know more.

> The file /etc/hosts contains the following: (I changed
> the actual IP addresses and names, but other than that
> this is verbatim what the /etc/hosts file contains)
>
> --- FILE CONTENTS BEGIN ---
> # Do not remove the following line, or various programs
> # that require network functionality will fail.
> 127.0.0.1 localhost.localdomain localhost

And where is the entry for your own hostname (a FQDN)?


> 1.2.3.4 www.domain.com
> 1.2.3.5 secure.domain.com
> 1.2.3.6 mail.domain.com
> --- FILE CONTENTS END ---
>
> The file /etc/host.conf contains a single line:
>
> order hosts,bind
>
> Can you think of something that could explain this

Yes - broken /etc/hosts, hostname, etc. Even hosts.allow/deny
and xinetd.conf in combo with broken hostname, domainname, etc.

Peter

Carlos Moreno wrote:
>
> [...]
> I log on to the server (it's a "dedicated server" that
> we're renting from a web hoster -- it has "direct"
> connection to the net, with a static IP address), and
> type the command:
>
> $ telnet localhost 5555
>
> For about ten seconds I have no reply. Then, I get the
> expected:
>
> Trying 127.0.0.1...
> telnet: connect to address 127.0.0.1: Connection refused
> [...]

BTW, the problem is intermittent (has been intermittent
for about one or two weeks). I try now, the problem shows;
try three hours later, works fine. Try tomorrow morning,
works fine. Tomorrow afternoon, again the problem shows,
etc. etc.

Carlos
--