DNSBL lookup probleme - SERVFAIL  [GELÖST]

Haben Sie einen Bug entdeckt? Teilen Sie es uns mit.
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

tab-kh wrote: Fri 16. Dec 2022, 20:38 Ja, solche Geschichten hatte ich auch. Die nächste Mail vom selben Absender 5 Minuten später ging durch und die Adresse war nicht gelistet. Allerdings hatte ich das nur mit der zen-Liste. Keine Ahnung was die da treiben.
Es funktionierte wie gesagt über 127.0.0.1 - für Spamhaus und für Spamrats (andere habe ich noch nicht gestestet spielt auch momentan keine Rolle).

das ist vermutlich eine blöde Idee ...
nano /etc/systemd/resolved.conf
DNS=127.0.0.1

haut zwar auch jetzt kein SERVFAIL raus aber sieht nicht komplett aus:
Bullseye

Code: Select all

dig zen.spamhaus.org

; <<>> DiG 9.16.33-Debian <<>> zen.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26335
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;zen.spamhaus.org.              IN      A

;; Query time: 20 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Dec 16 21:10:29 CET 2022
;; MSG SIZE  rcvd: 45

Buster

Code: Select all

dig zen.spamhaus.org

; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> zen.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 30ac644cd468254f7fa39cd9639cd0bf1f95dbbef1a90782 (good)
;; QUESTION SECTION:
;zen.spamhaus.org.              IN      A

;; AUTHORITY SECTION:
zen.spamhaus.org.       10800   IN      SOA     need.to.know.only. hostmaster.spamhaus.org. 2212162009 3600 600 432000 10

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 16 21:10:39 CET 2022
;; MSG SIZE  rcvd: 137
und der Bind scheint alles zu validieren

Code: Select all

validating eu.mailgun.org/TXT: no valid signature found
aber die lookups klappen damit über 127.0.0.53

Code: Select all

Dec 16 21:12:54 host0 postfix/smtpd[1459]: NOQUEUE: reject: RCPT from cm5.beefland.ir[137.74.191.165]: 554 5.7.1 Service unavailable; Client host [137.74.191.165] blocked using all.spamrats.com; SPAMRATS IP Addresses See: http://www.spamrats.com/bl?137.74.191.165; from=<core@cm5.beefland.ir> to=<xxx@xxx.tld> proto=ESMTP helo=<cm5.beefland.ir>

User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

Code: Select all

bind9 status
das wird wohl ein dnssec log issue sein:
named[741]: validating bnc3.mailjet.com/A: no valid signature found
ansonsten scheints aber zu arbeiten:
named[741]: REFUSED unexpected RCODE resolving '190.115.126.129.in-addr.arpa/PTR/IN': 210.193.2.34#53
named[741]: REFUSED unexpected RCODE resolving '190.115.126.129.in-addr.arpa/PTR/IN': 210.193.2.36#53
dispatch 0x7fbc8c0c10b0: shutting down due to TCP receive error: 2001:13c7:7002:3000::11#53: connection
also funktionieren tut es jetzt damit ...

Code: Select all

#/etc/systemd/resolved.conf
DNS=127.0.0.1
Domains=
DNSSEC=no
DNSOverTLS=no
MulticastDNS=no
LLMNR=no
Cache=no-negative
DNSStubListener=yes
ReadEtcHosts=yes

was meint ihr, kann man das vorerst so lassen mit systemd resolved?
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: DNSBL lookup probleme - SERVFAIL

Post by tab-kh »

Und welcher Resolver soll da jetzt was auflösen? Sieht für mich nicht so aus, als ob da außer dem Stub-Resolver was wäre. Der hat aber keine Forwarder und selbst rekursiv auflösen kann der m.E. nicht. Kommt das alles nur aus dem Cache des Stub-Resolvers? Also Überbleibsel von früheren Versuchen mit eingestellten Forwardern?
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

