Mein Problem: ich verwalte meinen VServer mit Plesk und in der etc/resolv.conf steht:
# This file is managed by systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known DNS servers.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

Folgerichtig gehen meine manuellen Anpassungen nach jedem Server-Reboot verloren.

Wie kann ich die Änderungen, um auf den lokalen unbound als Resolver zu verweisen, persistent konfigurieren?
Das Manual zu systemd-resolved(8) hat mich nicht wirklich weitergebracht.

Hi Daniel,

ja, das URIBL_BLOCKED sollte nicht mehr im Mailheader auftauchen. Entweder musst du einfach den spamd neu starten (sonst erkennt SpamAssassin nicht, dass ein neuer DNS-Server verwendet werden soll) oder der Eintrag in der resolv.conf passt noch nicht. Was kommt denn bei einem dig heise.de (ohne @127.0.0.1) raus? Welcher DNS-Server wird verwendet?

Grüße
Alex

danke für das Tutorial, soweit hat die Einrichtung funktioniert. Wenn ich jetzt aber eine Testmail (SPAM) mit der Signatur “XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X” sende wird die zwar (wie zuvor auch) korrekt als SPAM erkannt, jedoch habe ich weiterhin “URIBL_BLOCKED=0.001” im Mailheader. Der sollte doch eigentlich nicht mehr erscheinen?

dig heise.de @127.0.0.1 erzeugt bei mir folgende Ausgabe, was in meinen Augen richtig aussieht:

~# dig heise.de @127.0.0.1

; <> DiG 9.10.3-P4-Debian <> heise.de @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20321
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de. IN A

;; ANSWER SECTION:
heise.de. 86400 IN A 193.99.144.80

;; AUTHORITY SECTION:
heise.de. 86399 IN NS ns2.pop-hannover.net.
heise.de. 86399 IN NS ns.plusline.de.
heise.de. 86399 IN NS ns.s.plusline.de.
heise.de. 86399 IN NS ns.heise.de.
heise.de. 86399 IN NS ns.pop-hannover.de.

;; ADDITIONAL SECTION:
ns.s.plusline.de. 86399 IN A 212.19.40.14
ns.heise.de. 86399 IN A 193.99.145.37
ns.heise.de. 86399 IN AAAA 2a00:e68:14:800::d1ce
ns.plusline.de. 86399 IN A 212.19.48.14
ns.pop-hannover.de. 86399 IN A 193.98.1.200
ns2.pop-hannover.NET. 172799 IN A 62.48.67.66

;; Query time: 739 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 25 10:24:17 CET 2019
;; MSG SIZE rcvd: 307

Hast Du noch eine Idee?

Danke im Voraus und viele Grüße Daniel

Ergänze mal folgendes in den options:

dnssec-enable yes;
dnssec-validation yes;

Also:
1. `sudo nano /etc/network/interfaces`
1.1. Unterhalb von `iface lo inet loopback` eintragen: `dns-nameservers 127.0.0.1`
2. `/etc/init.d/networking restart`
3. `sudo ifdown -a`
4. `sudo ifup -a`

Außerdem hab ich als Linux-Neuling im Artikel den Start des Services nach der Installation vermisst, weshalb das `dig heise.de @127.0.0.1` bei mir Timeouts auslöste: `sudo /etc/init.d/bind9 start`

Gebe ich dann
root@h2718764:~# less /var/cache/bind/named_dump.db
ein, findet er keine Datei
/var/cache/bind/named_dump.db: No such file or directory
Hast Du eine Erklärung dafür?

Und noch eine Frage. In meiner resolv.conf stehen zwei IP-adressen. Könnte ich die nicht stehen lassen und “nameserver 127.0.0.1” darüber eintragen? Dann würde erst in “meiner” bind-db geschaut, ob der gesuchte Eintrag vorhanden ist und, falls nein, die beiden anderen dns-server abgefragt? Oder ist das falsch gedacht?

Mein Server läuft unter Ubuntu 16.04.03 LTS und Plesk Onyx

vielen Dank für dein Tutorial. Damit war die Einrichtung des Caching DNS-Resolvers basierend auf bind ein Spaziergang 🙂

Eine Frage habe ich allerdings. Und zwar tauchen auf meinem Server (Debian Jessie) im Log vermehrt Einträge des folgenden Typs auf:

Sep 2 06:32:44 XXXXX named[XXXXX]: error (connection refused) resolving ‘dns1.fpt.vn/AAAA/IN’: 2405:4800:103:2::4#53
Sep 2 06:32:44 XXXXX named[XXXXX]: error (connection refused) resolving ‘dns2.fpt.vn/A/IN’: 2405:4800:103:2::4#53
Sep 2 06:32:44 XXXXX named[XXXXX]: error (connection refused) resolving ‘dns1.fpt.vn/A/IN’: 2405:4800:103:2::4#53
Sep 2 06:32:44 XXXXX named[XXXXX]: error (connection refused) resolving ‘dns2.fpt.vn/AAAA/IN’: 2405:4800:103:2::4#53
Sep 2 06:32:44 XXXXX named[XXXXX]: error (unexpected RCODE SERVFAIL) resolving ‘89.176.55.1.in-addr.arpa/PTR/IN’: 210.245.0.131#53
Sep 2 06:32:45 XXXXX named[XXXXX]: error (unexpected RCODE SERVFAIL) resolving ‘89.176.55.1.in-addr.arpa/PTR/IN’: 210.245.0.10#53
Sep 2 06:32:45 XXXXX named[XXXXX]: error (unexpected RCODE SERVFAIL) resolving ‘89.176.55.1.in-addr.arpa/PTR/IN’: 210.245.0.10#53
Sep 2 06:32:45 XXXXX named[XXXXX]: error (unexpected RCODE SERVFAIL) resolving ‘89.176.55.1.in-addr.arpa/PTR/IN’: 210.245.0.131#53

Ich habe ein wenig ge-google-t aber leider keine klare Aussage dazu gefunden, ob das normal ist oder nicht. Vielleicht kannst du mir da ja weiterhelfen — ich bin mir ziemlich sicher, dass du das weißt 🙂

LG & danke,
GH