Page 3 of 3
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sat 17. Dec 2022, 19:01
by Ralph
24unix wrote: ↑Sat 17. Dec 2022, 18:45
Wobei ich selber so Kram nicht nutze, habe keinen nennenswerten Spam.
Ja dann mal Gratulation!
Das ist leider bei den wenigsten der Fall und bei einem System wie z.b. einem shared Host schon gar nicht
24unix wrote: ↑Sat 17. Dec 2022, 18:45
Und, auch wenn man Google DNS befragt gibt es kein all.spamrats.com.
Es handelt sich ja um DNSBL queries die nicht über A-records abgefragt werden.
Spamrats ist nur einer davon der mir in den mail.logs aufgefallen ist, weitere Details (siehe oben).
Hier findest du eine Sammlung von aktuellen DNSBL wenn du eine Abfrage abschickst, davon verwende ich nicht die exotischen.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sat 17. Dec 2022, 19:12
by 24unix
Ralph wrote: ↑Sat 17. Dec 2022, 19:01
Es handelt sich ja um DNSBL queries die nicht über A-records abgefragt werden.
Das verstehe ich nicht.
Im Prinzip fragen die doch nur nach einer Domain und prüfen die Reputation?
Aber die müssen doch via Namen erreichbar sein, und all.spamrats.com gibt es halt nicht.
Wo ist "hier"?
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sat 17. Dec 2022, 19:33
by Ralph
24unix wrote: ↑Sat 17. Dec 2022, 19:12
Ralph wrote: ↑Sat 17. Dec 2022, 19:01
Es handelt sich ja um DNSBL queries die nicht über A-records abgefragt werden.
Das verstehe ich nicht.
Im Prinzip fragen die doch nur nach einer Domain und prüfen die Reputation?
Aber die müssen doch via Namen erreichbar sein, und all.spamrats.com gibt es halt nicht.
Wo ist "hier"?
hier z.b.:
https://spamrats.com/lists.php
https://barracudacentral.org/rbl
ich verwende nur die renommierten Anbieter derzeit ca. 6-8
https://mxtoolbox.com/problem/blacklist/spamhaus-zen
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sat 17. Dec 2022, 19:35
by Ralph
24unix wrote: ↑Sat 17. Dec 2022, 19:12
Wo ist "hier"?
sorry hier ist hier
https://multirbl.valli.org/lookup/
da werden so ziemlich alle DNSBL geprüft wenn du eine IP eingibst erscheint die Liste (ca. 230 Anbiter)
Re: DNSBL lookup probleme - SERVFAIL [GELÖST]
Posted: Sun 18. Dec 2022, 12:12
by Ralph
Heute morgen gab es keine DNSBL lookup errors mehr, auch nicht mit spamrats:
Code: Select all
Dec 18 10:02:56 host0 postfix/smtpd[386987]: NOQUEUE: reject: RCPT from mail.douanes.dj[196.201.192.211]: 554 5.7.1 Service unavailable; Client host [196.201.192.211] blocked using all.spamrats.com; SPAMRATS IP Addresses See: http://www.spamrats.com/bl?196.201.192.211; from=<gouled.ahmed@douanes.dj> to=<xxx.xxx.tld> proto=ESMTP helo=<mail.douanes.dj>
aber dafür "Domain not found" Fehler
Code: Select all
Dec 18 09:42:51 host0 postfix/smtpd[370198]: NOQUEUE: reject: RCPT from mta-2d56772e.ip4.emsmtp.com[45.86.119.46]: 450 4.1.8 <suite10@news.vitaminexpress.org>: Sender address rejected: Domain not found; from=<suite10@news.vitaminexpress.org> to=<xxx.xxx.tld> proto=ESMTP helo=<mta-2d56772e.ip4.emsmtp.com>
systemd resolve verwende ich normalerweise nicht,
funktioniert aber jetzt und ich lasse es drauf ...
Das Problem bei systemd resolve war die Verwendung von "DNSStubListener=yes" wodurch die resolve.conf diesen Inhalt verwendet:
Code: Select all
nameserver 127.0.0.53
options edns0 trust-ad
search .
Durch DNSStubListener=no treten bei der folgenden Config keine lookup errors mehr auf:
Code: Select all
DNS=Server-IP-Adresse NS-IPAdresse
FallbackDNS=127.0.0.1 ::1
Domains=~.
DNSSEC=allow-downgrade
DNSOverTLS=no
MulticastDNS=no
LLMNR=no
Cache=no-negative
DNSStubListener=no
ReadEtcHosts=yes
Die resolv.conf sieht dann in etwa so aus:
Code: Select all
nameserver Server-IP-Adresse
nameserver Andere-NS-IP-Adresse
search .
Um das Problem zu lösen ist das systemd resolve package
NICHT zwingend erforderlich, ich belasse es aber jetzt dabei.
Warum das lookup Problem nach den Neu Installationen unter Bullseye auftritt könnte eine Bind Macke sein, jedenfalls wenn der resolver richtig eingerichtet ist und lokal auflösen kann gibt es keine Probleme.
Von meiner Seite ist die Sache damit gegessen - also kein direktes KH config Problem.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 18. Dec 2022, 15:56
by tab-kh
So habe ich das ja im Wesentlichen auch. Mit resolvectl status düfte bei dir jetzt auch angezeigt werden:
Code: Select all
Global
...
resolv.conf mode: uplink
DNS Servers: 127.0.0.1
...
Nur dass ich bei mir eben kein Downgrade bei DNSSEC erlaube.
Ich lasse das jetzt auch erst mal so, falls keine Probleme auftreten. Über Weihnachten probiere ich dann mal Unbound direkt auf einem Keyhelp-Server. Dafür nehme ich aber einen neuen her.
4vCore, 4GB RAM sollte ja dafür reichen. Websites und Mailadressen kommen keine drauf, will ja nur sehen wie sich bind9 mit dem Unbound verträgt. Wenn das klappt, werde ich nach und nach alle bestehenden Server auch so einrichten. Den externen Resolver lasse ich dann erst mal drin als Fallback.
Bzw. als zweiter Nameserver, nicht FAllbackDNS=meineResolverIP, sondern
FallbackDNS=irgendwas ist nach meinem Verständnis nur dann von Belang, wenn sonst nirgends Nameserver angegeben sind. Wenn nicht angegeben (Default), wird da normalerweise eine Liste von einkompilierten Nameservern benutzt. Google, Cloudflare, was weiss ich.
man resolved.conf wrote:
FallbackDNS=
A space-separated list of IPv4 and IPv6 addresses to use as the
fallback DNS servers. Please see DNS= for acceptable format of
addresses. Any per-link DNS servers obtained from systemd-
networkd.service(8) take precedence over this setting, as do any
servers set via DNS= above or /etc/resolv.conf. This setting is
hence only used if no other DNS server information is known. If
this option is not given, a compiled-in list of DNS servers is used
instead.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 18. Dec 2022, 16:23
by Ralph
schau mal rein:
https://wiki.archlinux.org/title/systemd-resolved
Die 127.0.0.1 solltest du durch die echte Server IP ersetzen und 127.0.0.1 kannst du als Fallback nehmen
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 18. Dec 2022, 17:10
by tab-kh
Ja. Da steht
If systemd-resolved does not receive DNS server addresses from the network manager and no DNS servers are configured manually then systemd-resolved falls back to the fallback DNS addresses to ensure that DNS resolution always works.
Ich setze aber manuell Nameserver (DNS=127.0.0.1,...)
Wozu soll ich die externe IP einsetzen? Unbound soll ja eh nur für die Namensauflösung für auf dem Server lokal installierte Programme benutzt werden. Da hat ja dann jeder Server seinen eigenen Unbound-Resolver. Darauf soll also nicht von extern zugegriffen werden. Eventuell kann ich nicht den Default 127.0.0.1 benutzen wegen bind9. Das werde ich dann aber schnell merken und ggf. halt entsprechend eine andere lokale Adresse benutzen. Unbound lässt sich entsprechend einstellen.
Deswegen will ich ja auch erst alles auf einem reinen Testsystem mit Keyhelp testen, bevor ich damit einen bereits produktiven Server lahmlege. Erst wenn da alles bombensicher läuft, rolle ich das nach und nach auf den anderen Servern aus.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 18. Dec 2022, 17:32
by Ralph
tab-kh wrote: ↑Sun 18. Dec 2022, 17:10
Ich setze aber manuell Nameserver (DNS=127.0.0.1,...)
Das war auch mal mein Gedanke, aber da kommt sich etwas in die Quere wenn du DNS=127.0.0.1 verwendest ... geh mal weiter im Thread zurück, das hatten wir schon. Glaub mir setz da einfach mal deine System IP rein (oder bei internem Netz mit dyndns die private) das funktioniert nach einem reboot, ich habe keine lookup error mehr weder für die DNSBL noch für andere Domain lookups außer legitime bei NXDOMAINs.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 18. Dec 2022, 19:10
by tab-kh
Mag sein, dass es sich mit bind9 beisst, was anderes kann es ja nicht sein. Dann nehme ich halt 10.0.0.42, jedenfalls ist das dann ein manuell gesetzter Nameserver. Werde ich dann nach Weihnachten wissen. Ist mir schon klar, dass es bei dir jetzt soweit funktioniert. Ich habe ja auch bereits meine funktionierende Lösung. Einen lokalen Cache haben wir beide nicht, wie ihn der Stub-Resolver geboten hätte. Wenn, ja wenn, der - oder auch systemd-resolved - nicht so rumzicken würde mit DNSSEC.
Mit lokalem Unbound habe ich dann den Cache von Unbound lokal, bringt halt noch eine Kleinigkeit bei Cache-Hits. Und davon habe ich reichlich, > 60% momentan. Kriegsentscheidend ist das sicher nicht, die Server laufen absolut stabil. Meine größere Sorge ist, was passiert wenn das Cloud-VLAN mal unvermittelt den Geist aufgibt? Eins kaputtes vLAN habe ich schon, da kann man beim zweiten nicht wissen, ob und wann das passiert. Bei einem lokalen Unbound gibt es diesen Unsicherheitsfaktor halt nicht.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 15. Jan 2023, 18:46
by tab-kh
Mittlerweile habe ich Unbound direkt auf allen meinen Server bis auf einem. Da zögere ich noch, weil es erstens mein Haupt-Mailserver ist und nach meinen Maßstäben relativ schwach auf der Brust. Außerdem wird er sowieso bald ersetzt werden, da kann ich mir die 5 Minuten Arbeit sparen
Falls irgendein Interesse an den Details besteht, mache ich einen entsprechenden Thread im Off Topic Bereich auf. Hier gehört das ja nicht (mehr) hin.
Re: DNSBL lookup probleme - SERVFAIL
Posted: Sun 15. Jan 2023, 19:13
by Ralph
tab-kh wrote: ↑Sun 15. Jan 2023, 18:46
Mittlerweile habe ich Unbound direkt auf allen meinen Server bis auf einem. Da zögere ich noch, weil es erstens mein Haupt-Mailserver ist und nach meinen Maßstäben relativ schwach auf der Brust. Außerdem wird er sowieso bald ersetzt werden, da kann ich mir die 5 Minuten Arbeit sparen
Falls irgendein Interesse an den Details besteht, mache ich einen entsprechenden Thread im Off Topic Bereich auf. Hier gehört das ja nicht (mehr) hin.
Ja natürlich besteht Interesse daran
Ich hatte auch schon mit dem Gedanken gespielt, bin immer noch auf systemd-resolved.