tab-kh wrote: Fri 16. Dec 2022, 22:06 Und welcher Resolver soll da jetzt was auflösen? Sieht für mich nicht so aus, als ob da außer dem Stub-Resolver was wäre. Der hat aber keine Forwarder und selbst rekursiv auflösen kann der m.E. nicht. Kommt das alles nur aus dem Cache des Stub-Resolvers? Also Überbleibsel von früheren Versuchen mit eingestellten Forwardern?
Für dns-nameservers gibt es einen Eintrag in /etc/network/interfaces. Das hat mit dem DNS Cache nichts zu tun weil die DNSBL ja über 127.0.0.1 aufgelöst werden können.
In der /etc/resolv.conf ist nameserver 127.0.0.1 Standard um lookups über den lokalen DNS Server durchzuführen.
Die Frage ist ganz eingfach nur, warum über 127.0.0.53 nicht alles korrekt aufgelöst wird und wie das Problem behoben werden kann.
User avatar
Tobi
Community Moderator
Posts: 2812
Joined: Thu 5. Jan 2017, 13:24

Re: DNSBL lookup probleme - SERVFAIL

Post by Tobi »

Ralph wrote: Sat 17. Dec 2022, 10:43 Die Frage ist ganz eingfach nur, warum über 127.0.0.53 nicht alles korrekt aufgelöst wird und wie das Problem behoben werden kann.
Sei mir bitte nicht böse, aber für mich stellt sich die Frage etwas anders:
"Warum funktioniert bei dir etwas nicht, was anscheinend bei allen anderen funktioniert?"
Gruß,
Tobi


-----------------------------
wewoco.de
Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

Tobi wrote: Sat 17. Dec 2022, 10:49
Ralph wrote: Sat 17. Dec 2022, 10:43 Die Frage ist ganz eingfach nur, warum über 127.0.0.53 nicht alles korrekt aufgelöst wird und wie das Problem behoben werden kann.
Sei mir bitte nicht böse, aber für mich stellt sich die Frage etwas anders:
"Warum funktioniert bei dir etwas nicht, was anscheinend bei allen anderen funktioniert?"
OK, also können alle anderen bestätigen das ein lookup z.b. auf diese beiden DNSBL erfogreich beantwortet wird?

Code: Select all

dig all.spamrats.com
dig zen.spamhaus.org
Ich habe gestern zwei neue Test Installationen unter Bullseye aufgesetzt und komme immer wieder zum gleichen Resultat bei diesem Check:
SERVFAIL
Wie gesagt NEU Installation - kein Check über ein Distro Upgrade wo eventl. noch alte configs als Überbleibsel vorhanden sind.

Code: Select all

dig all.spamrats.com @127.0.0.1

; <<>> DiG 9.16.33-Debian <<>> all.spamrats.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19378
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8a5846a0101708f001000000639da86703112bc3d39569af (good)
;; QUESTION SECTION:
;all.spamrats.com.              IN      A

;; Query time: 464 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 17 12:30:47 CET 2022
;; MSG SIZE  rcvd: 73

Code: Select all

dig all.spamrats.com @127.0.0.53

; <<>> DiG 9.16.33-Debian <<>> all.spamrats.com @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41060
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;all.spamrats.com.              IN      A

;; Query time: 1172 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Dec 17 12:31:32 CET 2022
;; MSG SIZE  rcvd: 45
Die Problem Beschreibung wird irgendwie missverstanden ... es besteht ein Problem mit DNSBL lookups über 127.0.0.53 mit einigen Major Listen Anbietern
Daher werden einige Emails je nach DNSBL rejected die kein Listing haben (siehe weiter zurück) z.b. bei spamhaus, sowie bei spamrats und barracudacentral gibt es RBL lookup errors über 127.0.0.53, über 127.0.0.1 funktionieren sie.
Ich habe diese DNSBL erst einmal rausgenommen obwohl diese momentan aufgrund der massiven Attacken hilfreich wären.

ich sehe also kein generelles Problem mit lookups was durch eine Fehlkonfiguration verursacht wäre:

Code: Select all

; <<>> DiG 9.16.33-Debian <<>> test.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21133
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ae88551e7ce40ff401000000639daec615fbc85037c19ed4 (good)
;; QUESTION SECTION:
;test.com.                      IN      A

;; ANSWER SECTION:
test.com.               1419    IN      A       67.225.146.248

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 17 12:57:58 CET 2022
;; MSG SIZE  rcvd: 81

