On Fri, Mar 28, 2008 at 5:57 PM, Oscar Ricardo Silva
<osilva AT scuff.cc.utexas DOT edu> wrote:
>   /usr/local/amanda25/sbin/amrecover -C dailytoo
>  AMRECOVER Version 2.5.2p1. Contacting server on amanda.tn.utexas.edu ...
>  [request failed: amanda.tn.utexas.edu: ssh could not resolve hostname]
...
>  It's not really an issue with resolving the hostname.  DNS is setup correctly
>  and I can ssh from the client to the server and from the server to the 
> backup.
>  While running amrecover I see no queries being sent to the servers listed in
>  resolv.conf.  Even inserting the host into /etc/hosts doesn't help.  I've 
> looked
>  through the list archives and someone ran into this problem in October 2006 
> but
>  have not seen any other mentions of it.

You're right that this isn't from ssh.  The message should probably be
something like "ssh_security: could not resolve hostname".  What's
happening is that the ssh security driver is trying to resolve the
hostname to its canonical name before passing it to 'ssh'.  This is
done via a call to getaddrinfo with AI_CANONNAME set, which will
usually do a forward-and-reverse lookup to determine the actual name
of the host.

On a lark, I ran:
$ host amanda.tn.utexas.edu
amanda.tn.utexas.edu has address 172.16.124.162

Which is a leak of a private (RFC1918) address from a public DNS
server.  I had been expecting it not to resolve for me, or alternately
to resolve to an IP in one of utexas's public netblocks, in which case
I could test the reverse DNS.  Anyway, I expect that the given IP
isn't translating back to anything, which is causing the error.

Hopefully this is the hint you need to get this working.  I'll make a
note to fix up the error message a bit.

-- 
Storage Software Engineer
http://www.zmanda.com