[No siree - this is (probably) some other abnormal DNS weenie query ;-)]
We're behind a firewall and our parent company had their primary DNS server
fail.
Our DNS servers have forwarder entries pointing to theirs, and appear to be
functioning perfectly - except when it comes to sendmail and tcpserver
(hooked into qmail of course)
SMTP connections to our sendmail and qmail servers take over 80sec to return
a banner when connected to _from_ machines on our own LAN (i.e. whose info
is in our DNS - not the downed forwarder). Telnet/FTP/whatever from the same
hosts works fine as always with immediate DNS lookups being reported VIA
TCPD in syslog. All our LAN hosts just have our DNS servers in their
/etc/resolv.conf files.
Once the initial delay is over, sendmail and qmail acts as normal.
Any ideas why this is happening? Using strace I can see sendmail receiving
timeouts from DNS lookups - although I can't see what it's looking up. Being
on the client and doing a DNS lookup (PTR,A,MX) returns successfully
immediately - I can't work out why the downed forwarder DNS server is having
such a hit on these SMTP servers...
Do tcpserver and sendmail do some "special" DNS query that tcpd
(tcpwrappers) doesn't? I don't feel comfortable that an outage on a server
out of my control has affect my network...
[Final note: Their DNS server was just restarted and immediately the delay
disappeared - so this was definitely a DNS problem caused by an interaction
between their DNS server and ours].
Any ideas?
Sendmail-8.9.1a and Qmail-1.03 under RedHat-5.x/Linux-2.0.36.
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
