[erledigt] spamhaus RBL / open resolver / wichtige eMails verworfen

Hallo, ich wollte eigentlich Spamhaus verwenden als RBL in meiner postfix config:

smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
#check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
#check_helo_access dbm:/etc/postfix/helo_checks,
check_sender_access hash:/etc/postfix/sender_access
#check_client_access dbm:/etc/postfix/client_checks,
#check_client_access pcre:/etc/postfix/client_checks.pcre,
#reject_rbl_client cbl.abuseat.org,
#reject_rbl_client sbl.spamhaus.org,
#reject_rbl_client pbl.spamhaus.org

Allerdings habe ich die wie man sieht deaktiviert, denn ich hab jede Menge wichtiger eMails nicht mehr erhalten:

Aug 8 16:33:03 server postfix/smtpd[24458]: NOQUEUE: reject: RCPT from a71-51.smtp-out.amazonses.com[54.240.71.51]: 451 4.7.1 Service unavailable; Client host [54.240.71.51] blocked using pbl.spamhaus.org; Error: open resolver; https://check.spamhaus.org/returnc/pub/74.63.24.222/; from=<0100019889f549ad-4aadcdd4-d204-4426-8084-52d630b2ab94-000000@amazonses.com> to=<xxx@xxx.de> proto=ESMTP helo=<a71-51.smtp-out.amazonses.com>

Ich verwende die dns server von netcup und habe auch einen unbound bei mir auf dem Server laufen als caching.

Was tun?

root@mydomain:/etc/spamassassin# resolvconf -l
# resolv.conf from lo.unbound
nameserver 127.0.0.1
# resolv.conf from ens3.inet
nameserver 127.0.0.1
nameserver 9.9.9.9
# resolv.conf from ens3.dhclient
nameserver 46.38.225.230
nameserver 46.38.252.230

kannst du mir sagen wie ich das einrichte? Hab den unbound eigentlich eingerichtet, kann auch abfragen stellen, aber irgendwie gehen die trotzdem noch alle über ens3.dhclient's gelistete, weil ich erhalte noch immer die Block-Meldung.

meine /etc/network/interfaces hat das hier drin:

iface ens3 inet dhcp
dns-nameserver 127.0.0.1
dns-nameserver 9.9.9.9

Eigentlich sollte das doch dann die von netcup ignorieren...?

Ich nutze auch Postscreen. Ich weis nicht, was das mit dem Thema zu tun hat. Es geht aktuell um DNS-Probleme, da scheinbar weiterhin der DNS Server von netcup verwendet wird und nicht meiner auf localhost.

wenn ich dig google.com ausführe, sehe ich am ende

;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)

trotzdem der fehler von spamhaus...

in der resolv.conf steht nur "nameserver 127.0.0.1", sieht also einwandfrei aus. Was mir aufgefallen ist, ich verwende resolvconf, nicht systemd-resolve. Werde nachher umstellen. Vermute, das ist ein Überbleibsel. Hab den Server vor 12 Jahren oderso eingerichtet... inzwischen ist ja alles systemd *kotz*, aber das ist ein anderes Thema...

Zitat von NaN

Die Lösung steht in der ersten Antwort.

Die Lösung ist mir bekannt und genau da möchte ich hin.

Blos wie.

Meine unbound config:

server:
root-hints: "/etc/unbound/root.hints"
use-syslog: yes
log-queries: yes
log-replies: yes
verbosity: 1
interface: 127.0.0.1
port: 53
cache-min-ttl: 3600
cache-max-ttl: 86400
do-not-query-localhost: no
num-threads: 2
rrset-roundrobin: yes
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
qname-minimisation: yes
hide-identity: yes
hide-version: yes

Wie kann ich prüfen, ob unbound als caching oder recursive arbeitet?

edit: gerade im #unbound gefragt, unbound arbeitet default als recursive resolver, nicht als caching.

Problem gefunden. Lag an resolvconf. Habe das Paket deinstalliert, systemd-resolve installiert und nun liefert mir auch dig +short whoami.v4.powerdns.org meine IP und nicht mehr die von netcup.

Zitat von NaN

Schau nach, welches Programm an Port 53 gebunden ist

unbound

Zitat von NaN

Und wenn du dich erinnern kannst, wie Quad9 in deine Konfiguration kommt, hilft das auch.

Wie erwähnt in #3 gehen die Anfragen NICHT über quad9 sondern über die von netcup.

dig +short whoami.v4.powerdns.org hat mir die IP von netcups DNS geliefert und nicht meine.

Zitat von NaN

Laut Kommentar #3 hast du den offenbar selbst in der /etc/network/interfaces eingetragen.

Richtig, als fallback.

> Der wird dann tatsächlich benutzt und daran scheitert die Abfrage der DNSBL.

Nein, der wird nicht benutzt wie in #11 geschrieben.

Zitat von Hille

Auch hier können eigene DNS Server definiert werden.

Das hatte ich auch versucht aber bin da irgendwie dran gescheitert. Egal was ich gemacht habe (mit resolvconf), der hat mir in resolvconf -l dauernd die netcup dns in en3 gelistet. Dann wurds mir jetzt einfach zu blöd...

Auch ist es scheinbar so, dass "die meisten" systemd-resolve verwenden. Ist wohl inzwischen Standard in den Distris, und dann schwimme ich halt mit dem mainstream mit.

Warum soll ich weiter mails verlieren wenn localhost jetzt verwendet wird

Zitat von NaN

So funktioniert das nicht.

Wieso? Wenn localhost als resolver nicht funzt, wird der 2te DNS genommen, so würde ich mal vermuten dass das funktioniert.

Zitat von H6G

Damit dürften sich deine Probleme lösen.

Genau das hatte ich versucht. Deswegen hab ich ja in den configs rumgewurstelt. Das hat nicht geklappt.

In meiner resolv.conf steht nun nach dem Wechsel:

nameserver 127.0.0.53
options edns0 trust-ad
search DOMAINS

Zitat von H6G

Von systemd-resolved kann ich nur abraten und würde es immer deaktivieren.

Wieso? Ich bin auch kein Fan von systemd, aber es ist halt - leider - Standard inzwischen. Vermute, wenn ich in #debian oderso nach Hilfe frage, werden mir die Leute eher helfen können, wenn Standards verwendet werden.

Zitat von H6G

Bei glibc ja,

Ich weis nicht wie die Debian-Pakete kompiliert werden, vermute jetzt aber mal, dass Debian standardmässig auf glibc setzt.

Vielleicht ist das auch einfach ein bug in resolvconf gewesen. Denn das einzige was ich angepasst habe ist resolvconf zu ersetzen, und nun klappt alles. Ganz ohne rumgewurstel in irgendwelchen configs.