13 Comments

Updated on Mai 7, 2019

Caching DNS-Resolver mit bind9

Es gibt viele Gründe, warum man einen eigenen Caching DNS-Resolver oder gar kompletten DNS-Server betreiben möchte. Sei es, um DNSSEC zu nutzen, oder um einfach unabhängig von Provider-DNS zu sein. Schließlich übernimmt ab dann der eigene Server die komplette rekursive DNS Auflösung, angefangen bei den DNS Root Servern. Anschließend werden die Antworten im lokalen Cache gehalten. Deshalb bringt das Ganze auch einen gewissen Performanceschub mit sich.

Bei mir war der Hauptgrund mein Mailserver. Manche DNSBLs arbeiten nach dem Freemium-Prinzip und lassen nur eine begrenzte Anzahl an Abfragen pro Source-IP durch. Da ich bis vor kurzem noch öffentliche DNS-Server benutzt habe, und letztlich ja diese bei den DNSBLs nachfragen, waren viele SpamAssassin Checks nicht erfolgreich. Nachzulesen hier: SpamAssassin Erkennungsrate (deutlich) verbessern

Ich gehe hier nur auf die Konfiguration des DNS-Resolver ein, sprich es werden nur Domains aufgelöst, nicht aber DNS Records für eigene Domains gehostet. Vielleicht mache ich das in Zukunft mal und berichte. 🙂

Update 07.05.2019: Mittlerweile bin ich auf unbound umgestiegen. Dieser funktioniert direkt nach der Installation ohne weiteres Zutun. Unter Ubuntu 16.04 / 18.04 reicht folgendes aus:

 apt install unbound

Anschließend kann direkt mit Punkt Test des neuen DNS Resolvers dieser Anleitung fortgefahren werden.

Installation von bind9 auf Ubuntu 14.04

Unter Ubuntu 14.04 ist ein eigener DNS-Resolver schnell installiert:

apt-get update
apt-get install bind9 bind9utils bind9-doc

Nach der Installation wird Bind automatisch gestartet, außerdem wird ein Init-Script hinterlegt, sodass er auch nach einem Neustart des Servers automatisch wieder gestartet wird.

Damit Bind als Caching DNS-Resolver arbeitet, muss nur eine Konfigurationsdatei angepasst werden:

sudo nano /etc/bind/named.conf.options

Über den options Block wird folgendes hinzugefügt:

acl goodclients {
localhost;
};

options {
. . .

im options Block wird folgendes ergänzt:

options {
directory "/var/cache/bind";

recursion yes;
allow-query { goodclients; };
. . .

Damit wird Bind so konfiguriert, dass nur Anfragen von localhost erlaubt werden. Außerdem wird die Rekursion aktiviert. Das bedeutet, dass Bind selbst bei den DNS Root-Servern anfrägt und keinen weiteren DNS-Forwarder benutzt.

Falls man den DNS Resolver nicht nur für den eigenen Server nutzen möchte, werden einfach die entsprechend erlaubten IP-Bereiche in die ACL zusätzlich mit eingetragen:

acl goodclients {
localhost;
192.0.2.0/24;
};

Test des neuen DNS Resolvers

Um zu überprüfen, ob alles richtig funktioniert, könnt ihr mittels dig euren DNS Server etwas auflösen lassen:

dig heise.de @127.0.0.1

Achtet auf die Query time im Output des Befehls. Wenn dig erneut aufgerufen wird, sollte diese auf 0ms wandern, da die Domain eurem Nameserver bekannt ist.

Verwenden des eigenen DNS Resolvers

Nun muss euer DNS Server nur noch vom Betriebssystem verwendet werden. Unter Ubuntu 14.04 ist dazu folgendes notwendig:

sudo nano /etc/resolv.conf

In der Datei sucht ihr euch die Zeile, die mit nameserver beginnt. Dort ist die IP des aktuellen DNS Server eingetragen. Diese IP muss durch 127.0.0.1, also die Loopback-IP eures Servers, ersetzt werden. Falls der DNS Resolver für mehrere Computer dient, ist dort natürlich die echte IP des Servers einzutragen.

nameserver 127.0.0.1

Auslesen des Cache von bind9

Falls ihr wissen wollt, welche Daten euer DNS Resolver im Cache hat, geht das wie folgt:

# Der nächste Befehlt schreibt den Cache aus dem RAM nach (bei Ubuntu) /var/cache/bind/named_dump.db
sudo rndc dumpdb
# Jetzt kann die Datei aufgerufen werden
less /var/cache/bind/named_dump.db


Ähnliche Posts:

Category: Linux Tags: , , , ,

13 Comments on “Caching DNS-Resolver mit bind9”

  1. Pingback: SpamAssassin Erkennungsrate (deutlich) verbessern | SYN-FLUT.de

  2. Bitte ein Semikolon hinter localhost ergänzen, ansonsten startet der Dienst nicht.

    1 acl goodclients {
    2 localhost;
    3 };
    4
    5 options {
    6 . . .

    In der späteren Auflistung mehrere Clients/Netze ist es wiederum richtig eingetragen.

    Reply

  3. Hallo Alex,

    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

    Reply

  4. Hallo Alex, danke für die Anleitung! Genau auf dieses Problem bin ich gestern aufmerksam gemacht worden in der SA ML. Eine meiner Testmails hatte im Spam-Status den Eintrag URIBL_BLOCKED=0.001. Mein Mailserver (Debian/MySQL/Amavis/SA/Clamav) würde durch URIBL geblockt werden, weil ich die DNS-Anfrage normal weiterleite. Ich solle einen “non-forwarding” DNS-Server einrichten. Ich wusste überhaupt nicht, was los ist 🙂 Nachdem ich https://wiki.apache.org/spamassassin/CachingNameserver gelesen hatte, bin ich dann über Google auf deine Seite gekommen.

    Reply

  5. Hallo Alex,
    danke für den Beitrag. Bei mir klappt das Auslesen der bind.db mit Deiner Befehlssequenz nicht. Wenn ich rndc dumpdb eingebe, erhalte ich die Warnung:
    key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)

    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

    Reply

  6. Hallo Alex, danke für die super Anleitung! Damit war der Bind-Cache-Server schnell engerichtet.
    Jedoch, Zitat: “Bind selbst bei den DNS Root-Servern anfrägt und …” Zitat ende.
    Es gibt keine Fräge. 😉

    Reply

  7. Das mit der `/etc/resolv.conf` hat bei mir nicht so ganz funktioniert. Ich hab dann die Anweisungen von dort befolgt: `https://askubuntu.com/a/310407`

    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`

    Reply

  8. Hi 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

    Reply

    • 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

      Reply

  9. Danke für die inspirierenden Tips.

    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.

    Reply

  10. Pingback: SpamAssassin optimieren – wiki.schoppe.it

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

About-Me-smaller

Willkommen auf meinem Blog! Mein Name ist Alex. Ich beschäftige mich leidenschaftlich mit Netzwerken, Linux-Servern und Open-Source-Produkten. Beruflich arbeite ich im Unified-Communications und TelePresence-Bereich.

Impressum - Datenschutz


Copyright © 2024 · All Rights Reserved · SYN-FLUT.de

Custom Child-Theme, based on Swell Lite from Organic Themes · RSS Feed · Anmelden