My two cents ... John and Matt are offering sound "best practices advice" for installing a cacheing only DNS on your Windows 2000. It's dead easy, and you'll find that your queries to find mail servers and RBL answers are faster.
"Cacheing only" means that this DNS service on your Imail server won't be responsible for serving up any zones, so you don't need to worry about messing that up. If you're worried about the bad guys (of course!), you can easily configure the service to only accept queries from your internal machines by IP, and/or use your firewall to block inbound queries. I tested using the nameserver you cited to look up ucancap.org and found that it could timeout, but once I got the record, it would be cached for 24 hours. I found that the reply came by UDP, was less than 512 bytes, and nicely included the IP address of the MX host along with the MX record. I noted that, at least from my network, I had really good tracert times (but they block ICMP). Their mailhost is slow to respond; reaching them, I see that their HELO greeting is "barracuda.ucancap.org" so I'd have to wonder how long they've had an antispam device from barracuda.com in front of their real mail host, and is this when you stopped being able to send them mail? ... I just did some nslookup tests using ns1.dnswizards.com and also ns2.dnswizards.com and get hinky results, with ridiculous timeouts. I'd suggest that if nothing else, you stop using them for your DNS queries! Andrew 8) > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Orin Wells > Sent: Wednesday, November 30, 2005 8:09 AM > To: Declude.JunkMail@declude.com > Subject: Re: [Declude.JunkMail] OT - At wits end > > At 11:03 PM 11/29/2005, Dave Doherty wrote: > >Hi, Orin- > > > >A couple of suggestions.... > > > >First, look at your HOSTS file in > c:\winnt\system32\drivers\etc to see > >if 64.62.134.10 is listed there. Delete the entry if you > find it there. > > Thanks. Done that. Nothing there. > > > >Next, add DNS service to your IMail server. > > I have been hesitant to do our own DNS services because of > others who have told me doing your own DNS can become a full > time job. I am assuming they are talking about a registered > DNS server when every hacker in the world wants to play with > it. I hadn't thought about activating DNS though. We are > running a 2000 server and I would have to figure out how to > turn it on. We will be going to 2003 soon if we can ever get > the servers running correctly. I hate hardware!! > > >Set the DNS servers in Network Properties to known-good upstream DNS > >resolvers. > > Other than this, the primary servers for all our domains are > thought to be good. I believe they have another server we > could add to the stream. > > >Set the DNS address in IMail to 127.0.0.1. This has the effect of > >providing mulitple DNS servers to IMail. > > Ahhh. That was a piece I was missing here. We have > 64.85.13.6 which is the primary DNS server. Will this then > use the servers in Network Properties or is it going to > expect the local server to be providing DNS services? > > Thanks for the suggestions. > > > >-d > > > > > >----- Original Message ----- From: "Orin Wells" > <[EMAIL PROTECTED]> > >To: <Declude.JunkMail@declude.com> > >Sent: Wednesday, November 30, 2005 1:35 AM > >Subject: [Declude.JunkMail] OT - At wits end > > > > > >>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. > > --- > [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.
