logo-jonsch

Eigenen DNS-Server auf einem Raspberry Pi betreiben



Beitragsbaum



Vorwort

Einen eigenen DNS-Server bietet heutzutage einen großen Vorteil zu den kommerziellen und gewöhnlichen DNS-Diensten im Internet. Die Konfiguration kann von jedem selbst bestimmt und angepasst werden. Des Weiteren bietet einem das Konstrukt maximale Transparenz. Man kann selbst festlegen, welcher Verkehr gefiltert wird, welche Seiten gesperrt oder zugelassen werden und wie der Aufbau des Logging Systems auszusehen hat. Das ganze System ist greifbar im eigenen Himnetzwerk, daher ist einem auch bekannt, wer Zugriff auf die Daten hat und wer nicht. Dies ist meiner Meinung nach die Kirsche auf dem Sahenhäubchen der dafür sprechenden Fakten.




Pro/Contra

Nochmal zur bildlichen Verdeutlichung der eigentlichen Vor- und Nachteile des Systems.


Pro Contra
  • Der DNS steht lokal im Netz, somit kontrollierbar wer Zugang zu dem System hat.
  • Kosten für die Anschaffung eines Raspberry Pi’s und Zubehör fallen an.
  • Konfiguration kann komplett selbst auf die Bedürfnisse angepasst werden.
  • Konfiguration muss selbst durchgeführt werden.
  • Privatsphäre und System-Logging kann selbst angepasst werden.
  • Administration und Support fallen selbst an.
  • Sobald die Seite einmal im Cache gespeichert wird, werden erneute Anfragen schneller verarbeitet.
  • Falls der DNS-Service versagt und kein Failover konfiguriert ist, fällt die Namensauflösung im Heimnetzwerk aus.
  • Geoblocking der kommerziellen DNS-Server wird durch das eigene System unbrauchbar gemacht.
  • Domains für die Endgeräte daheim anlegen, somit muss nicht immer die IP-Adresse eingegeben werden.



Raspberry Pi vorbereiten

Bevor man mit der eigentlichen Installation und Konfiguration des DNS-Servers beginnen kann, muss der Raspberry Pi (RPi) erstmal auf die bevorstehenden Schritte vorbereitet werden. Damit diese Schritte durchgeführt werden können, startet diese kurze Anleitung schon mit einem laufenden Raspbian oder anderem OS für den Einplatinencomputer. Welche Schritte der Vorbereitungen man nun treffen muss, werde ich hier kurz aufführen.




Statische IP-Adresse vergeben

Eine statische IP-Adresse für den Raspberry Pi ist eine Grundvorraussetzung um den DNS Dienst problemlos zu betreiben. Denn nur durch eine statische IP ist der DNS Server auch immer unter der gleichen Adresse erreichbar. Würde der RPi nach einem Upgrade oder nach einer Änderung des Systems neustarten, kann es sein, dass dieser eine neue IP-Adresse vom DHCP zugewiesen bekommt.




Hostname anpassen

Der Hostname muss nicht unbedingt angepasst werden, damit der DNS-Server betrieben werden kann. Allerdings finde ich es schöner, wenn der Hostname des Systems auch die Verwendung dessen widerspiegelt. In meinem Beispiel ändere ich den Hostnamen des Pi’s zu „ns1″ abgeleitet von „Nameserver 1“.




Domain und Hosts anlegen

Der letzte Schritt der Vorbereitung wäre dann einen Domain Namen festzulegen, mit dem man im Netzwerk die einzelnen Geräte oder den DNS-Server ansprechen will. Um Verwirrungen aus dem Weg zu gehen, empfiehlt es sich bei der Auswahl der Domain auf klassische Domainendungen (TLD) zu verzichten, beispielsweise .de, .com, .org, .net und viele mehr. Auch für mein Beispiel werde ich eine Domain festlegen mit dem Namen „bei.spiel“ und der IP-Adresse 192.168.0.100 für den Nameserver, über diese er erreichbar sein wird.


