MichlFranken

DNS Server: Eigenen Linux DNS Server mit Bind9 aufsetzen

Allgemein, Cloud Computing, Trickkiste

DNS Server: Eigenen Linux DNS Server mit Bind9 aufsetzen

8 min

2

Loading

Wenn du im Internet surfst und zum Beispiel die Domain michlfranken.de im Browser eingibst, dann verbindet sich Dein Rechner mit einem DNS Server um zu erfragen, welche IP Adresse hinter der Domain michlfranken.de steckt um genau diese IP aufzurufen. Warum es sich lohnt einen eigenen DNS Server zu betreiben, schauen wir uns heute an. Viel Spaß.

Was für viele Internetanwender selbstverständlich ist, kann für die DNS Betreiber bare Münze sein. Verwendest Du z.B. einen DNS einer Suchermaschine, die ihr Geld mit dem Verkauf von personalisierter Werbung macht, kann sich der Anbieter hier nur die Hände schlecken. Denn schließlich liefert der zugehörige DNS Log ein exaktes Surfprofil.

Doch bevor jetzt die ersten Rufe: Datenschutzskandal! Ruhig Blut. Das ist technisch alles korrekt und muß so sein, sofern Du nicht die IPs aller Internetseiten im Kopf hast. Doch könnte man mit ein paar Tricks etwas für seine Privatsphäre tun. In dem Video zeige ich Dir, wie Du einen Bind9 DNS Server aufbaust und diesen wie einen Proxy bzw. als Resover DNS-Client betreibst. Der DNS baut lokal bei Dir einen Domain-Cache auf und stellt bei neuen Domains, die er nicht kennt, eine Anfrage an einen anderen, öffentlichen DNS Server Deiner Wahl. Wir werfen dann auch einmal einen Blick in die Logs des DNS um zu ergründen, warum es vielleicht ratsam sein könnte die DNS Server Deines Internetanbieters ggf. gegen andere zu ersetzen.

Vorbereitung:

Prinzipiell ist es irrelevant unter welcher Linux Distribution Du den DNS aufsetzt. Ich habe es für dieses Video auf einem Debian Stable (derzeit Buster) System als Server durchgeführt. Das Client System ist openSUSE Thumbleweed, also eine andere Linuxdistribution. Wir fahren hier also mit 2 VMs um einen Server und einen Client zu simulieren.

Wir benötigen eine feste IP für den DNS Server. Die via VirtualBox genateten IP Adressen sind ungenügend. Deshalb habe ich vorweg für das Debian System in VirtualBox umgestellt unter Netzwerk -> Adapter 1 -> Angeschlossen an Netzwerkbrücke:

Debian VM starten und IP abfragen:

Debian Server -> ip a

IP Adresse: 192.168.1.129

Hostname: debian-dns-yt

Um eine entfernte Anmeldung am DNS durchführen zu können, müssen wir openssh server auf dem Debian DNS Server installieren:

sudo apt -y install openssh-server

Falls der openssh Server nicht startet:

sudo systemctl status sshd

sudo systemctl status sshd

Installation BIND9 DNS Server vom Client aus

Bind9 installieren

sudo apt -y install bind9 bind9utils

Der eigene DNS ist am Anfang ohne jegliche Einträge. Heißt er muß erstmal seinen eigenen Datenbestand aufbauen. Dazu leitet er Anfragen an für ihn unbekannte Domains an einen anderen DNS weiter und baut so seinen eigenen Bestand auf.

Die jetzt folgende Konfiguration könnt Ihr prinzipiell eins zu eins übernehmen wenn Ihr z.B. eine Fritzbox nutzt bzw. eine 24er Netzmaske im Einsatz habt.

in der named.conf wird angezeigt, welche Dateien geladen werden:

Da wir unseren DNS in Funktion eines Proxy – Servers aufsetzen wollen, müssen wir in der Datei named.conf.options Änderungen vornehmen.

Bind9 Anpasungen vornehmen

cd /etc/bind/

sudo vi named.conf.options

bei Fowarders sollen die DNS Server eingetragen werden, die der BIND Server anspricht, wenn er die Zieladressen selbst nicht kennt.

Ich trage die folgenden unzensierten und freie DNS ein:

80.241.218.68; 46.182.19.48;

80.241.218.68 -> Dismail.de

46.182.19.48 -> Digitalcourage

Quelle und weitere DNS: https://www.kuketz-blog.de/empfehlungsecke/#dns

Zonen anlegen

Zunächst müssen wir zwei Zonen anlegen. Eine Forward Lookup Zone und eine Reverse Lookup Zone

sudo vi named.conf.local

Wir starten mit der Forward Zone, die wir michlfranken nennen:

zone "michlfranken" {

  type master;

  file "/var/cache/bind/db.michlfranken";

  };

Zone: gefolgt von dem Zonennamen

Type: Master heißt dieser Server ist für diese Zone hauptverantwortlich und verwaltet diese.

File: Konfigurationsdatei der Zone (erstellen wir noch)

Wir konfigurieren jetzt noch eine Reverse Zone, damit der DNS sagen können soll welcher Name zu einer IP gehört.

Je nach bei Dir vorhandener Netzmaske kommt bei Euch eine Änderung jetzt. Ich habe ein 24er Netzmaske bei meiner Fritzbox mit der IP 192.168.1.1:

Mein Netzwerk Segment:192.168.1.0/24 -> 1.168.192.in-addr.arpa

Reverse DNS Zone:

zone "1.168.192.in-addr.arpa“ {

  type master;

  file "/var/cache/bind/db.rev-local";

  };

Cache Verzeichnis anlegen

sudo mkdir -p /var/cache/bind

