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
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:
- MichlFranken auf Mastodon: https://mastodon.social/@MichlFranken
- MichlFranken auf Twitter: https://twitter.com/michlfranken
- MichlFranken auf YouTube: https://youtube.com/c/MichlFranken
- MichlFranken RSS: https://www.michlfranken.de/feed/
- MichlFranken Blog: https://www.michlfranken.de/
Du möchtest mehr über Linux lernen?
- Welches Linux passt zu mir?: Entscheidungshilfe für Linux Einsteiger – 2020: https://amzn.to/2X4DDx1 (Partnerlink / Affiliate Link)
- Der eigene Server mit FreeBSD 9: Konfiguration, Sicherheit und Pflege: https://amzn.to/3cCY36R (Partnerlink / Affiliate Link)
- Ubuntu 18.04: Schnellanleitung für Einsteiger: https://amzn.to/2LAcmwV (Partnerlink / Affiliate Link)
- Ubuntu 18.04 LTS: Das umfassende Handbuch zur LTS-Version »Bionic Beaver« https://amzn.to/3fVJv48 (Partnerlink / Affiliate Link)
- Arch Linux: Schnellanleitung für Einsteiger https://amzn.to/2TaCHpP (Partnerlink / Affiliate Link)
- Ubuntu 16.04 LTS: Das umfassende Handbuch https://amzn.to/3fMZrWm (Partnerlink / Affiliate Link)
- Linux: Das umfassende Handbuch https://amzn.to/2WZHnjj (Partnerlink / Affiliate Link)
- Linux kompatibles Notebook: https://amzn.to/3dN6bSr (Partnerlink / Affiliate Link)
- Notebookständer: https://amzn.to/3g0gDbh (Partnerlink / Affiliate Link)
- Raspberry Pie 4 Model 4 Set: https://amzn.to/2Z8fA2N (Partnerlink / Affiliate Link)
- Linux Mint Slim PC als Mini-Server: https://amzn.to/2WBdF59 (Partnerlink / Affiliate Link)
Als Amazon-Partner verdiene ich an qualifizierten Verkäufen
Vielen Dank für die tolle Anleitung. Es hat auf Anhieb geklappt. Ich bin begeistert und entsetzt wenn ich den Log anschaue :-O
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