From: Y z on



----------------------------------------
> Date: Wed, 28 Apr 2010 15:20:08 +0800
> From: udippel(a)uniten.edu.my
> To: yankel(a)hotmail.com
> CC: stan(a)hardwarefreak.com; postfix-users(a)postfix.org
> Subject: Re: 'Domain not found' errors after Ubuntu upgrade
>
>
>>>> Start by making sure that these match:
>>>>
>>>> /etc/resolv.conf
>>>> /var/spool/postfix/etc/resolv.conf
>>>>
>>
>> Yup. Postfix start warns me if they differ.
>> I tried putting in nameservers there, but that makes it worse: then postfix (it's supposed to relay) accepts the messages, then can't find te relay domain, so it bounces them. Ouch.
>>
>>> ~$ /etc/init.d/postfix restart
>>>
>>
>>
>> Yup. Been starting and stopping for a while now. :-(
>>
>
> I had something similar a few days back, when - duh - all my incoming
> mail got stuck for the same reason. I knew about the two resolv.conf,
> but nothing helped.
> Then I tried some dig another.domain.com MX, and it timed out, while dig
> another.domain.com didn't. Once name resolution of MX was back, postfix
> was back after a restart. I dunno, if it was a bad coincidence, though I
> didn't like it all too much.
>
> Good luck,
>
> Uwe

I'm sure (well, almost sure) that bind got hosed *somehow*. Postfix really doesn't have more than a bit part in this drama. I just want to figure out why Postfix gets different answers than dig at the command prompt. Lack of sleep doesn't help. :-)



_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox..
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3
From: Stan Hoeppner on
Y z put forth on 4/28/2010 2:08 AM:
>
> ----------------------------------------
>> Date: Wed, 28 Apr 2010 01:56:55 -0500
>> From: stan(a)hardwarefreak.com
>> To: postfix-users(a)postfix.org
>> Subject: Re: 'Domain not found' errors after Ubuntu upgrade
>>
>> Stan Hoeppner put forth on 4/28/2010 1:50 AM:
>>> Y z put forth on 4/28/2010 1:36 AM:
>>>
>>>> Where do I start troubleshooting?
>>>
>>> Start by making sure that these match:
>>>
>>> /etc/resolv.conf
>>> /var/spool/postfix/etc/resolv.conf
>
> Yup. Postfix start warns me if they differ.
> I tried putting in nameservers there, but that makes it worse: then postfix (it's supposed to relay) accepts the messages, then can't find te relay domain, so it bounces them. Ouch.

I've only ever had this name resolution problem once and that's how I solved
it, with hints from this list.

> Yup. Been starting and stopping for a while now. :-(

Did you check nsswitch.conf for 'dns' under 'hosts'?

Something broke Postfix' ability to resolve dns. It's not complaining about
a library version error, which points to configuration only. Make sure
SELinux is _not_ enabled. Turn off any iptables rules you have loaded.


--
Stan

From: Uwe Dippel on
Y z wrote:
>
> I'm sure (well, almost sure) that bind got hosed *somehow*. Postfix
> really doesn't have more than a bit part in this drama. I just want to
> figure out why Postfix gets different answers than dig at the command
> prompt.

Relax.
I am sure you did
dig that.other.mail.org MX.
Then the answer can't be different among postfix and command prompt.
If the two resolv.conf are identical. If need be (and some will jump
into my face) our little helper is 'cp' for identical results (and
resolvers) to get some mails delivered as long as the resolution on the
command line is satisfying. (That's what I did on Monday morning when
the queue was overflowing and the dreaded warning about them being
different came up. Luckily, here 'cp' worked.)

And I still have the desire to understand, why the resolvers could
become different over the weekend; when the name resolution(s) for MX
failed. I can't believe 'because of' the MX reolution(s) failed, and
yet/var/spool/postfix/etc/resolv.conf was just empty.
'Restart' had not helped. Only when the resolution was back, would the
two be identical again. Very strange.

Uwe

First  |  Prev  | 
Pages: 1 2
Prev: Postfix logging to syslog
Next: false positives