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. 🙂

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

5 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.

  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

  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.

Schreibe einen Kommentar

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