On Wed, Oct 06, 2010 at 09:23:10AM -0700, Mark
Hamilton wrote:
I don't know if this issue has already
been discussed but I didn't see
it after a quick search. I installed perdition 1.18 and set it up.
Everything worked fantastic including ssl etc... Then I started seeing
some errors like in the subject line above. After turning on debugging
I saw a mention of a temporary failure in dns before the connection
failed. I tested it myself by putting my ipad in an ip block that did
not have a dns server resolving the reverse lookup. It failed. I added
the block to a dns server where it was expected and it worked fine.
Since I don't have access to everyone's reverse ip I tried adding one
client to the hosts file on the server running perdition and it seemed
to fix the issue as well. I have an older version, 1.17, that does not
seem to have a problem with ips that do not have a proper dns server set
up. Is there anyway to stop this from happening?
Hi Mark,
that is rather curious. I would be interested to see some more of the log
messages surrounding the error, particularly with the debug configuration
option enabled. And to know if the same problem occurs in 1.19-rc4.
Although I'm not having much luck reproducing this problem I suspect that
the no_lookup configuration option can be used as a work-around.
Ok, I spawned a copy of the perdition server in vmware so I could poke
at it without making users upset. I then removed the network from the
dns server again. This is what I got:
Oct 6 23:05:14 mail perdition[4803]: Connect: xx.xxx.xx.x->xx.xxx.xx.xx
Oct 6 23:05:15 mail perdition[4803]: SSL connection using AES256-SHA
Oct 6 23:05:15 mail perdition[4803]: greeting_str: getnameinfo
peername: Temporary failure in name resolution
Oct 6 23:05:15 mail perdition[4803]: greeting: greeting_str
Oct 6 23:05:15 mail perdition[4803]: main: greeting
Oct 6 23:05:15 mail perdition[4803]: Fatal error writing to client
xx.xxx.xx.x->xx.xxx.xx.xx.Exiting child.
Oct 6 23:05:24 mail perdition[4804]: Connect: xx.xxx.xx.x->xx.xxx.xx.xx
Oct 6 23:05:24 mail perdition[4804]: SSL connection using AES256-SHA
Oct 6 23:05:24 mail perdition[4804]: greeting_str: getnameinfo
peername: Temporary failure in name resolution
Oct 6 23:05:24 mail perdition[4804]: greeting: greeting_str
Oct 6 23:05:24 mail perdition[4804]: main: greeting
Oct 6 23:05:24 mail perdition[4804]: Fatal error writing to client
xx.xxx.xx.x->xx.xxx.xx.xx.Exiting child.
Then as you suggested I turned on the no_lookup option and the problem
went away. If you do a lookup on the ip address that is in a block that
is not configured in a name server you get:
Host x.xx.xxx.xx.in-addr.arpa not found: 2(SERVFAIL)
I thought that the SERVFAIL may be the key so I put everything back and
duplicated the failure. Then I put the net block in the name server but
did not give the ip a PTR record. At this point a lookup in the name
server gives:
Host x.xx.xxx.xx.in-addr.arpa. not found: 3(NXDOMAIN)
Still a not found but no fail. I tried the connection to perdition and
everything was happy. There were no logs about resolution. It looks
like things get scared when the see the fail even though it doesn't seem
to need an answer.
Thank you very much for your time Mr Horman and I have an acceptable
solution with the no_lookup option.
Mark