Re: [cobalt-users] gethostbyname

[shimi <shimi@xxxxxxxxxxxxxxxx>]

On Wed, 20 Jun 2001, Carrie Bartkowiak wrote:

> Hey guys,
> I'm getting this error, which is making me do the RCA puppy stare at
> my monitor:
> Jun 20 14:19:09 www in.qpopper[17007]: warning: /etc/hosts.deny, line
> 21: can't verify hostname:
> gethostbyname(lantepool.lante.com.29.85.63.in-addr.arpa) failed
> 
> Here's line 21 of hosts.deny:
> ALL: .t-dialin.com
> 
> They seem like two different beasts to me. This happens whenever a
> certain client connects via FTP.
> Any advice? A search through the archives is conflicting; one post
> tells me that having .t-dialin.com in the hosts.deny is okay, another
> post tells me it should only be numerical IPs in hosts.deny (this is
> doing a search for 'gethostbyname').
> This is the only client that this happens with, and he can connect and
> upload files just fine - just causes logged errors when he does.

I'll assume .t-dialin.com is the FIRST host-represented address (NonIP).
When qpopper wants to check if you can connect or not, i.e., you're listed
in hosts.allow/deny etc etc, he starts comparing each rule and rule in the
file to the connecting IP.

As long as there are IPs, this process is automatic.

Now, he got to a hostname. What do we do? We must know the hostname of the
connecting person, right?

As you know, there are A records, and PTR records, one for resolving
hostnames into IP addresses, and one for resolving IP addresses back to
hostnames, corresp.

So first we lookup the hostname from his IP. Ok, we GOT a hostname, but
wait, what if it's a script kiddie who has a control over the reverse DNS
for his IP, and for the fun made it resolve to microsoft.com? uh-uh, tough
luck!

So, we do the other way around, we resolve the hostname we recieved from
the previous query to get the hostname's real IP address. If they match,
the rule in hosts.deny is being compared to and no further resolves of
that IP will happen (cached) until the end of the ruleset.
If they DON'T much - well, I'm sure you understand :-)

> CarrieB

You have great questions, Carrie :-)

- shimi.

P.S. yes I know that your message describes an error on the first stage of
IP verification, I just wanted to explain why this verification happens
from the first place, and the relation to line 21.