Die Domain kann dann folgendermaßen im System konfiguriert werden:

$ nano /etc/hosts



und erweitert die Datei mit folgenden Einträgen:

172.0.0.1 localhost
192.168.0.100 ns1.bei.spiel ns1



ns1.bei.spiel

Der dick markierte Teil hier gibt die eigentliche Domain an.


ns1.bei.spiel

Der dick markierte Teil hier gibt die Subdomain an, welcher hier auf den DNS-Server verweist.



Nachdem die Schritte durchgearbeitet wurden, wird der Raspberry Pi neugestartet, damit dieser auch die Einstellungen übernimmt und direkt auch verwendet.




Installation von bind9

Der nächste Schritt ist die eigentliche DNS Software, die nun auf dem Raspberry Pi installiert werden muss. Die wohl bekannteste Open Source Software ist in dem Gebiet „bind9“ und diese wird auch hier verwendet werden. Die Konfigurationsoptionen als auch die Pflege der Software, dank der großen Community, ist unschlagbar und daher führend in der DNS Software.


Für die Installation auf einem Raspbian OS wird keine extra Repository benötigt, die vorher hinzugefügt werden muss. Einzig und allein werden hierzu folgende Pakete benötigt:

$ apt-get install bind9 bind9utils



Diese zwei Pakete beinhalten zu einem die eigentliche DNS Software (bind9) und zu anderem verschiedene Zusatzprogramm, welche nützlich bei der Konfiguration und Wartung des DNS Dienstes sind (bind9utils).


Die Installation wäre damit abgeschlossen und der Raspberry Pi kann erneut neugestartet werden.




Konfiguration des DNS-Servers

Nun kommt man zur eigentlichen Konfiguration des bind9 Systems.




IPv6 oder Ipv4 only?

Die erste Frage die man sich gleich am Anfang stellen muss ist, soll der DNS nur IPv4 oder auch IPv6 Adressen vermitteln? Falls die Entscheidung nun auf einen reinen IPv4 Betrieb gefallen ist, dann werden zukünftig alle Anfragen über IPv6 Adressen vom DNS gedropt. Falls man beides nutzen möchte, wird dieser Konfigurationsschritt einfach übersprungen und ändert nichts an der Default Konfiguration der Datei. Empfohlen wird hier den Defaultwert beizubehalten.


Für den reinen IPv4 Betrieb die Datei bind9 im Verzeichnis /etc/default/ öffnen.

$ vi /etc/default/bind9

OPTIONS=“-4 -u bind“



Danach kann die Datei abgespeichert und mit STRG+X geschlossen werden.




Das Kernsystem

Nachdem Konfigurationsschritt wechselt man in das Kernverzeichnis der Software unter:

$ cd /etc/bind/



In diesem Verzeichnis befinden sich die zwei Hauptkonfigurationsdateien die für die Konfiguration des DNS-Dienstes relevant sind:

/bind/named.conf.options
/bind/named.conf.local




DNS Requests weiterleiten

In der folgenden Datei müssen Angaben über die Weiterleitung von Anfragen an DNS-Server außerhalb des Heimnetzwerkes gemacht werden.


Sobald ein Request von unserem DNS nicht verarbeitet werden kann, zum Beispiel wenn die Seite vorher noch nie über den eigenen Nameserver aufgerufen wurde oder keine gecachten Einträge vorhanden sind, dann muss diese Anfrage an einen anderen DNS weitergegeben werden von dem er dann die nötigen Datensätze erhält. Bei einem erneuten Aufruf der Seite, greift der eigene DNS dann auf seinen Cache zurück und kann die Anfrage direkt lokal verarbeiten. Es ist also keine Kommunikation mit einem anderen DNS-Server mehr nötig, wie es bei dem ersten Schritt der Fall war.


