Orin,
I have seen these issues in relation to EDNS0 being enabled on one of
the servers. While most servers and firewalls will work perfectly with
EDNS0 enabled, there are certainly some that will produce consistent
failed lookups. EDNS0 is a new way of doing DNS lookups by sending more
data in a single packet, but some older software sees this as invalid or
an attempted exploit and rejects these packets. It does not fall back
effectively.
One possibility is the server that IMail is querying is based on Windows
2003 DNS and has EDNS0 enabled. This can happen with an old firewall as
well as older versions of BIND. If so, they definitely should disable
it, and instructions can be found here:
http://support.microsoft.com/kb/828263
Since you are running your own mail server, you should also definitely
consider turning DNS on for your own server so that you don't have to
rely on others. If you are using Windows 2003, then you should follow
the above instructions regardless of whether or not you see any
problems. In the long-run you just simply can't rely upon someone
else's server like this, and by installing it on your IMail/Declude box
it will not require you to also host DNS records...it can cache-only.
Setup of Microsoft DNS is super easy, and you can point both IMail and
Declude at it by using 127.0.0.1 as the IP to query.
The other advice given so far could also net good results, but doing it
yourself will very likely fix the problem and make you self-sufficient
from here on.
Matt
Orin Wells wrote:
We have a bit of a puzzler with one our clients in trying to
communicate with another domain. What happens is they get 20 attempts
failure to deliver. What is REALLY happening is that the DNS servers
that service our environment do not see the target domain for some
unknown reason and thus iMail is unable to resolve the domain to an ip
address for delivery. And since our imail server is pointing to one
of these DNS servers as our primary server I have been unable to find
a way around the problem.
It seems to have started on or about November 9th when the firewall at
the target site received the last message from our server. We think
something changed but no one will admit to anything changing.
The sending environment is running under iMail 7.07 and is
cado-oregon.org (IP 64.85.18.53). There are two dns servers providing
our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and
64.85.14.6). The first is what iMail has as the designated DNS
server. No domain on our server can send email to the domain
ucancap.org (ip 64.62.134.10) - this actually ends up going to a
domain called altrue.he.net which apparently hosts their website.
This is odd, but they are happy with it and it is not the problem.
Their mail is hosted on their own exchange server and the mx record at
the destination hosting company shows it going to mail.ucancap.org (IP
216.110.199.124). The remote hosting DNS server is
ns1.douglasfast.net (IP 216.110.195.3)
I thought out of desperation that if I added an outside DNS server to
the list used by our mail server that iMail would trip down to it and
find the target. I first tried a qwest.net DNS server and I thought
it was going to work until I got back a message saying the destination
email address was not valid (no relaying). I thought that odd so I
replaced the server with the douglasfast.net dns server. I was right
back to where I started wondering why anything different happened when
the Qwest sever was in place because it appears iMail only knows about
a single DNS server. The one entered in iMail itself. I am not about
to make the douglasfast.net server our primary dns server to solve
this for a single client.
Now it appears our DNS servers see every known domain in the world
except any behind this service (douglasfast.net - which is an electric
company offering network services in Roseburg, OR). And apparently
every DNS server in the world can see their domains except ours.
The two ISPs are apparently not eager to talk to each other to help
resolve the problem so we have the usual "the problem has to be on
their end" finger pointing. And I don't have the experience to try to
figure out why the DNS servers at our server farm can not talk to the
DNS servers at the destination site or even to spot the real problem.
It does not appear to be an issue of IP blocking as such because I can
telnet into the destination mail server from within our server (behind
the 64.85... ) using their ip address. Both ends have verified that
there is no IP blocking going on at fire walls, routers or in the
Exchange server - or they have claimed to have checked this. I can
also see their domain from my workstation that is connected to
qwest.net. Why do the qwest DNS servers work OK and the DNSWizards do
not? The folks at our server farm have tried a variety of tests,
cache flushes and re-acquisitions along with a lot of other things and
have not figured out what is going on nor made any headway.
If you use dnsstuff.com on the douglasfast.net DNS servers the results
are sometimes odd. There are some "FAIL" issues indicating there are
some timing problems on the server (using DNSReport.com). Checking
for the MX records seems to correctly identify the mail server (DNS
Lookup).
The other day when I looked for the reverse DNS for the mail server it
came back with an error, but I see it is working fine tonight.
Checking DNS timing always returns 250 + ms and a grade of "F". I do
not know the significance of this. Could it be the reason our DNS
server can not get a good fix on this? But why (apparently) just the
dnswizards servers? Why not everybody else?
Can someone a little brighter than I am take a look and tell me if you
see anything that could be contributing to this problem? If anyone
can even suggest a reasonable work-around until this resolves itself
(my bet is on or about December 9th)?
If you can see the problem, please give it to me an a way I can convey
it to the party that has the problem and maybe get them to fix it.
---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