root@host0:~# dig test.com @127.0.0.53

; <<>> DiG 9.16.33-Debian <<>> test.com @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39436
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;test.com.                      IN      A

;; ANSWER SECTION:
test.com.               1175    IN      A       67.225.146.248

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Dec 17 12:58:04 CET 2022
;; MSG SIZE  rcvd: 53
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: DNSBL lookup probleme - SERVFAIL

Post by tab-kh »

Was sagt eigentlich

Code: Select all

resolvectl status
wenn du es mit deinen beiden unterschiedlichen Konfigurationen aufrufst?
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

tab-kh wrote: Sat 17. Dec 2022, 14:39 Was sagt eigentlich

Code: Select all

resolvectl status
wenn du es mit deinen beiden unterschiedlichen Konfigurationen aufrufst?
die 127.0.0.1 habe ich wieder rausgenommen

Code: Select all

resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 213.133.98.98
       DNS Servers: 213.133.99.99 213.133.98.98 213.133.100.100

Link 2 (enp1s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

es geht aber um ein DNSBL Lookup Problem mit einigen Anbietern über 127.0.0.53, was sagt denn bei dir folgendes:

Code: Select all

dig all.spamrats.com @127.0.0.53
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: DNSBL lookup probleme - SERVFAIL

Post by tab-kh »

Ralph wrote: Sat 17. Dec 2022, 14:50
es geht aber um ein DNSBL Lookup Problem mit einigen Anbietern über 127.0.0.53, was sagt denn bei dir folgendes:

Code: Select all

dig all.spamrats.com @127.0.0.53

Code: Select all

; <<>> DiG 9.16.33-Debian <<>> all.spamrats.com @127.0.0.53
;; global options: +cmd
;; connection timed out; no servers could be reached
Nicht weiter erstaunlich, wenn der DNSStubListener ausgeschaltet ist und 127.0.0.53 auch nicht als DNSServer eingetragen ist in der /etc/systemd/resolved.conf

Ich setze auch keine DNS-Server in der /etc/network/interfaces. Unsere Konfigurationen sind halt völlig unterschiedlich, das sage ich völlig wertfrei, schon weil ich zu wenig Ahnung von diesen Dingen habe, um beurteilen zu können, was letztlich die bessere Methode ist, falls es ein "besser" hier wirklich gibt.

resolvectl status zeigt bei mir:

Code: Select all

Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
    resolv.conf mode: uplink
  Current DNS Server: 192.168.1.101
         DNS Servers: 192.168.1.101 2000:1000:2000:3000::101 8.8.4.4
                      2001:4860:4860::8844
Fallback DNS Servers: 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001

Link 2 (eth0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported

Link 3 (eth1)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported

Link 4 (eth2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
Der 192.168.1.101 ist mein Resolver, der über das Cloud vLAN angebunden ist (eth2). Der wird immer benutzt, sofern er verfügbar ist. Das war eben in einigen anderen von mir versuchten Einstellungen nicht so, gerade bei Benutzung des StubResolvers wie bei dir.

Das hätte ich durchaus gern so gehabt wegen des lokalen Caches des Stub-Resolvers, aber nach einigen Stunden Betrieb hat das Ding meinen Resolver soweit heruntergestuft, dass der nächste Resolver in der Liste dran war. Der war dann nach einiger Zeit ebenso "out" und der nächste kam dran usw. Das war nicht in meinem Sinne und sehr wahrscheinlich auch immer noch einer von mehreren Bugs von systemd-resolved.

Da bleibt nur "DNSSEC=no" in der /etc/systemd/resolved.conf wie bei dir. Dann passiert das nicht. Das Problem besteht sowohl bei "DNSSEC=yes" als auch bei "DNSSEC=allow-downgrade". Der Default "no" kommt also wohl nicht von ungefähr. Aber das will ich so nicht haben, DNSSEC hätte ich schon ganz gern validiert. Man muss ja nicht alles glauben, was irgendwelche dubiosen Zeitgenossen einem als vertrauenswürdige Informationen verkaufen wollen. Beim Uplink-Modus passiert das jetzt nicht mehr.

/etc/systemd/resolved.conf

Code: Select all

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
# Google:     8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
# Quad9:      9.9.9.9 2620:fe::fe
DNS=192.168.1.101 2000:1000:2000:3000::101 8.8.4.4 2001:4860:4860::8844
DNSSEC=yes
DNSOverTLS=no
MulticastDNS=no
LLMNR=no
Cache=no-negative
DNSStubListener=no
#DNSStubListener=yes
#DNSStubListenerExtra=
ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
/etc/resolv.conf ist ein Symlink:

Code: Select all

lrwxrwxrwx 1 root root 32 16. Dez 20:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
und sieht mit den obigen Einstellungen dann so aus:

Code: Select all

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.1.101
nameserver 2000:1000:2000:3000::101
nameserver 8.8.4.4
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844
search .
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

tab-kh wrote: Sat 17. Dec 2022, 16:11

Code: Select all

; <<>> DiG 9.16.33-Debian <<>> all.spamrats.com @127.0.0.53
;; global options: +cmd
;; connection timed out; no servers could be reached
Nicht weiter erstaunlich, wenn der DNSStubListener ausgeschaltet ist und 127.0.0.53 auch nicht als DNSServer eingetragen ist in der /etc/systemd/resolved.conf

Danke, ganz genau der löst über 127.0.0.53 nicht auf ;-)

und jetzt versuche mal ein:

Code: Select all

dig all.spamrats.com @127.0.0.1
wie gesagt, ich habe bisher 3 DNSBL gefunden die über 127.0.0.53 entweder false/positive rejecten oder gar nicht erst zu erreichen sind und genau darum geht es hier:

Code: Select all

postfix/smtpd[227289]: warning: 156.74.140.155.b.barracudacentral.org: RBL lookup error: Host or domain name not found. Name service error for name=156.74.140.155.b.barracudacentral.org type=A: Host not found, try again

Code: Select all

warning: 49.128.240.80.all.spamrats.com: RBL lookup error: Host or domain name not found. Name service error for name=49.128.240.80.all.spamrats.com type=A: Host not found, try again

Code: Select all

postfix/smtpd[1588]: NOQUEUE: reject: RCPT from a0-123.smtp-out.eu-west-1.amazonses.com[54.240.0.123]: 554 5.7.1 Service unavailable; Client host [54.240.0.123] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/162.158.85.214; from=<20221216191238c2e6bacacd434464afbb46fa4560p0eu-C2PN85VRG22OP@bounces.amazon.de>

Code: Select all

postfix/smtpd[1588]: NOQUEUE: reject: RCPT from sonic325-7.consmr.mail.ne1.yahoo.com[66.163.184.67]: 554 5.7.1 Service unavailable; Client host [66.163.184.67] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/172.68.49.211
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

oder DNSStubListener auf off
und die NS dann eintragen das 127.0.0.1 in der resolv oben steht z.b
DNS=127.0.0.1 127.0.0.53 8.8.8.8

dabei wird 127.0.0.53 an die zweite Stelle zurückgestellt, keine Ahnung ob das zu Konflikten führen kann

Code: Select all

nameserver 127.0.0.1
nameserver 127.0.0.53
nameserver 8.8.8.8
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

OK, ich muß noch die nächste Spam Attacke abwarten, aber ich glaube ich habe es jetzt über systemd resolved hinbekommen :mrgreen:
Details:
https://wiki.archlinux.org/title/systemd-resolved

Code: Select all

nano /etc/systemd/resolved.conf
DNS=server-ipv4-ip server-ipv6-ip
FallbackDNS=127.0.0.1 ::1
Domains=~.
DNSSEC=allow-downgrade
DNSStubListener=yes
ReadEtcHosts=yes
ist ein Link auf /run/systemd/resolve/stub-resolv.conf (nicht statisch)

Code: Select all

cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

Code: Select all

dig all.spamrats.com @127.0.0.53

; <<>> DiG 9.16.33-Debian <<>> all.spamrats.com @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2437
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;all.spamrats.com.              IN      A

;; Query time: 104 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Dec 17 17:50:42 CET 2022
;; MSG SIZE  rcvd: 45
User avatar
24unix
Posts: 1560
Joined: Sun 21. Jun 2020, 17:16
Location: Kollmar
Contact:

Re: DNSBL lookup probleme - SERVFAIL

Post by 24unix »

Ralph wrote: Sat 17. Dec 2022, 17:54 ist ein Link auf /run/systemd/resolve/stub-resolv.conf (nicht statisch)
Das weiß man eigentlich.

Außerdem wurde Dir das hier auch schon gepostet.

tab-kh wrote: Sat 17. Dec 2022, 16:11 /etc/resolv.conf ist ein Symlink:

Code: Select all

lrwxrwxrwx 1 root root 32 16. Dez 20:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
User avatar
Ralph
Posts: 786
Joined: Mon 30. Mar 2020, 16:14

Re: DNSBL lookup probleme - SERVFAIL

Post by Ralph »

24unix wrote: Sat 17. Dec 2022, 18:07
Ralph wrote: Sat 17. Dec 2022, 17:54 ist ein Link auf /run/systemd/resolve/stub-resolv.conf (nicht statisch)
Das weiß man eigentlich.

Außerdem wurde Dir das hier auch schon gepostet.

tab-kh wrote: Sat 17. Dec 2022, 16:11 /etc/resolv.conf ist ein Symlink:

Code: Select all

lrwxrwxrwx 1 root root 32 16. Dez 20:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
Der Link war immer auf /run/systemd/resolve/stub-resolv.conf nachdem ich das resolvconf package deinstalliert habe, ich wollte das hier nur noch einmal hervorheben.
Nochmal: Das Problem ist/war das 127.0.0.53 einige DNSBL nicht auflösen kann per default!

Code: Select all

dig all.spamrats.com @127.0.0.53
und somit kommt es zu Problemem mit false rejects und einigen DNSBL die gar nicht funktionieren
User avatar
24unix
Posts: 1560
Joined: Sun 21. Jun 2020, 17:16
Location: Kollmar
Contact:

Re: DNSBL lookup probleme - SERVFAIL

Post by 24unix »

Ralph wrote: Sat 17. Dec 2022, 18:30 Nochmal: Das Problem ist/war das 127.0.0.53 einige DNSBL nicht auflösen kann per default!

Code: Select all

dig all.spamrats.com @127.0.0.53
und somit kommt es zu Problemem mit false rejects und einigen DNSBL die gar nicht funktionieren
Tut er bei mir auch nicht.

Aber auf spamrats.com.

Wobei ich selber so Kram nicht nutze, habe keinen nennenswerten Spam.

Und, auch wenn man Google DNS befragt gibt es kein all.spamrats.com.

Code: Select all

[0] # dig all.spamrats.com @8.8.8.8

; <<>> DiG 9.16.33-Debian <<>> all.spamrats.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58051
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;all.spamrats.com.		IN	A

;; Query time: 1296 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 17 18:42:04 CET 2022
;; MSG SIZE  rcvd: 45
Wo hast Du das all.spamrats.com her?

Code: Select all

[0] # dig ANY spamrats.com @8.8.8.8

; <<>> DiG 9.16.33-Debian <<>> ANY spamrats.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40561
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;spamrats.com.			IN	ANY

;; ANSWER SECTION:
spamrats.com.		7200	IN	SOA	ns1.linuxmagic.com. hostmaster.wizard.ca. 373 21600 3600 604800 43200
spamrats.com.		7200	IN	TXT	"v=spf1 ip4:65.39.244.0/24 ip4:104.128.144.0/20 -all"
spamrats.com.		7200	IN	NS	ns2.linuxmagic.com.
spamrats.com.		7200	IN	NS	ns3.linuxmagic.com.
spamrats.com.		7200	IN	NS	ns4.linuxmagic.com.
spamrats.com.		7200	IN	NS	ns.linuxmagic.com.
spamrats.com.		21600	IN	MX	10 mx2.cityemail.com.
spamrats.com.		21600	IN	MX	10 mx1.cityemail.com.
spamrats.com.		7200	IN	A	104.128.145.83

;; Query time: 152 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 17 18:43:44 CET 2022
;; MSG SIZE  rcvd: 313
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Post Reply