The domains in question do have MX records, but the DNS lookup failures end up giving us A records only, and then exchange tries to deliver to the A record address, which accepts mail for a different domain.
We've offered logging; we need them to approve the costs first... No bind in this org. Someone sent me a note about a known issue with the Watchguards. I'm going to look at that today... *********************** Charlie Kaiser [email protected] Kingman, AZ *********************** > -----Original Message----- > From: Ben Scott [mailto:[email protected]] > Sent: Wednesday, April 29, 2009 7:34 PM > To: NT System Admin Issues > Subject: Re: DNS issue > > If a domain name has no MX records, but does have A > records, then SMTP MTAs are supposed to treat the domain as > if it had specified the hosts at those A records as the mail > exchangers. This is per the relevant RFC. > > Does it happen for "all" domains, or just some? > > As someone else said, query logging would be good. Another > thing to try is a packet sniffer. (Sometimes that's even > better, because you might see stuff that the person > programming an application's logging routines didn't think > was relevant.) > > In the NT 4.0 days, I sometimes fixed deficiencies in the > NT 4.0 DNS server by having it forward all DNS queries to a > local ISC BIND "named" resolver which then did the > Internet-facing stuff. The MS DNS server was much improved > in Win 2000, but it's a thought if you get desperate. > > > What I'm trying to find out is this: Is there a way to prevent > > server-side caching of negative replies to remote DNS queries? > > The normal control for this is the "minimum TTL" field from > the SOA record of the zone being queried. > > Microsoft's documentation seems to imply that they just use that: > "The Windows 2000 DNS server caches negative responses > according to the minimum TTL in the SOA record. However, it > cannot be less than one minute or greater than 15 minutes." > > (http://technet.microsoft.com/en-us/library/cc959309.aspx) > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource > hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
