DNS-Problem mit Postfix nach Backbonewechsel

[orinoco]

Hi,

mein Zugangsprovider hat auf einen neuen Backbone und folglich andere
DNS-Server umgestellt.
Seitdem habe ich folgendes Domainauflösungs-Problem mit postfix:
Aus dem mail-log:


Dec 18 15:45:47 postfix/smtpd[28905]: connect from unknown[193.99.144.71]
Dec 18 15:45:48 postfix/smtpd[28905]: NOQUEUE: reject_warning: RCPT from unknown[193.99.144.71]: 450 <forumbounce@heise.de>: Sender address rejected: Domain not found; from=<forumbounce@heise.de> to=<localpart@exampledomain.com> proto=ESMTP helo=<web.heise.de>
Dec 18 15:45:48 postfix/smtpd[28905]: 487C6A0C0D: client=unknown[193.99.144.71]
Dec 18 15:45:48 postfix/cleanup[28906]: 487C6A0C0D: message-id=<midXXXXXXXXXXXX@web.heise.de>
Dec 18 15:45:48 postfix/qmgr[26587]: 487C6A0C0D: from=<forumbounce@heise.de>, size=1588, nrcpt=1 (queue active)
Dec 18 15:45:48 postfix/local[28907]: 487C6A0C0D: to=<localpart@exampledomain.com>, orig_to=<localpart@exampledomain.com>, relay=local, delay=1, status=sent (delivered to <mailbox>)
Dec 18 15:45:48 postfix/qmgr[26587]: 487C6A0C0D: removed
Dec 18 15:45:48 postfix/smtpd[28905]: disconnect from unknown[193.99.144.71]


Der Knackpunkt ist die zweite Meldung
------------

Dec 18 15:45:48 postfix/smtpd[28905]: NOQUEUE: reject_warning: RCPT
from unknown[193.99.144.71]: 450 <forumbounce@heise.de>: Sender
address rejected: Domain not found; from=<forumbounce@heise.de>
to=<heise@exampledomain.com> proto=ESMTP helo=<web.heise.de>
-----------
aufgrund der Einstellung in der main.cf
-----


smtpd_sender_restrictions =
warn_if_reject,
reject_unknown_sender_domain,

-----

Offensichtlich kann postfix den Domainnamen nicht auflösen. Das ist
in vielen Fällen seit der Umstellung so, also bei Servernamen, die
offensichtlich keine Phantasiedomains von Spammern sind (wozu ja
reject_unknown_sender_domain ja da ist und eine
Domainnamenüberprüfung ist wohl auch für greylisting mit postgrey
notwendig)

Man könnte jetzt also meinen, dass irgendwas mit dem DNS-Server nicht
stimmt (weil der ja ein anderer ist). Aber:
-------------
# nslookup -type=MX heise.de
Server: 194.97.173.124
Address: 194.97.173.124#53

Non-authoritative answer:
heise.de mail exchanger = 10 relay.heise.de.

Authoritative answers can be found from:
relay.heise.de internet address = 193.99.145.50
----------------------

Daran kann's also auch nicht liegen. Auch mit anderen DNS-Server in
der resolv.conf Datei bleibt das Problem das gleiche.

Auch das Versenden von mails von diesem Server funktioniert nicht mehr
aus dem mail-log:

Dec 19 01:14:35 postfix/qmgr[26861]: DEE41A1754: from=<root@example.com>, size=465, nrcpt=1 (queue active)
Dec 19 01:14:36 postfix/smtp[26974]: DEE41A1754: to=<localpart@hotmail.com>, relay=none, delay=1, status=bounced (Host or domain name not found. Name service error for name=hotmail.com type=A: Host found but no data record of requested type)

Von einem anderen Rechner im lokalen Netzwerk ist das Versenden von mails problemlos mit dem lokalen sendmail möglich.

Vor der Backboneumstellung hat alles einwandfrei geklappt, bzw. an den Konfigurationsdateien main.cf etc. wurde nichts geändert.
Ich vermute, dass postfix irgendwo alte und damit falsche DNS-EInstellungen verwendet. resolv.conf kann es jedenfalls nicht sein, weil dort habe ich schon die neuen DNS-Server IP-Adressen eingetragen bzw. jetzt schon mehrfach ausgetauscht.



nameserver 194.97.173.125
nameserver 194.97.173.124
nameserver 194.97.173.124 # ppp temp entry
nameserver 194.97.173.125 # ppp temp entry


Hab jetzt schon alles was im Internet mit diesen Fehlermeldungen, postfix, DNS etc zu tun hat abgegrast und keine Lösung gefunden.

Gruss

orinoco

Nochmal die komplette main.cf (was vorher einwandfrei funktioniert hat)


# These are only the parameters changed from a default install
# see /etc/postfix/main.cf.dist for a commented, fuller version of this file.

# These are changed by postfix install script
readme_directory = /usr/share/doc/postfix-2.2.5/README_FILES
html_directory = /usr/share/doc/postfix-2.2.5/html
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
command_directory = /usr/sbin
manpage_directory = /usr/share/man
daemon_directory = /usr/lib64/postfix
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
queue_directory = /var/spool/postfix
mail_owner = postfix

# User configurable parameters

inet_interfaces = all
mynetworks_style = host

myhostname = mail.example.homelinux.net
mydomain = example.homelinux.net