Damit dieser Prozess auch umgesetzt werden kann, benötigt die bind9 Software eine Angabe der forwarders gefüttert mit den IP-Adressen der DNS-Server.


$ vi named.conf.options



Beispielsweise trage ich die Nameserver von openDNS ein.

forwarders {
192.168.0.1;
208.67.222.222;
208.67.220.220;
};



DNS Zonen definieren

Der Nameserver benötigt die Angabe der forward DNS Zone und der reverse DNS Zone um später Hostauflösungen beider Richtungen zu vermitteln. Diese Konfiguration ist ausschlaggebend für die Verarbeitung der Anfragen.




Forward DNS Zone

Diese Zone ist für die klassische Namensauflösung von (Alias-) Domain Name zu IP-Adresse zuständig. In einer extra angelegten Konfigurationsdatei, definieren wir unsere Endgeräte im Netzwerk. Für jedes Endgerät, auch Host genannt, vergeben wir eine eindeutige IP-Adresse und eine Alias-Domain. Diese Informationen verpacken wir in einen speziellen Eintrag den mann Address Record nennt.


Zum Beispiel kann man den Router als Adress Record anlegen, damit dieser später nicht nur über die IP-Adresse sondern auch über die Alias-Domain aufgerufen werden kann.

router IN A 192.168.0.1



Zuerst wird der Hostname definiert, in diesem Beispiel lautet dieser router. Danach definieren wir die records IN für Internet und A für Address.


Wichtig ist hier jedoch, dass der Adress Record A sich nur auf IPv4 Adressen und der Adress Record AAAA sich nur auf reine Ipv6 Adressen bezieht. Als Letztes geben wir die IP-Adresse des Routers mit an.


Durch diesen Adress Record Eintrag wäre der Router beim Betrieb des eigenen DNS im Heimnetzwerk, unter dem Namen router.bei.spiel erreichbar. Eine Hostabfrage würde dann so aussehen:

$ host router.bei.spiel
router.bei.spiel has address 192.168.0.1



Der nächste Schritt wäre nun die Konfiguration anzupassen und dafür öffnet man die Datei named.conf.local

$ vi named.conf.local



und ergänzt diese mit folgenden Zeilen:

# our forward Zone
zone „bei.spiel“ {
type master;
file „/etc/bind/zones/db.bei.spiel“;
};



Der Pfad kann natürlich je nach Wunsch angepasst werden. Ich habe mich allerdings dafür entschieden ein extra Verzeichnis mit dem Namen Zones zu erstellen, einfach nur der besseren Übersicht halber.


Das Verzeichnis erstellt man folgendermaßen:

$ mkdir zones



Sobald man das Verzeichnis erstellt hat, kann die Anpassung der Konfigurationsdatei für die Forward Zone beginnen.


Dafür kopiert man als Vorlage die Datei db.local nennen diese aber in db.bei.spiel um. Hintergrund dieser Aktion ist, dass man mit der bereits vorhandenen Datei db.local schon eine Vorlage der Konfiguration hat, die nun nur noch angepasst werden muss.

cp /etc/bind/db.local etc/bind/zones/db.bei.spiel



Nachdem die Datei kopiert wurde, öffnet man diese und passt die Konfiguration nach folgendem Schema an:

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.bei.spiel. root.bei.spiel. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.bei.spiel.
@ IN A 192.168.0.100
ns1 IN A 192.168.0.100
router IN A 192.168.0.1
www IN CNAME bei.spiel.



TTL – Time to live

Dieser Eintrag gibt an, wie lange der Record clientseitig gecached werden soll. Die Reichweite kann hier von 0 bis 2147483647 (~68 Jahre) selbst definiert werden. Die Angabe 0 setzt fest, dass nicht clientseitig gecached wird.

Empfehlenswert ist hier, die default Einstellungen bei zubehalten.




SOA – Start of Authority

Der so genannte SOA Record gibt verschiedene Informationen über die Aktualität der Zone aus. Beispielsweise wann diese zu letzt aktualisiert wurde.

