Domain of sender address does not resolve ?
in [Sendmail]
|
Prev: starttls errors
Next: 554 5.7.1 Command rejected
From: James Fagan on 22 Sep 2007 22:28 Bill Cole wrote: > In article <1190329385.146805.233620(a)e34g2000pro.googlegroups.com>, > proftpd(a)gmail.com wrote: > >> Hello, >> >> I am using sendmail as a gateway for spam/virus filtering for several >> domains. This has been working great until about a week ago when I >> noticed the outgoing queue (mail to the domains witch I filter for) >> started to grow. I am seeing allot of errors regarding "Domain of >> sender address user(a)cox.net does not resolve" >> >> Where the domain in question really is cox.net the username will vary. >> This is the only domain that for some reason sendmail can't seem to >> resolve. >> >> Here is a sample: >> Sep 20 15:40:00 nospam1 sendmail[15290]: l8H0itPK031395: >> to=<user(a)alexabercrombie.com>, delay=3+21:54:59, xdelay=00:00:00, >> mailer=smtp, pri=35137092, relay=[64.18.194.87], dsn=4.0.0, >> stat=Deferred: 451 4.1.8 Domain of sender address user(a)cox.net does >> not resolve > > Note that this is the MTA at 64.18.194.87 having a domain resolution > problem, and it is telling the sendmail instance generating that log > line that it cannot resolve cox.net in some probably transient way, i.e. > a DNS query timeout, not an explicit NXDOMAIN response. > > It isn't exactly clear whether resolution on 64.18.194.87 is what you're > trying to diagnose here... > > >> I am running named on the same machine as a local caching name server >> for faster response times. Here is the output from "dig cox.net" >> >> ; <<>> DiG 9.2.4 <<>> cox.net >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13980 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;cox.net. IN A >> >> ;; ANSWER SECTION: >> cox.net. 84290 IN A 68.1.17.9 >> >> ;; AUTHORITY SECTION: >> cox.net. 84290 IN NS ns.west.cox.net. >> cox.net. 84290 IN NS ns.cox.net. >> cox.net. 84290 IN NS ns.east.cox.net. >> >> ;; Query time: 13 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: Thu Sep 20 15:44:31 2007 >> ;; MSG SIZE rcvd: 102 > > That's less important than the MX record for cox.net, but that also has > valid resolution with suitably long TTL's. DNS should not be breaking. > > [...] > >> As far as I can see sendmail _should_ be able to resolve the domain. > > Yes, but if you are not looking at how the receiving MTA on 64.18.194.87 > is doing resolution, you aren't looking at the right place. This is not > clear to me... > >> Here are the steps I have taken in order to allow these messages to >> pass onto the customers. >> >> I have added the following to my /etc/mail/access file, then rebuilt >> the db. >> From:cox.net OK >> cox.net OK >> >> Result =NG >> >> I have added cox.net to my /etc/hosts file then restarted sendmail. >> >> Result =NG >> >> I have added the following to my /etc/mail/sendmail.mc file and >> rebuilt the .cf file and restarted sendmail. >> >> define(`confBIND_OPTS',`WorkAroundBrokenAAAA') >> FEATURE(accept_unresolvable_domains) >> LOCAL_CONFIG >> O Timeout.hoststatus=10m >> O HostStatusDirectory=.hoststat >> C{ResOk}TEMP >> >> Result =NG > > If you are doing this to the sendmail that generated the cited log line, > you are hitting the wrong sendmail over the head with a bat it does not > deserve, and probably doing so to its detriment. > accept_unresolvable_domains is evil. > > >> I am at a loss. So far nothing I have tried has worked. Also I think >> it is important to note that some mail from "cox.net" will pass along >> just fine to the customer. So its not all mail, but at least some of >> it that is getting stuck. I am running >> >> CentOS 4.5 2.6.9-55.0.2.ELsmp >> Sendmail 8.13.1 > > You should upgrade that. I'm not convinced that the security issue it > has is deadly, and the bug fixes are not universally expressed, but it > is a bit old. > > 64.18.194.87 is running 8.12.10, or at least its banner says that. > This implies some serious administrative laxness there.... > >> BIND 9.2.4 > > Upgrade that. Really. > >> Any ides, thoughts, suggestions ? > > Wild ideas: does 64.18.194.87 have TCP port 53 firewalled in any way? > Does it have a well-performing resolver? It is conceivable that the DNS > response is taking just about as long as the resolver timeout on that > machine. > Bill, Thanks for your insight. I was under the impression that the messages were coming from the smtp gateway machine directly, not the machine at 64.18.194.87. No wonder things weren't working! GAH! There indeed was a problem that 64.18.194.87 was having with the DNS server it was using. In fact it turned out that allot of the machines were using the same DNS server and it was unable to resolve allot of domains, it just happened to be the cox.net ones that were choking the system. I have since changed these and things are back to normal now. I was beating the gateway to death :(. All my evil deeds have been reversed :) According to CentOS all the packages are up to date. I had assumed that the receiving mail server would not perform a DNS lookup. Bad me. Lesson learned. For the next guy. Make sure that all your mail receiving servers can perform the lookup against the sending domain. James |