delay_warning_time = 4h
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (Mandrake Linux)
unknown_local_recipient_reject_code = 550
smtp-filter_destination_concurrency_limit = 2
lmtp-filter_destination_concurrency_limit = 2
smtpd_sasl_path = /etc/postfix/sasl:/usr/lib64/sasl2
recipient_delimiter = +
owner_request_special = no
alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
mydestination = $myhostname, localhost.$mydomain, $mydomain
myorigin = example.homelinux.net
virtual_alias_domains = example1.com, example2.net, example3.de
virtual_alias_maps = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated

smtpd_sasl_auth_enable = yes
smtpd_sasl_application_name = smtpd
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain = $mydomain

smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_client_restrictions =
permit_mynetworks,
check_client_access
hash:/etc/postfix/access.client_reject,
permit
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access
hash:/etc/postfix/helo_access,
warn_if_reject,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
warn_if_reject,
reject_unknown_sender_domain,
check_sender_access
hash://etc/postfix/access.sender_special_permit,
check_sender_access
hash://etc/postfix/access.sender_special_reject,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_recipient_access
hash://etc/postfix/access.recipient_special_permit,
check_recipient_access
hash://etc/postfix/access.recipient_special_reject,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unlisted_recipient,
# check_policy_service inet:127.0.0.1:10031,
permit

[MiGo]

Hast du einfach mal einen Tag gewartet? DNS-Umstellungen können schon eine Weile brauchen, bis sie sich rumgesprochen haben.

[orinoco]

Hast du einfach mal einen Tag gewartet? DNS-Umstellungen können schon eine Weile brauchen, bis sie sich rumgesprochen haben.

Also die Benachrichtigung über die Umstellung hab ich schon letzte Woche bekommen, umgestellt wurde dann exakt Montag früh und nun warte ich schon seit 1 1/2 Tagen. Das kann aber eigentlich auch nicht sein. Wenn in der resolv.conf die neuen DNS-Server drinstehen, dann sollten eigentlich alle Programme das sofort "mitkriegen". Normales Surfen und alles andere klappt ja auch. Habe postfix schon x-mal neu gestartet - ohne Erfolg.

[heatwalker]

Läuft dein Postfix zufällig in einer chroot Umgebung?

Wenn ja, wird vermutlich die resolv.conf im chroot nicht geändert.

[orinoco]

Läuft dein Postfix zufällig in einer chroot Umgebung?
Wenn ja, wird vermutlich die resolv.conf im chroot nicht geändert.

Ja, habe es eben überprüft und das ist der Fall. Und es hat in der chroot Umgebung auch eine resolv.conf mit alten Einträgen gegeben, die letztmalig am 2.11. geändert wurde, also relativ selten aktualisiert ist und auf Backboneumstellungen nur schlecht vorbereitet ist. Scheint das Problem gewesen zu sein. Fehlermeldung tritt bei den ersten Testmails nicht mehr auf. Werde wohl einen cronjob erstellen der die resolv.conf Dateien regelmäßig abgleicht. Obwohl es könnte ja auch eine Sicherheitslücke sein, wenn sie automatisch abgelichen werden (deswegen macht man ja das mit dem chroot) aber eine diff-notification mail ist sicher nicht verkehrt.
Vielen Dank für den Tip.

[heatwalker]

Normalerweise werden die notwendigen Daten in das chroot Verzeichnis
exportiert.

Müsste in /etc/init.d/postfix ensprechend eingetragen sein.

Hier mal ein Auszug:

# see if anything is running chrooted.
NEED_CHROOT=$(awk '/^[0-9a-z]/ && ($5 ~ "[-yY]") { print "y"; exit}' /etc/postfix/master.cf)

if [ -n "$NEED_CHROOT" ] && [ -n "$SYNC_CHROOT" ]; then
# Make sure that the chroot environment is set up correctly.
oldumask=$(umask)
umask 022
cd $(postconf -h queue_directory)

# if we're using unix:passwd.byname, then we need to add etc/passwd.
local_maps=$(postconf -h local_recipient_maps)
if [ "X$local_maps" != "X${local_maps#*unix:passwd.byname}" ]; then
if [ "X$local_maps" = "X${local_maps#*proxy:unix:passwd.byname}" ]; then
sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd > etc/passwd
chmod a+r etc/passwd
fi
fi

FILES="etc/localtime etc/services etc/resolv.conf etc/hosts \
etc/nsswitch.conf"
for file in $FILES; do
[ -d ${file%/*} ] || mkdir -p ${file%/*}
if [ -f /${file} ]; then rm -f ${file} && cp /${file} ${file}; fi
if [ -f ${file} ]; then chmod a+rX ${file}; fi
done
rm -f usr/lib/zoneinfo/localtime
ln -sf /etc/localtime usr/lib/zoneinfo/localtime
rm -f lib/libnss_*so*
tar cf - /lib/libnss_*so* 2>/dev/null |tar xf -
umask $oldumask
fi

[orinoco]

Normalerweise werden die notwendigen Daten in das chroot Verzeichnis
exportiert.

Müsste in /etc/init.d/postfix ensprechend eingetragen sein.

Hier mal ein Auszug:
[...]

Ich hab hier ein Mandriva 2006 System, da ist das etwas anders organisiert.
/etc/init.d/postfix ruft bei jedem Neustart des Servers /usr/sbin/postfix-chroot.sh auf und darin ist wohl ein Fehler der die Dateien nicht aktualisiert. Gibt auch kein Fehlerkorrektur Update dafür, aber in Mandriva 2007 ist der Fehler wohl nicht mehr drin, denn da klappt es und postfix-chroot.sh sieht auch anders aus. Danke nochmal für die Hilfe.

[heatwalker]

Gerne doch. :)