Empfehlenswert ist auch hier, die default Einstellungen bei zubehalten.

Auf die anderen Punkte werde ich nicht weiter eingehen, da diese selbsterklärend sind und für uns relativ unwichtig, da wir diese auf den default Einstellungen beruhen lassen.




Forward DNS Zone

Diese Zone definiert quasi den Rücklauf, die umgekehrte Suche oder Auflösung anhand der (Alias-) Domain. Unter anderem findet man Verwendung bei Troubleshooting oder auch bei der Benutzung eines eigenen Mailserver. Email’s die von einem Email Server verschickt werden, die keinen reverse DNS Eintrag aufweisen, werden oft gedropt und von den meisten ISP auf eine Art Blacklist verbannt.


Auch hier vergibt man einen ähnlichen Eintrag, jedoch mit einem anderen Record. Wir greifen bei reverse DNS Zonen immer auf eine spezielle Domain namens in-addr.arpa zurück. Der Aufbau ist relativ simpel, jeder Eintrag wird als PTR Record definiert. Wichtig ist hier jedoch, dass wir die IP-Adresse hier in der umgekehrten Reihenfolge dargestellt wird!


Zum Beispiel kann man auch hier den Router in die Datenbank einpflegen, damit man anhand der IP-Adresse die dazugehörige Alias-Domain herausfinden kann.

1 IN PTR router.bei.spiel.



Zuerst wird das 4. Oktett der IP-Adresse, welches genau ein Endgerät definiert, angegeben.


In diesem Fall gibt die 192.168.0.1 den router an.
Danach definieren wir die records IN für Internet und PTR für Pointer, also für die Alias-Domain.
Als Letztes folgt die komplette Alias-Domain des Routers.


Somit hätte man auch einen Eintrag für den Router angelegt. Eine Hostabfrage würde dann so aussehen:

$ host 192.168.0.1
1.0.168.192.in-addr.arpa domain name pointer router.bei.spiel.



Gleiches Spiel wie bei der Forward Zone, allerdings muss das Verzeichnis Zones nicht mehr erstellt werden.


Nun fehlt noch die Anpassung der Konfigurationsdatei für die Reverse Zone.

$ vi named.conf.local



und ergänzt diese mit folgenden Zeilen:

# our reverse Zone
# server IP 192.168.0.100
zone „0.168.192.in-addr.arpa“ {
type master;
file „/etc/bind/zones/db.192“;
};



Danach kopiert man erneut als Vorlage die Datei db.local nennen diese aber in db.192 um. Der Name variiert je nach Subnetzbereich.

cp /etc/bind/db.local etc/bind/zones/db.192



Nachdem die Datei kopiert wurde, öffnet man diese und passt die Konfiguration nach folgendem Schema an:

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.bei.spiel. root.bei.spiel. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.bei.spiel.
1 IN PTR router.bei.spiel.
100 IN PTR ns1.bei.spiel.



Damit wäre die Konfiguration an den jeweiligen Zonen abgeschlossen.




Resolv.conf anpassen

Als Letztes muss noch die Datei resolv.conf angepasst werden. Durch die Angabe des eigenen Nameservers legt man fest, dass sämtliche Anfragen direkt vom eigenen lokalen DNS bearbeitet werden sollen.

$ vi /etc/resolv.conf



und fügt folgenden Eintrag hinzu:

# Generated by resolvconf
nameserver 192.168.0.100



Neustart des bind9

Zum finalen Abschluss startet man den Nameserver neu. Das System sollte nun ok ausspucken. Falls dies nicht der Fall ist, sollte nochmal die Konfiguration überprüft werden, eventuell fehlt ein Semikolon oder ein Punkt ist an falscher Stelle platziert worden.

$ /etc/init.d/bind9 restart



… und fertig ist der eigene DNS-Server im Heimnetzwerk.


over & out,
jonsch