Konfiguration für angelegte Zonen erstellen

cd /var/cache/bind

Forward Lookup Zone

sudo vi db.michlfranken

;; db.michlfranken

;; Forward lookup zone

$ TTL 3D

@                    IN            SOA           yt-bind.michlfranken. mail.admin (

                                                         0000000001

                                                         9H

                                                         3H

                                                         4W

                                                         3H )

@                    IN            NS            yt-bind.michlfranken.

                     IN            A             192.168.1.129

yt-bind              IN            A             192.168.1.129

Infos:

  • TTL = Time to live
  • SOA Record wird immer benötigt und ist zur allgemeinen Zonendfinition nötig
  • NS deutet auf NameServer Einträge hin. Diese sind nötig, damit alle Anfragen den DNS für die Domäne kennen.
  • A Record für den DNS, damit der DNS Server Host aufgelöst werden kann
  • A Record für den Host anlegen, so kann die iP des DNS erfragt werden

Reverse Zone:

Fängt inhaltlich gar nicht so unterschiedlich an. SAO und NS Eintrag sind identisch.

sudo vi db.rev-local

;; db.rev-local

;; reverse zone

$ TTL 3D

@                       IN              SOA             yt-bind.michlfranken. mail.admin (

                                                        0000000001

                                                        9H

                                                              3H

                                                        4W

                                                        3H )

@                       IN              NS              yt-bind.michlfranken.

129                      IN              PTR             yt-bind.michlfranken.

Die unterste Zeile (PTR Eintrag) ist die IP vom DNS. Da 192.168.1.129 wird hier nur das vierte Oktett angegeben, also 129

Rechte auf bind ändern

sudo chown bind:bind db.*

Bind9 durchstarten

sudo systemctl restart bind9

Logging einbauen:

sudo mkdir /var/log/named

sudo chmod 777 /var/log/named

sudo vi /etc/bind/named.conf

logging {

    channel query.log {

        file “/var/lib/bind/bind_query.log” versions 3 size 5m;

        // Set the severity to dynamic to see all the debug messages.

        severity dynamic;

        print-time yes;

    };

    category queries { query.log; };

};

Bind9 durchstarten

sudo systemctl restart bind9

Nun ist es nötig, am Client-System als DNS die IP von unserem DNS Server einzutragen: 192.168.1.129

Es gibt nun zwei Möglichkeiten das Ergebnis zu prüfen. Die eine ist der eben eingebaute Log, der zeigt, welche Domains angesprochen sind. Die andere ist das Programm DIG, das zeigt wie schnell eine Anfrage beantwortet wird.

Installiere dig auf sofern eingehend nicht dnsutils installiert wurde.

Beispiele für Debian und openSUSE

Debian: sudo apt install dnsutils -y

openSUSE: sudo zypper install bind-utils

Variante 1: Log prüfen:

Am openSUSE Client sind wir via SSH mit dem Debian DNS Server verbunden und geben in der Konsole ein:

cd /var/lib/bind

tail -f bind_queries.log

am SUSE Rechner öffnen wir einen Browser und geben z.b. www.n-tv.de ein

Der DNS Log zeigt was alles aufgerufen und protokolliert wird, wenn wir z.B. www.n-tv.de aufrufen

Variante 2: DNS Caching via DIG verifizieren:

Auf dem openSUSE Rechner rufen wir auf (das ist keine Schleichwerbung, sondern mir ist spontan das als erstes eingefallen!):

dig www.telekom.de

oder

dig www.vodafone.de

Wir sehen jeweils im linken Fenster eine Query Time im msec Bereich. Das zeigt, daß der lokale DNS die IP hinter den Domains telekom.de und vodafone.de nicht kannte, die Anfrage an den Upstream-DNS leitete, dort Antwort erhielt und diese dann lieferte. Im rechten Fenster sehen wir eine Query Time von 0. Das zeigt, daß die Anfrage aus dem eigenen Puffer gezogen wurde, weshalb kein Verzug aufkommt.

Ich hoffe, ich konnte einigermaßen anschaulich machen wieso ein eigener DNS u.U. Sinn machen kann. Zumindest zeigt er, wie krank das Netz mittlerweile ist, denn die wenigsten würden erwarten, daß wenn Sie Domain 1 ansurfen, unzählige weitere Domains im Hintergrund eingebunden und geladen werden.

Wer einen Pi-hole nutzt, kann dort ebenfalls Upstream-DNS konfigurieren und hat bereits einen eigenen DNS laufen.

Das zu diesem Artikel korrespondierende YouTube Video findest Du auf meinem YouTube -Kanal hier.

Folgt mir gerne auch auf:

Du möchtest mehr über Linux lernen?

Als Amazon-Partner verdiene ich an qualifizierten Verkäufen

, , , , , , , , , , , ,

2 Comments

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

  1. Vielen Dank für die tolle Anleitung. Es hat auf Anhieb geklappt. Ich bin begeistert und entsetzt wenn ich den Log anschaue :-O

  2. Danke für die Anleitung.

    Leider stelle ich fest, dass auch hier die Namensauflösung nur temporär “zeitlich beschränkt” ist.

    Daher meine Frage:
    Wie kann aus Beispiel ein „Pi-hole“ der als DNS bereits fungiert, auch ein permanenter lokaler erster DN-Root-Server „automatisiert für die bereits abgefragten und somit ihm bekannten Domains und IPs …“ geschaffen werden?

    Sprich die DN Datenbank Systemneustarts überstehen, ohne das die /etc/hosts oder /etc/host.conf manuell gefüttert werden muss.

    Danke für den Beitrag im Voraus

    Gruß
    Eimer

log in

Captcha!
Forgot password?

forgot password

Back to
log in