cmoser Wiki - Benutzerbeiträge [de]

FreeBSD als DNS-Server

2024-04-21T17:22:25Z

C9mos: /* Zonen überprüfen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Wenn man keine eigene Domäne registriert hat, kann man die Topleveldomäne ''.internal'' nutzen, um Kollisionen mit bestehenden Domänen zu vermeiden. Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 3D
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet. Das Einfrieren funktioniert nur bei dynamischen Zonen!
<nowiki># rndc freeze 1.168.192.in-addr.arpa</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/1.168.192.in-addr-arpa</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen. Das Auftauen von Zonen funktioniert nur bei dynamischen Zonen.
<nowiki># rndc thaw 1.168.192.in-addr.arpa</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags oder das Vergessen des Adresseneintrags des Nameservers, wenn dieser sich in derselben Zone befindet.

====== Zonen überprüfen======
Mit <code>named-checkzone</code> lassen sich manuell editierte Zonen auf Fehler überprüfen. Das Tool gibt die Art des Fehlers und die jeweilige Zeilennummer an. <named-checkzone> übergibt man als Argumente den Zonennamen und den Pfad der Zonendatei.
<nowiki>named-checkzone meinedomain.de /usr/local/etc/namedb/primary/meinedomain.de</nowiki>

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2024-04-18T19:15:05Z

C9mos: /* Zonen manuell editieren */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Wenn man keine eigene Domäne registriert hat, kann man die Topleveldomäne ''.internal'' nutzen, um Kollisionen mit bestehenden Domänen zu vermeiden. Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 3D
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet. Das Einfrieren funktioniert nur bei dynamischen Zonen!
<nowiki># rndc freeze 1.168.192.in-addr.arpa</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/1.168.192.in-addr-arpa</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen. Das Auftauen von Zonen funktioniert nur bei dynamischen Zonen.
<nowiki># rndc thaw 1.168.192.in-addr.arpa</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags oder das Vergessen des Adresseneintrags des Nameservers, wenn dieser sich in derselben Zone befindet.

====== Zonen überprüfen======
Mit <code>named-checkzone</code> lassen sich manuell editierte Zonen auf Fehler überprüfen. Das Tool gibt die Art des Fehlers und die jeweilige Zeilennummer an. <named-checkzone> übergibt als Argumente den Zonennamen und den Pfad der Zonendatei.
<nowiki>named-checkzone meinedomain.de /usr/local/etc/namedb/primary/meinedomain.de</nowiki>

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2024-04-18T19:10:57Z

C9mos: /* Wie komme ich zu einer Domäne */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Wenn man keine eigene Domäne registriert hat, kann man die Topleveldomäne ''.internal'' nutzen, um Kollisionen mit bestehenden Domänen zu vermeiden. Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 3D
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze 1.168.192.in-addr.arpa</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/1.168.192.in-addr-arpa</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw 1.168.192.in-addr.arpa</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags oder das Vergessen des Adresseneintrags des Nameservers, wenn dieser sich in derselben Zone befindet.

====== Zonen überprüfen======
Mit <code>named-checkzone</code> lassen sich manuell editierte Zonen auf Fehler überprüfen. Das Tool gibt die Art des Fehlers und die jeweilige Zeilennummer an. <named-checkzone> übergibt als Argumente den Zonennamen und den Pfad der Zonendatei.
<nowiki>named-checkzone meinedomain.de /usr/local/etc/namedb/primary/meinedomain.de</nowiki>

===== Zonen mit ''nsupdate'' bearbeiten =====

Hauptseite

2023-10-07T12:11:12Z

C9mos: /* [https://wiki.cmoser.org/index.php/derler2000 Daniel's Seiten */

== Meine Beiträge nach Sektionen Sortiert ==
=== [https://wiki.cmoser.org/index.php/anleitungen Anleitungen] ===
==== Diverse Services ====
* [https://wiki.cmoser.org/index.php/Django_mit_NGINX_unter_Ubuntu-22.04 Django mit NGINX unter Ubuntu-22.04]
* [https://wiki.cmoser.org/index.php/Git_Server_einrichten Git Server einrichten]

==== Raspberry PI ====
* [https://wiki.cmoser.org/index.php/Raspberry_PI_und_FreeBSD_Basissetup Basis Setup von FreeBSD auf einem Raspberry PI]
==== FreeBSD ====
* [https://wiki.cmoser.org/index.php/FreeBSD_als_DNS-Server FreeBSD als DNS-Server]
* [https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]

== Seiten von Freunden ==
=== [https://wiki.cmoser.org/index.php/magoam Magoam's Seiten] ===
=== [https://wiki.cmoser.org/index.php/derler2000 Daniel's Seiten] ===

== Starthilfen ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsparameter]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ Häufige Fragen zu MediaWiki]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ Mailingliste zu neuen Versionen von MediaWiki]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Hauptseite

2023-10-07T12:10:32Z

C9mos: /* Seiten von Freunden */

== Meine Beiträge nach Sektionen Sortiert ==
=== [https://wiki.cmoser.org/index.php/anleitungen Anleitungen] ===
==== Diverse Services ====
* [https://wiki.cmoser.org/index.php/Django_mit_NGINX_unter_Ubuntu-22.04 Django mit NGINX unter Ubuntu-22.04]
* [https://wiki.cmoser.org/index.php/Git_Server_einrichten Git Server einrichten]

==== Raspberry PI ====
* [https://wiki.cmoser.org/index.php/Raspberry_PI_und_FreeBSD_Basissetup Basis Setup von FreeBSD auf einem Raspberry PI]
==== FreeBSD ====
* [https://wiki.cmoser.org/index.php/FreeBSD_als_DNS-Server FreeBSD als DNS-Server]
* [https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]

== Seiten von Freunden ==
=== [https://wiki.cmoser.org/index.php/magoam Magoam's Seiten] ===
=== [https://wiki.cmoser.org/index.php/derler2000 Daniel's Seiten ===

== Starthilfen ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsparameter]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ Häufige Fragen zu MediaWiki]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ Mailingliste zu neuen Versionen von MediaWiki]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Raspberry PI und FreeBSD Basissetup

2023-10-07T11:58:36Z

C9mos: /* System einrichten */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|500px|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|500px|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512
root@rpi# chmod 0600 /var/swap.bin
root@rpi# sysrc swapfile=/var/swap.bin
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Um einen Nutzer ohne Passwortabfrage Programme mit erhöhten Berechtigungen mit doas ausführen zu lassen, gibt fügt man folgende Zeile in die ''/usr/local/doas.conf'' ein:
<nowiki>permit nopass username</nowiki>

Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-07T11:57:55Z

C9mos: /* Basiskonfiguration */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|500px|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|500px|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512
root@rpi# chmod 0600 /var/swap.bin
root@rpi# sysrc swapfile=/var/swap.bin
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Um einen Nutzer ohne Passwortabfrage Programme mit erhöhten Berechtigungen mit doas ausführen zu lassen, gibt fügt man folgende Zeile in die ''/usr/local/doas.conf'' ein:
<nowiki>permit nopass username</nowiki>

Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-07T11:55:54Z

C9mos: /* System einrichten */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|500px|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512
root@rpi# chmod 0600 /var/swap.bin
root@rpi# sysrc swapfile=/var/swap.bin
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Um einen Nutzer ohne Passwortabfrage Programme mit erhöhten Berechtigungen mit doas ausführen zu lassen, gibt fügt man folgende Zeile in die ''/usr/local/doas.conf'' ein:
<nowiki>permit nopass username</nowiki>

Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-07T11:55:10Z

C9mos: /* System einrichten */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|500px|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512
root@rpi# chmod 0600 /var/swap.bin
root@rpi# sysrc swapfile=/var/swap.bin
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Um einen Nutzer ohne Passwortabfrage Programme mit erhöhten Berechtigungen mit doas ausführen zu lassen, gibt fügt man folgende Zeile in die ''/usr/local/doas.conf'' ein:
<nowiki>permit nopass username</nowiki>

Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-07T11:51:44Z

C9mos: /* doas */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512
root@rpi# chmod 0600 /var/swap.bin
root@rpi# sysrc swapfile=/var/swap.bin
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Um einen Nutzer ohne Passwortabfrage Programme mit erhöhten Berechtigungen mit doas ausführen zu lassen, gibt fügt man folgende Zeile in die ''/usr/local/doas.conf'' ein:
<nowiki>permit nopass username</nowiki>

Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:12:53Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512
root@rpi# chmod 0600 /var/swap.bin
root@rpi# sysrc swapfile=/var/swap.bin
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:11:07Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
<nowiki>root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512 
root@rpi# chmod 0600 /var/swap.bin 
root@rpi# sysrc swapfile=/var/swap.bin</nowiki>
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:10:19Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
<nowiki>root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512 
root@rpi# chmod 0600 /var/swap.bin 
root@rpi# echo "swapfile=\"/var/swap.bin\"" >> /etc/rc.conf</nowiki>
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:06:09Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
<nowiki>root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512</nowiki>
root@rpi# chmod 0600 /var/swap.bin<nowiki> 
root@rpi# echo "swapfile=\"/var/swap.bin\"" >> /etc/rc.conf</nowiki>
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:05:49Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
<nowiki>root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512</nowiki> 
root@rpi# chmod 0600 /var/swap.bin<nowiki> 
root@rpi# echo "swapfile=\"/var/swap.bin\"" >> /etc/rc.conf</nowiki>
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:05:07Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
</nowiki>root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512 
root@rpi# chmod 0600 /var/swap.bin<nowiki> 
root@rpi# echo "swapfile=\"/var/swap.bin\"" >> /etc/rc.conf</nowiki>
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Raspberry PI und FreeBSD Basissetup

2023-10-05T18:04:30Z

C9mos: /* Swap Datei erstellen */

== FreeBSD ==
FreeBSD ist ein UNIX® ähnliches Betriebssystem, das auf 4.4BSD-Lite basiert. Es ist anders als Linux, das ja eigentlich nur der Kernel ist, ein komplettes Betriebssystem.
Ursprünglich war BSD (Berkeley Software Distribution) als Erweiterung des von AT&T entwickelten Betriebssystems UNIX® gedacht. Verschiedene Open-Source Projekte basieren auf dieser als 4.4BSD-Lite bekannten Quelltextausgabe. In dieser Softwareausgabe sind auch Quelltexte anderer Open-Source Projekte enthalten, insbesonders jene des GNU-Projekts.
Das Komplette Betriebssystem umfasst:
* Den BSD-Kernel, der sich um Prozess-Scheduling, die Unterstützung mehrerer Prozessoren (SMP – Symmetric Mulit-Processing), Speicherverwaltung, Datenträgerverwaltung, Gerätetreiber und einiges mehr kümmert. Im Gegensatz zu Linux gibt es verschiedene BSD-Kernels mit unterschiedlichen Fähigkeiten.
*Die C-Bibliothek, die die grundlegende API (Application Programming Interface) für Programme ist. Die C-Bibliothek basiert auf Berkeley-Code und nicht auf Quelltexten des GNU Projekts
*Nützliche Programme wie z.B. Shells, Programme für Dateioperationen, Compiler und Linker. Einige dieser Programme stammen noch aus dem GNU-Projekt, andere hingegen nicht.
*Andere nützliche Programme und Services, wie z.B. Sendmail, SSH, FTP und einige mehr.
*Eine Ports-Kollektion, die Programme und Bibliotheken enthält und die über 30.000 Ports enthält.

FreeBSD eignet sich, da keine Desktopumgebung vorinstalliert ist, besonders als Server. Eine Desktopumgebung lässt sich aber nachinstallieren, wenn das erwünscht ist.

Für das Raspberry PI gibt es ein fertiges [https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz FreeBSD 13.1 Image für das RaspberryPI 3 bzw. 4], das direkt auf der [https://freebsd.org FreeBSD Webseite] zum Herunterladen angeboten wird. Wenn man ein Raspberry PI 4 benutzt, sollte man mindestens Version 13.1 vwerwenden, da 13.0 noch einen älteren ''u-boot'' Bootloader verwendet, und man da noch einige Schritte von Hand machen muss, um das Raspberry PI 4 zum Hochfahren zu bewegen.

== Installieren des Images ==
Hat man das Image heruntergeladen, muss es noch auf eine SD-Karte geschrieben werden. Ich empfehle eine mit mindestens 8 GB Speicher zu verwenden, da diese noch genug Platz für weitere Programme hat. Zu groß sollte sie auch nicht sein, da hierbei ein Backup lange dauern kann und es, je nach SD-Karten Größe, einiges Platz auf dem Backup-Medium einnimmt.
Hat man die passende SD-Karte gewählt, muss man noch das Image auf selbige 'brennen'.

Unter Unix geht das ganz einfach mit der Kommandozeile. ${device} steht für das zu beschreibende Gerät. (z. B. ''/dev/sdc'') 
<nowiki>root# xzcat --keep FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz | dd of=${device} bs=4M</nowiki>

Unter Windows muss man ein Programm zum Beschreiben des Images herunterladen. Mit [https://sourceforge.net/projects/win32diskimager/ Win32 Disk Imager] ist es möglich Image-Dateien auf eine SD-Karte zu brennen. Das FreeBSD-Image muss vor dem Brennen noch entpackt werden. Das geht mit sowohl [https://www.7-zip.org/download.html 7-Zip] als auch mit [https://winrar.de/download.php WinRAR].

Ist das Beschreiben der SD-Karte erledigt, kann sie bereits ins Raspberry PI gegeben werden und man kann schon loslegen, den Einplatinencomputer für seine Zwecke zu konfigurieren. Wenn man keine Tastatur und Bildschirm ans Raspberry PI anschließen will, kann man sich auch per SSH (Secure SHell) am Gerät anmelden. Da ein DHCP-Client standardmäßig aktiviert ist, findet man auch im eigenen Netzwerk das Gerät. Eine Voraussetzung dafür ist, dass man bereits einen DHCP-Server (z. B. im Router) betreibt.
Hat man das Gerät im eigenen Netzwerk gefunden, z. B. in den Netzwerkeinstellungen des Routers, kann man sich mit dem Standardnutzer ''freebsd'' mit dem Passwort ''freebsd'' anmelden. Das root-Passwort ist root.
<nowiki>user@localhost$ ssh freebsd@${ip_adresse}</nowiki>

Um sich unter ssh zum Systemadministrator zu machen, gibt man in der Kommandozeile su ein.
<nowiki>freebsd@generic$ su</nowiki>

Wenn man Hilfe zu einem Befehl benötigt, erhält man diese mit dem Befehl ''man''.
<nowiki>freebsd@generic$ man man</nowiki>

== Basiskonfiguration ==
Bevor man loslegt, einen eigenen Server aufzusetzen, sollte man einige Grundkonfigurationen vornehmen, da einige Sicherheitslücken zu Beginn geschlossen werden sollten. Einige Grundeinstellungen lassen sich mit dem Dialog-basierten Tool ''bsdconfig'' erledigen. Dieses Programm trägt die benötigten Einträge in die entsprechenden Dateien ein. Das System wird vor allem über die Datei ''/etc/rc.conf'' gesteuert. Hier werden die Netzwerkeinstellungen und die Services, die es beim Hochfahren zu starten gilt, eingetragen. Diese Datei kann auch von Hand editiert werden. 
<code>man rc.conf</code> gibt Informationen über diese Konfigurationsdatei aus.

Wenn man eine Bourne kompatible Shell gegenüber der ''csh'' bevorzugt kann man mit dem Befehl ''pw'' die Login Shell des jeweiligen Benutzers ändern. 
<nowiki>root@generic# pw usermod root -s /bin/sh</nowiki>

=== Installieren eines Editors ===
Für diejenigen, die mit ''vi'' oder ''ed'' nicht gewohnt sind, empfiehlt es sich einen Editor wie ''nano'' zu installieren. Wenn man mit dem Raspberry PI bereits Internet Zugang hat kann man einen Editor wie folgt installieren. 
<nowiki>root@rpi# pkg install -y nano</nowiki>

Um den installierten Editor als Standardeditor zu nutzen, editiert man die ''~/.profile'' und ändert die Variable '''EDITOR'''. 
<nowiki>EDITOR=nano; export EDITOR</nowiki>

Um den Editor gleich zu aktivieren, muss man die Datei ''~/.profile'' erneut laden. 
<nowiki>user@rpi$ . ~/.profile</nowiki>

Sollte man auch für '''root''' den Standardeditor ändern wollen, sind die oben genannten Schritte auch unter den Nutzer '''root''' auszuführen.

=== root Passwort ändern und Benutzer anlegen ===
[[Datei:FreeBSD adduser.png|gerahmt|alternativtext=FreeBSD adduser image|FreeBSD adduser]]
Das root-Passwort gehört unbedingt geändert, da ansonsten jeder in der Lage ist, über das Standardpasswort Administrator Rechte zu erlangen. Man kann sich zwar nicht über Secure Shell als root anmelden, man hat aber dennoch Zugriff auf den Benutzer ''freebsd'' mit dem Standardpassword ''freebsd''. Selbiger befindet sich noch in der Gruppe ''wheel'', was einem ermöglicht ''su'' auszuführen. Das root-Passwort kann man mit ''bsdconfig'' geändert werden oder in der Shell.
<nowiki>root@generic# passwd</nowiki>

FreeBSD beginnt mit der Vergabe der User-IDs bei 1001, die meisten Linux-Distributionen allerdings bei 1000. Man sollte sich seinen Standardnutzer mit der UID 1000 anlegen und ihn zumindest in die Gruppe ''wheel'' aufnehmen. Des Weiteren empfiehlt es sich, die Nutzer-IDs von seiner Linux-Distribution, sofern man eine hat, im FreeBSD-System zu übernehmen. Sollte man ein NFS (Network File System) am Laufen haben, macht es sich bezahlt, da hier die Zugriffsrechte über die Nutzer- und Gruppen-IDs vergeben werden.

Die Nutzer können sowohl mit dem Tool ''bsdconfig'' angelegt werden als auch in der Shell. In der Shell geht es sowohl mit ''pw'' als auch mit dem Befehl ''adduser''.

==== Passwortlose Anmeldung mit SSH ====
Wenn man einen neuen Nutzer angelegt hat, kann man sich als Nutzer ''freebsd'' abmelden. Das geht mit dem Befehl ''exit''. Und sich als neuer User anmelden. Um sich ohne Passwort anmelden zu können, kann man sich ein Secure-Shell Schlüsselpaar mit ''ssh-keygen'' erstellen, was auch unter Windows gelingt. Danach muss der öffentliche Schlüssel der Datei ''~/.ssh/authorized_keys'' im Zielsystem angehängt werden. Unter Unix/Linux geht das mit dem Befehl ''ssh-copy-id''.
<nowiki >user@connect-from$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host</nowiki>

Unter Windows hat man entweder [https://www.msys2.org/ MSys2] oder [http://cygwin.org/ Cygwin] installiert oder man geht einen längeren Weg. Die zuvor genannten Programme bringen eine Unix/Linux ähnliche Umgebung nach Windows. Der längere Weg sieht wie folgt aus: Kopieren der id_rsa.pub Dateien in den Benutzerordner des Zielsystems und selbige danach an die ''authorized_keys''-Datei anhängen.
<nowiki>c:\Users\self> sftp user@host
sftp> put .ssh/id_rsa.pub self.sshkey
sftp> exit

c:\Users\self> ssh user@host

user@generic$ cat self.sshkey >> ~/.ssh/authorized_keys</nowiki>

Ist das erledigt, kann man sich ohne Passwortauthentifizierung am Raspberry PI mit Secure-Shell anmelden.

Sollte man sich einen anderen Nutzer angelegt haben, kann man den '''freebsd'''-Account löschen. Das geht mit ''pw''.
<nowiki>root@generic# pw userdel freebsd</nowiki>

=== System einrichten ===
Die Basiskonfiguration des Systems lässt sich am einfachsten mit dem Tool ''bsdconfig'' einrichten.
[[Datei:FreeBSD bsdconfig.png|gerahmt|alternativtext=FreeBSD adduser|FreeBSD adduser]]

==== Zeitzone (Timezone) ====
Die Zeitzoneneinstellung bestimmt, in welcher Zeitzone man sich befindet und damit die Systemzeit in der lokalen Zeit angezeigt wird. Für uns ist das wahrscheinlich '''Europe -@gt; Germany''' oder '''Europe -> Austria'''.

==== Network Management ====
In den Netzwerkeinstellungen gilt es zuerst den Hostnamen zu bestimmen. Die Einstellung hierfür befindet sich in ''bsdconfig'' unter '''Network Management -> Hostname/Domain'''. Man kann den Namen mit vollständiger Domäne angeben. Man sollte aber keine Domäne erfinden, sondern sich [https://www.ionos.de/ eine eigene Domäne registrieren] lassen, wenn man eine braucht. Eine eigene Domain kostet normalerweise keine 20 € im Jahr. Bei den meisten Webhosting angeboten ist sogar eine Domain inkludiert. Wenn man seinen eigenen DNS-Server am laufen hat und eine bestehende Domäne überschreibt, kann man nicht mehr auf die Services dieser Domäne im Internet zugreifen. Hier ist also etwas Vorsicht geboten. Ich nutze hierfür aber meine eigene Domain, da ich hier auch die DNS-Daten des Internet-DNS-Servers übernehme.

===== Network Devices =====
Hier gilt es, die IP-Adresse des Rechners zu bestimmen. Das Netzwerkgerät heißt am Raspberry PI 3 '''ue0''' und am Raspberry PI 4 '''genet0'''. Man sollte im Router oder am DHCP-Server nachsehen, in welchen Bereich die IP-Adressen vergeben werden, um Netzwerkkollisionen zu vermeiden. Man kann das Gerät auch auf DHCP stellen, um eine automatisch vergebene IP-Adresse zu erhalten. Will man das Raspberry PI aber als Server betreiben, empfiehlt es sich eine statische IP-Adresse zu wählen (z. B. 192.168.1.254). Die Adressen x.x.x.0 sind für das Netzwerk selbst und die Adressen x.x.x.255 sind als Broadcastadressen reserviert und sollten möglichst nicht genommen werden. Man sollte auch, wenn man nicht weiß, was man tut, im zugewiesenen Adressbereich des DHCP-Servers bleiben. Wenn z. B. bereits zugewiesene die Adresse mit 192.168.1. beginnt, sollte man auch in diesem Bereich bleiben.

Die Netzmaske, die normalerweise 255.255.255.0 ist, sollte man auch so belassen, damit man im selben Adressraum des eigentlichen Netzwerks bleibt.

===== Wireless Networks =====
Diese Einstellung kann man getrost auslassen, da dar Drahtlos-Netzwerkadapter des Raspberry PI nicht unterstützt wird.

===== Default Router/Gateway =====
Hier gibt man die IP-Adresse des Internet-Routers ein. Die Adresse des Routers steht normalerweise auf der Unter- bzw. der Rückseite des Routers. Wenn man eine falsche Adresse angibt, kann man sich später nicht mit dem Internet verbinden.

==== Startup ====
Unter '''Startup -> Toggle Startup Services''' sollte man ''growfs'' deaktivieren, da dieser Dienst nur einmal zum Vergrößern der Hauptpartition auf die Größe der gesamten SD-Karte benötigt wird und das Raspberry PI ansonsten bei jedem Neustart versucht, diese Partition zu vergrößern. Das wurde aber bereits beim ersten Starten erledigt.
Des weiteren sollten die Services '''ntpdate''', zum synchronisieren der Uhr mit der Atomuhr und '''powerd''', um dem Raspberry PI es zu ermöglichen den Prozessortakt auf 1200 MHz (RPI3) bzw. 1500 MHz (RPI4) anstelle der ansonsten nur 600 MHz erhöhen zu können.

Da da Raspberry PI über keine Echtzeituhr verfügt sollte man '''ntpdate''' via cron-job mindestens ein mal pro Tag neu starten. Dazu aber später mehr.

==== Dateisystemeinstellungen ====
Die Dateisysteme unter Unix ähnlichen Betriebssystemen werden nicht wie unter Windows in Laufwerke aufgeteilt, sondern sie werden direkt ins Dateisystem, d.h. ein Verzeichnis, eingebunden. Angefangen von der root-Dateisystem (''/'') können auch andere Verzeichnisse auf eine eigene Partition verweisen. Zum Beispiel kann ''/home'' auf einer eigenen Partition liegen. Die Deteisystemtabelle befindet sich in der Datei '''/etc/fstab'''. Das Layout dieser Tabelle ist, in einer Reihe mit Leerzeichen getrennt:
* Partition/Ursprung
* Einbindepunkt (Mountpint)
* Dateisystemformat
* Optionen
* Dump-Frequenz (in Tagen)
* Pass Nummer für paralellen fsck

Da die Option '''noatime''' standardmäßig nicht für das root-Dateisystem gesetzt ist, und das Raspberry PI somit jeden Dateizugriff mit protokolliert, was die Lebenserwartung der SD-Karte, auf der das sich Betriebssystem befindet, stark verkürzt, werden wir das ändern. Als '''root''' führen wir <code>nano /etc/fstab</code> aus und editieren die Datei. In der Zeile mit dem Mountpoint ''/'' fügen wir die Option '''noatime''' hinzu. Die Zeile sollte danach wie folgt aussehen:
<nowiki>/dev/ufs/rootfs / ufs rw,noatime 1 1</nowiki>

=== Swap Datei erstellen ===
Wenn man ein Raspberry PI als Server einsetzen möchte, kann das Erstellen einer Auslagerungsdatei sinnvoll sein, denn wenn ein Prozess zu viel Arbeitsspeicher verbraucht, könnte dieser abrupt beendet werden, was bei einem Server nicht gerade gut ist. Da das Raspberry PI 3 nur über 1 GB RAM verfügt, kann das durchaus Sinn machen, wenn ein Prozess kurzzeitig mehr Arbeitsspeicher verbraucht als er sollte. Wenn man eine Auslagerungsdatei erstellen möchte, muss man zuerst die Datei erzeugen (im Beispiel eine 2 GB große Datei) und dann der Datei die richtigen Zugriffsrechte zuweisen. 
</nowiki>root@rpi# dd if=/dev/zero of=/var/swap.bin bs=4M count=512 
root@rpi# chmod 0600 /var/swap.bin<nowiki> 
root@rpi# echo "swapfile=\"/var/swap.bin\"" >> /etc/rc.conf</nowiki>
Nach dem Neustart des Systems wird die Swap-Datei eingebunden.

Man kann aber auch die Swap-Datei ohne Neustart aktivieren:
<nowiki>root@rpi# mdconfig -a -t vnode -f /var/swap.bin -u 99
root@rpi# swapon /dev/md99</nowiki>

Um die Eingebundenen Swap-Bereiche anzuzeigen gibt man als '''root''' <code>swapinfo -k</code> im Terminal ein.

=== System neu starten ===
Die Basiseinstellungen sind nun abgeschlossen und das System kann neu gestartet werden, um sicherzustellen, dass alles funktioniert wie geplant und das System auch nach einem Stromausfall wieder hochfährt.
<nowiki>root@rpi# reboot</nowiki>

=== Cronjobs ===
Cronjobs sind Programme und Scripte, die periodisch ausgeführt werden. Einen Cronjob erstellt man, indem man <code>crontab -e</code> als jeweiliger Benutzer ausführt und anschließend die dabei geöffnete Datei editiert. Das Format eines Cronjobs ist:
* Minute (0-59) oder '''*''' für jede Minute
* Stunde (0-23) oder '''*''' für jede Stunde
* Tag des Monats (1-31) oder '''*''' für jeden Tag
* Monat (1-12) oder '''*''' für jeden Monat
* Wochentag (0-7), wobei 0 und 7 Sonntag ist oder '''*'''
<code>man 5 crontab</code> gibt eine genaue Auskunft über das verwendete Format.

Um Cronjobs zu erstellen, die den Service ''ntpdate'' um jeden Tag um 11:00 und 23:00, nach dem Verstreichen einer zufälligen Zeit zwischen 0 Sekunden und einer Stunde, neu starten, um die Systemzeit zu aktualisieren fügt man folgende Zeile in die, als ''root'' durch <code>crontab -e</code> geöffnete Datei folgende Zeilen ein:
<nowiki>0 11,23 * * * sleep $(( RANDOM % 3600 ))s && service ntpdate restart</nowiki>

== Softwareinstallation ==
Unter FreeBSD ist die Software von Drittanbietern in Ports gegliedert. Die Binärpakete unter FreeBSD sind so erstellt, dass sie so wenig Abhängigkeiten wie möglich haben. Wenn man jedoch eine Quelltextinstallation vorzieht, ist dies natürlich auch möglich. Die Ports-Kollektion lässt sich mit '''portsnap''' herunterladen und installieren. Die Ports werden in das Verzeichnis ''/usr/ports'' installiert.
<nowiki>root@rpi# portsnap fetch install</nowiki>
Mit '''portsnap''' lässt sich auch die Ports-Kollektion updaten.
<nowiki>root@rpi# portsnap fetch update</nowiki>

Um einen Port zu bauen, wechselt man in das Verzeichnis des gewählten Ports und führt '''make''' aus.
<nowiki>root@rpi# cd /usr/ports/security/sudo
root@rpi# make config-recursive
root@rpi# make install</nowiki>
Das Erstellen der Ports aus den Quellen kann einige Zeit in Anspruch nehmen und es verringert die Lebensdauer der SD-Karte maßgeblich, da viele Schreibvorgänge zum Erstellen erforderlich sind. Was nicht heißen soll, dass es nicht möglich ist, sein System aus den Quellen zu erstellen.

Wer Binärpakete bevorzugt, kann mit '''pkg''' seine Programme installieren und aktuell halten.<code>man pkg</code> gibt Auskunft über die genaue Benutzung des Paketmanagers. 
<code>pkg install paketname ...</code> installiert die genannten Pakete. 
<code>pkg search paketname</code> sucht nach dem gewünschten Paket. 
<code>pkg update</code> macht ein Update des Paket-Repositorys. 
<code>pkg upgrade</code> macht ein Update der installierten Pakete. 

=== sudo/doas ===
Wer Linux nutzt, kommt früher oder später mit dem Programm '''sudo''' in Kontakt. Mit '''sudo''' lassen sich Programme als ein anderer Nutzer ausführen. Das ist praktisch, wenn man nicht immer mit '''su''' zum Nutzer ''root'' wechseln will oder muß. '''doas''' ist eine einfache '''sudo'''-Alternative. '''Eine falsche Konfiguration dieser Programme kann eine erhebliche Sicherheitslücke sein!'''

==== sudo ====
Um sudo wie unter Linux gewohnt nutzen zu können, muss man die sudo zuerst installieren und danach Konfigurieren. Um '''sudo''' in seinen gewohnten Editor zu editieren, sollte man ihn zuerst zuvor beschrieben in der Datei ''.profile'' einstellen.
<nowiki>root@rpi# pkg install -y sudo
root@rpi# visudo</nowiki>

In der jetzt geöffneten Datei, die gut dokumentiert ist, fügt man folgende Zeile hinzu:
<nowiki>%wheel ALL=(ALL:ALL) ALL</nowiki>
Somit können alle, die sich in der Gruppe '''wheel''' befinden, '''sudo''', wie unter Linux gewohnt, benutzen.

==== doas ====
'''doas''' ist wie zuvor schon erwähnt eine '''sudo'''-Alternative. Um '''doas''' nutzen zu können, muss man zuerst die Datei ''/usr/local/doas.conf'' anlegen. Wenn man den folgenden Zeile in die Datei einfügt, kann man '''doas''' wie '''sudo''' nutzen und erlaubt das wechseln der Gruppe '''wheel''' auf alle Nutzer. 
<nowiki>permit :wheel</nowiki>
Eine genaue Anleitung über diese Datei erhält man mit <code>man doas.conf</code>.

== Links ==
* [https://www.freebsd.org FreeBSD Homepage]
* [https://docs.freebsd.org/de/books/handbook/ FreeBSD Handbuch (Deutsch)]
* [https://docs.freebsd.org/en/books/handbook/ FreeBSD Handbook (Englisch)]
* [https://forums.freebsd.org FreeBSD Forum]

Git Server einrichten

2023-05-25T11:38:52Z

C9mos: /* Git über das git Protokoll verteilen */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===
TODO

=== Git über das ''git Protokoll'' verteilen ===
Der ''git-daemon'' eignet sich für den unautorisierten Zugriff auf Git-Repositorien. Diese sind für alle Teilnehmer in einem Netzwerk verfügbar. Sollte sich der Git-Server im Internet befinden, werden alle freigegebenen Repositorien für jeden verfügbar gemacht, befindet sich der Git-Server hinter einer Firewall, werden die freigegebenen Repositorien für jeden im selben Netzwerk abrufbar. Das eignet sich für öffentliche Repositorien bzw. Repositorien, die von jedem sich im selben Netzwerk befindenden, abgerufen können sollen.

Um ein Repository freizugeben, muss sich im Hauptverzeichnis des Repositorys eine leere Datei mit dem Namen ''git-daemon-export-ok'' befinden. Diese Datei teilt dem Git-Daemon mit, dass dieses Repository mit der Welt geteilt werden darf. Also legen wir eine leere Datei mit dem vorher genannten Namen in unserem Test-Repository an, um den Daemon zu testen.
<nowiki>git@gitserver$ touch /home/git/repositories/test.git/git-daemon-export-ok</nowiki>

'''TODO'''

=== Git über http ===
TODO

Git Server einrichten

2023-05-25T11:38:03Z

C9mos: /* Git über das git Protokoll verteilen */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===
TODO

=== Git über das ''git'' Protokoll verteilen ===
Der ''git-daemon'' eignet sich für den unautorisierten Zugriff auf Git-Repositorien. Diese sind für alle Teilnehmer in einem Netzwerk verfügbar. Sollte sich der Git-Server im Internet befinden, werden alle freigegebenen Repositorien für jeden verfügbar gemacht, befindet sich der Git-Server hinter einer Firewall, werden die freigegebenen Repositorien für jeden im selben Netzwerk abrufbar. Das eignet sich für öffentliche Repositorien bzw. Repositorien, die von jedem sich im selben Netzwerk befindenden, abgerufen können sollen.

Um ein Repository freizugeben, muss sich im Hauptverzeichnis des Repositorys eine leere Datei mit dem Namen ''git-daemon-export-ok'' befinden. Diese Datei teilt dem Git-Daemon mit, dass dieses Repository mit der Welt geteilt werden darf. Also legen wir eine leere Datei mit dem vorher genannten Namen in unserem Test-Repository an, um den Daemon zu testen.
<nowiki>git@gitserver$ touch /home/git/repositories/test.git/git-daemon-export-ok</nowiki>

'''TODO'''

=== Git über http ===
TODO

Git Server einrichten

2023-05-25T11:08:06Z

C9mos: /* Git über das git Protokoll verteilen */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===
TODO

=== Git über das ''git'' Protokoll verteilen ===
Der ''git-daemon'' eignet sich für den unautorisierten Zugriff auf Git-Repositorien. Diese sind für alle Teilnehmer in einem Netzwerk verfügbar. Sollte sich der Git-Server im Internet befinden, werden alle freigegebenen Repositorien für jeden verfügbar gemacht, befindet sich der Git-Server hinter einer Firewall, werden die freigegebenen Repositorien für jeden im selben Netzwerk abrufbar. Das eignet sich für öffentliche Repositorien bzw. Repositorien, die von jedem sich im selben Netzwerk befindenden, abgerufen können sollen.

Um ein Repository freizugeben, muss sich im Hauptverzeichnis des Repositorys eine leere Datei mit dem Namen ''git-daemon-export-ok'' befinden. Diese Datei teilt dem Git-Daemon mit, dass dieses Repository mit der Welt geteilt werden darf. Also legen wir eine leere Datei mit dem vorher genannten Namen in unserem Test-Repository an, um den Daemon zu testen.
<nowiki>git@gitserver$ touch /home/git/repositories/test.git/git-daemon-export-ok</nowiki>

<code>TODO</code>

=== Git über http ===
TODO

Git Server einrichten

2023-05-25T11:06:32Z

C9mos: /* Git über das git Protokoll verteilen */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===
TODO

=== Git über das ''git'' Protokoll verteilen ===
Der ''git-daemon'' eignet sich für den unautorisierten Zugriff auf Git-Repositorien. Diese sind für alle Teilnehmer in einem Netzwerk verfügbar. Sollte sich der Git-Server im Internet befinden, werden alle freigegebenen Repositorien für jeden verfügbar gemacht, befindet sich der Git-Server hinter einer Firewall, werden die freigegebenen Repositorien für jeden im selben Netzwerk abrufbar. Das eignet sich für öffentliche Repositorien bzw. Repositorien, die von jedem sich im selben Netzwerk befindenden, abgerufen können sollen.

Um ein Repository freizugeben, muss sich im Hauptverzeichnis des Repositorys eine leere Datei mit dem Namen ''git-daemon-export-ok'' befinden. Diese Datei teilt dem Git-Daemon mit, dass dieses Repository mit der Welt geteilt werden darf. Also legen wir eine leere Datei mit dem vorher genannten Namen in unserem Test-Repository an, um den Daemon zu testen.
<nowiki>git@gitserver$ touch /home/git/repositories/test.git/git-daemon-eport-ok</nowiki>

<code>TODO</code>

=== Git über http ===
TODO

Git Server einrichten

2023-05-25T09:30:43Z

C9mos: /* GIT über das git Protokoll verteilen */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===
TODO

=== Git über das git Protokoll verteilen ===
TODO

=== Git über http ===
TODO

Git Server einrichten

2023-05-25T09:29:52Z

C9mos: /* Shellzugriff einschränken */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===
TODO

=== GIT über das git Protokoll verteilen ===
TODO

=== GIT über http ===
TODO

Git Server einrichten

2023-05-25T07:37:19Z

C9mos: /* Installation von Git */

Git Server einrichten

2023-05-25T07:36:41Z

C9mos: /* Installation von Git */

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
Unter Ubuntu geht das wie folgt:
<nowiki>$ sudo apt update && sudo apt install -y git</nowiki>
Und unter FreeBSD:
<nowiki># pkg pkg install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
Unter Ubunto geht das wie folgt:
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /home/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /home/git/{repositories,.ssh} && sudo -u git chmod 0700 /home/git/.ssh
$ sudo -u git touch /home/git/.ssh/authorized_keys && chmod 0600 /home/git/.ssh/authorized_keys</nowiki>
Und unter FreeBSD:
<nowiki># pw useradd git -c "GIT Nutzer" -d /home/git -g git -s /bin/sh -u 10000
# mkdir -p /home/git/repositories /home/git.ssh
# chown git:git /home/git/repositories
# chown git:git /home/git/.ssh && chmod 0700 /home/git/.ssh
# touch /home/git/.ssh/authorized_keys \
&& chown git:git /home/git/.ssh/authorized_keys \
&& chmod 0600 /home/git/.ssh/authorized_keys<nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.

=== Test Repository erstellen ===
Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===

Git Server einrichten

2023-05-25T07:21:40Z

C9mos:

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Softwareprojekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 bzw. FreeBSD installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
<nowiki>sudo apt update && sudo apt install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /srv/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /srv/git/{repositories,.ssh} && sudo -u git chmod 0700 /srv/git/.ssh
$ sudo -u git touch /srv/git/.ssh/authorized_keys && chmod 0600 /srv/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.
A
=== Test Repository erstellen ===

Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===

Hauptseite

2023-05-25T07:20:28Z

C9mos: /* Meine Beiträge nach Sektionen Sortiert */

== Meine Beiträge nach Sektionen Sortiert ==
=== [https://wiki.cmoser.org/index.php/anleitungen Anleitungen] ===
==== Diverse Services ====
* [https://wiki.cmoser.org/index.php/Django_mit_NGINX_unter_Ubuntu-22.04 Django mit NGINX unter Ubuntu-22.04]
* [https://wiki.cmoser.org/index.php/Git_Server_einrichten Git Server einrichten]

==== Raspberry PI ====
* [https://wiki.cmoser.org/index.php/Raspberry_PI_und_FreeBSD_Basissetup Basis Setup von FreeBSD auf einem Raspberry PI]
==== FreeBSD ====
* [https://wiki.cmoser.org/index.php/FreeBSD_als_DNS-Server FreeBSD als DNS-Server]
* [https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]

== Seiten von Freunden ==
=== [https://wiki.cmoser.org/index.php/magoam Magoam's Seiten] ===

== Starthilfen ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsparameter]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ Häufige Fragen zu MediaWiki]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ Mailingliste zu neuen Versionen von MediaWiki]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Git Server unter Ubuntu-22.04

2023-05-25T07:16:42Z

C9mos: C9mos verschob die Seite Git Server unter Ubuntu-22.04 nach Git Server einrichten

#WEITERLEITUNG [[Git Server einrichten]]

Git Server einrichten

2023-05-25T07:16:42Z

C9mos: C9mos verschob die Seite Git Server unter Ubuntu-22.04 nach Git Server einrichten

Versionskontrollsysteme wie Git sind in der modernen Softwareentwicklung für die "Best Practices" nicht mehr wegzudenken. Sie erlauben es, Änderungen der Software auf Quelltextebene mitzuverfolgen. Git erlaubt zudem frühere Versionen der Software wieder herzustellen und mit Zweigen (''branches'') unterschiedliche Versionen von Dateien und Verzeichnissen zu erstellen.

Viele Software Projekte setzen auf Services wie ''Github'', ''GitLab'' oder ''Bitbucket'' um ihre Software zu versionieren und diese zu verteilen. Wir werden uns aber in diesem Tutorial unseren eigenen Git-Server unter Ubuntu 22.04 installieren, da man nicht jedes Projekt im Internet finden soll. Das gilt vor allem dann, wenn man seine eigenen Konfigurationsdateien mit Git versioniert.

== Installation von Git ==
Zuerst sollte man überprüfen, ob Git bereits installiert ist. 
<nowiki>git --version</nowiki>
Wird dieser Befehl mit einem Fehler quittiert, ist Git nicht installiert und muss noch dem System hinzugefügt werden. 
<nowiki>sudo apt update && sudo apt install -y git</nowiki>
Ein erneutes <code>git --version</code> gibt dann die installierte Git-Version aus. Für den Git-Server haben wir somit die benötigte Software installiert.

=== Git-Nutzer anlegen ===
Als Nächstes müssen wir noch einen Git-Nutzer, unter dem der Server laufen soll, anlegen. Dieser Nutzer hostet die ganzen Git-Repositorien und macht sie im Netzwerk verfügbar. Über SecureShell werden die Repositorien den angelegt und verwaltet. Die Repositorien befinden sich im Verzeichnis ''/srv/git/repositories''. Ein ''.ssh'' Verzeichnis, in dem sich in der Datei ''authorized_keys'' befindet, welche die zur Anmeldung erlaubten öffentlichen Schlüssel der Nutzer enthält, muss, mit den entsprechenden Berechtigungen, auch noch angelegt werden. 
<nowiki>$ sudo useradd --comment "Git Nutzer" --home-dir /srv/git --create-home --password PASSWORD --uid 10000 --user-group
$ sudo -u git mkdir /srv/git/{repositories,.ssh} && sudo -u git chmod 0700 /srv/git/.ssh
$ sudo -u git touch /srv/git/.ssh/authorized_keys && chmod 0600 /srv/git/.ssh/authorized_keys</nowiki>

Jetzt müssen noch die Schlüssel der Benutzer in die Datei eingefügt werden. Wenn die Nutzer noch kein ssh-Schlüsselpaar haben, lässt sich selbiges mit dem Befehl <code>ssh-keygen</code> anlegen.
Mit <code>cat ~/.ssh/id_rsa.pub</code> lässt sich der öffentliche Schlüssel anzeigen.

Mit ''ssh-copy-id'' lassen sich die Schlüssel dann am Server eintragen.
<nowiki>$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@git-server</nowiki>

Oder man kopiert die öffentlichen Schlüssel auf den Git-Server und hängt sie der Datei ''~/.ssh/authorized_keys'' an.
<nowiki>$ users="chris anna patrick udo"

# Kopieren der Nutzer auf den Server
$ for i in $users; do
> sudo scp /home/${i}/.ssh/id_rsa.pub git@gitserver:/tmp/git.${i}.ssh-key
> done

# Anmelden am gitserver mit dem Nutzer "git"
$ ssh git@gitserver

# Anhängen der öffentlichen Schlüssel an ~/.ssh/authorized_keys
git@gitserver$ for i in /tmp/git.*.ssh-key; do
git@gitserver> cat $i >> ~/.ssh/authorized_keys && rm $i
git@gitserver> done

# Abmelden am Server
git@gitserver$ exit</nowiki>

Hat man den eigenen Schlüssel auf dem Git-Server übertragen, sollte man versuchen, sich als ''git'' am Server anzumelden. Kann man sich ohne Passworteingabe anmelden, hat man alles richtig gemacht.
A
=== Test Repository erstellen ===

Als Nächstes erstellen wir ein Test-Repository, um unseren Server zu testen. Wir erstellen ein ''bare'' Repository, da wir am Server keine Commits machen, sondern nur ''push'' und ''pull'' Operationen durchführen, außer wir legen ein neues Repository an.
<nowiki>git@gitserver$ mkdir -p repositories/test.git
git@gitserver$ cd repositories/test.git
git@gitserver$ git init --bare</nowiki>

Jetzt können wir am Client ein Repository anlegen und selbiges an den Server übertragen.
<nowiki>$ mkdir test.git
$ cd test.git
$ git init
$ echo "Das ist ein Test" >> test.txt
$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin git@gitserver:repositories/test.git
$ git push origin master</nowiki>

Ab jetzt können Sie das Repository klonen und daran Änderungen vornehmen.
<nowiki>$ git clone git@gitserver:repositories/test.git
$ cd test
$ nano README
$ git add .
$ git commit -am "README hinzugefügt"
$ git push origin master</nowiki>

Mit dieser Methode können Sie einen Read/Write-Git-Server für mehrere Entwickler in Betrieb nehmen.

=== Shellzugriff einschränken ===

FreeBSD als DNS-Server

2023-05-18T19:59:43Z

C9mos: /* Zonen überprüfen = */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 3D
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze 1.168.192.in-addr.arpa</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/1.168.192.in-addr-arpa</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw 1.168.192.in-addr.arpa</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags oder das Vergessen des Adresseneintrags des Nameservers, wenn dieser sich in derselben Zone befindet.

====== Zonen überprüfen======
Mit <code>named-checkzone</code> lassen sich manuell editierte Zonen auf Fehler überprüfen. Das Tool gibt die Art des Fehlers und die jeweilige Zeilennummer an. <named-checkzone> übergibt als Argumente den Zonennamen und den Pfad der Zonendatei.
<nowiki>named-checkzone meinedomain.de /usr/local/etc/namedb/primary/meinedomain.de</nowiki>

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:59:18Z

C9mos: /* Zonen manuell editieren */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 3D
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze 1.168.192.in-addr.arpa</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/1.168.192.in-addr-arpa</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw 1.168.192.in-addr.arpa</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags oder das Vergessen des Adresseneintrags des Nameservers, wenn dieser sich in derselben Zone befindet.

====== Zonen überprüfen =======
Mit <code>named-checkzone</code> lassen sich manuell editierte Zonen auf Fehler überprüfen. Das Tool gibt die Art des Fehlers und die jeweilige Zeilennummer an. <named-checkzone> übergibt als Argumente den Zonennamen und den Pfad der Zonendatei.
<nowiki>named-checkzone meinedomain.de /usr/local/etc/namedb/primary/meinedomain.de</nowiki>

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:45:26Z

C9mos: /* Erstellen der Forward Lookup Zone */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 3D
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:45:02Z

C9mos: /* Erstellen einer Reverse Lookup Zone */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3D
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 3D
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:42:12Z

C9mos: /* Primäre Zonen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein. In diesem Beispiel ein statische Zone, die keine dynamischen Updates erfahern darf.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:41:03Z

C9mos:

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. Diese erstellen wir in diesem Beispiel als dynamische Zone. Um die Zone dynamisch, wie z.B. mit <code>nsupdate</code> oder einem DHCP-Server dynamisch verändern zu können, kommt in der Zonenkonfiguration Option <code>allow-update</code> hinzu. Hier gibt man die IP-Adressen oder rndc-Schlüssel an, die die Zone verändern dürfen.
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
127.0.0.1; // localhost
key "meinedomainde-key"; // der Schlüssel, mit dem man die Zone verändern darf
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:35:55Z

C9mos: /* Primäre Zonen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
zone "meinedomain.de" {
type primary;
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T19:21:58Z

C9mos: /* Sekundäre Zonen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
zone "meinedomain.de" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

==== Konfiguration überprüfen und neu laden ====
Hat man die Konfiguration verändert, kann man die Konfiguration vor dem Neuladen mit <code>named-checkconf</code> überprüfen. Sollten Fehler in der Konfiguration vorhanden sein, werden diese mit Zeilennummern ausgegeben, was die Fehlerbehebung deutlich vereinfacht. Mit <code>rndc reconfig</code> kann im Anschluss die Konfiguration neu geladen werden. Und das, ohne den Server neu starten zu müssen. Das ist vor allem dann sehr nützlich, wenn man viele große Zonen abbildet und der Neustart des Servers dadurch lange dauert.
<nowiki># named checkconf
# rndc reconfig</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-18T17:43:06Z

C9mos: /* Primäre Zonen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
zone "meinedomain.de" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-15T16:37:21Z

C9mos: /* Installation und Konfiguration von BIND */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden oder die Konifuration neu geladen werden.
Entweder mit:
<nowiki># service named restart</nowiki>
Oder:
<nowiki># rndc reconfig</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-15T16:14:28Z

C9mos: /* Erstellen einer Reverse Lookup Zone */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa. IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.

Eine komplette IPv6 Zone sieht wie folgt aus:
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T13:20:32Z

C9mos: /* Erstellen der Zonendatei */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einemb ORIGIN-Eintrag, der den Gültigkeitsbereich der jeweiligen Zone angibt. Gefolgt wird dieser von einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird, mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$ORIGIN meinedomain.de.
$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$ORIGIN 1.168.192.in-addr.arpa.
$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T11:13:05Z

C9mos: /* Erstellen einer Reverse Lookup Zone */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
@ IN NS ns1.meinedomain.de.
@ IN NS ns2.meinedomain.de.
; mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
@ IN NS ns1.meinedomain.de
@ IN NS ns2.meinedomain.de

; Mailserver
@ IN MX 30 mail1.meinedomain.de.
@ IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T10:15:32Z

C9mos: /* Zonen manuell editieren */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedomain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T10:14:23Z

C9mos: /* Erstellen einer Reverse Lookup Zone */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T10:07:27Z

C9mos: /* Zonen manuell editieren */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN NS mail1.meinedomain.de.
IN NS mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Will man eine Zone einfach nur neu laden, lässt sich das mit <code>rndc reload</code> bewerkstelligen.
<nowiki># rndc reload meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T09:59:08Z

C9mos: /* Zonen manuell editieren */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN NS mail1.meinedomain.de.
IN NS mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Fehler in der Zonendatei und man muss sie erneut editieren. Ein häufiger Fehler ist das Auslassen eines ''NS''-Eintrags.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T09:54:37Z

C9mos: /* Erstellen einer Reverse Lookup Zone */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN NS mail1.meinedomain.de.
IN NS mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Syntaxfehler in der Zonendatei und man muss sie erneut editieren.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T09:50:18Z

C9mos: /* Zonen manuell editieren */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN NS mail1.meinedomain.de.
IN NS mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können. Beim Einfrieren werden auch die dynamischen Änderungen aus dem Zonen-Journal übernommen, was bewirkt, dass man eine aktuelle Zone bearbeitet.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>

Schlägt das Laden der Zone fehl, hat man einen Syntaxfehler in der Zonendatei und man muss sie erneut editieren.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T09:48:07Z

C9mos: /* Bearbeiten von Zonen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN NS mail1.meinedomain.de.
IN NS mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich manuell, mit <code>rndc</code> oder dynamisch, mit <code>nsupdate</code>, bearbeiten.
===== Zonen manuell editieren =====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone mit seinem bevorzugten Editor bearbeiten. Man sollte die Seriennummer der Zone mit erhöhen, damit es den sekundären DNS-Servern mitgeteilt wird, dass die Zone geändert worden ist.

<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>
Schlägt das Laden der Zone fehl, hat man einen Syntaxfehler in der Zonendatei und man muss sie erneut editieren.

===== Zonen mit ''nsupdate'' bearbeiten =====

FreeBSD als DNS-Server

2023-05-14T09:42:07Z

C9mos: /* Bearbeiten von Zonen */

== Domain Name Service ==
Der ''Domain Name Service'' übernimmt die Namensauflösung von Netzwerkadressen. So kann man im Netzwerk die einzelnen Rechner mit einem Namen ansprechen und anstelle mit nur IP-Adressen kommunizieren. So wird z. B. wiki.cmoser.org in die zugewiesene IP-Adresse umgewandelt.

Wenn man aber keinen DNS-Server selbst hostet, aber eine Namensauflösung will, kann man auf jeden Rechner die ''/etc/hosts'' (unter Windows die ''%WINDIR%\system32\drivers\etc\hosts'') editieren, um eine Namensauflösung zu ermöglichen. Wenn das Netzwerk aber über mehrere Rechner verfügt und man einen Computer hinzufügen will, wird es schnell aufwendig, die ''/etc/hosts'' auf jeden Rechner zu bearbeiten. Hier kommt dann ein DNS ins Spiel. Als DNS-Service nehme ich BIND.

Ich habe mir einst ein Raspberry PI gekauft und nehme es als DNS-Server her, weil es wenig Strom verbraucht und eigentlich recht günstig zu erwerben ist. [https://www.freebsd.org FreeBSD] nutze ich, weil es eigentlich mein bevorzugtes Unix ist. Die Rechenleistung des RPI reicht bei weiten aus um einige Services, darunter auch einen DNS und DHCP Server, zu betreiben.

Es wird davon ausgegangen, dass das FreeBSD-Basissetup bereits abgeschlossen ist und dem Rechner eine statische IP-Adresse, wie z. B. 192.168.1.254, zugewiesen wurde. '''Ein DNS-Server braucht unbedingt eine statische IP-Adresse!!!'''

=== Wie komme ich zu einer Domäne ===
Eine Domäne zu erfinden ist meistens keine gute Idee, da man sich hier möglicherweise von im Internet angebotenen Services ausschließt, wenn man eine Domäne überschreibt. Die Domain lässt sich bei einem Registrar registrieren. Bei den meisten Webhosting Angeboten ist eine eigene Domäne mit inkludiert. Wenn man keinen Webserver im Internet betreiben will, aber eine Domäne für seine Zwecke braucht, kann man sie auch einzeln registrieren. Eine Domäne kostet normalerweise keine 20 € im Jahr. Hier sind ein paar Links, wo man sich eine Domäne registrieren kann. Diese Registrare unterstützen auch PayPal.
* [https://ionos.de Ionos.de]
* [https://www.internic.at/de/ Internic.at]
* [https://domain.com Domain.com] - '''kein IPV6!'''

=== Aufbau einer Domäne ===
Eine Doamäne ist der Namensraum, in welchen sich weitere Hosts und Subdomänen befinden. Die Domäne wird von rechts nach links aufgelöst, beginnend mit der Toplevel Domain (z .B. 'de') und durch einen Punkt (".") getrennt. ''cmoser.org'' ist die Domäne ''cmoser'' in der Toplevel Domäne ''org''.

Die Domain wird in Zonen unterteilt. Jede Zone ist eine eigene Domain bzw. eigene Subdomain. Z. B. ''cmoser.org'' ist eine eigene Zone im Nameserver des DNS-Providers. Jede Zone enthält einen oder mehrere Einträge, wie die Mailserver der Domäne, die einzelnen Hosts mit Namen und IP-Adresse und die Adressen der einzelnen Nameserver der Domäne. Es gibt auch eine Reverse-Lookup Zone, die die umgekehrte Auflösung von IP-Adressen in den Host-Namen übernimmt. Sekundäre Zonen werden vom primären DNS-Server geholt und helfen bei der Namensauflösung, wenn der Primäre DNS-Server eine höhere Last aufweist und dienen nebenbei auch der Redundanz. Fällt der primäre DNS-Server aus, hat man, wenn man auch einen Sekundären Nameserver betreibt, etwas Zeit sich um den Primären DNS-Server wieder zum Laufen zu bringen, bis die Namensauflösung nicht mehr funktioniert.

Jede Zone wird in einer eigenen Datei gespeichert. Diese Dateien befinden sich unter FreeBSD normalerweise unter ''/usr/local/etc/namedb/primary'' für primäre Zonen, ''/usr/local/etc/namedb/secondary'' für Sekundärzonen und ''/usr/local/etc/namedb/dynamic'' für dynamische Zonen.

Dynamische Zonen sind praktisch, wenn man einen DHCP-Server hostet und gerne die Clients, welche IP-Adressen über den DHCP-Server beziehen (wie z. B. Laptops, Handys, Tablets usw.), mit einer Namensauflösung versehen will. Im Artikel ''[https://wiki.cmoser.org/index.php/FreeBSD_als_DHCP-Server FreeBSD als DHCP-Server]'' werde ich darauf näher eingehen.

==== Primäre Zonen ====
Eine primäre (Master) Zone enthält die originale Zonendatei. Die primären Zonen sind sowohl lesbar als auch schreibbar. Alle DNS-Einträge werden in die primäre Zone des DNS-Servers geschrieben. Die Daten werden in einer Textdatei gespeichert, was den Vorteil hat, dass sich einfach ein Backup erstellen lässt und sie sich, im Falle von Problemen, einfach wieder herstellen lässt.

Wenn man Änderungen an der DNS-Zone machen will, muss eine primäre Zone verfügbar sein. Ist der Server mit der primären Zone ausgefallen, kann man keine Änderungen an der Zone durchführen.

Wer Redundanz haben will, muss man die Zonendaten auf mehreren Servern zur Verfügung stellen.

'''LAN IP-Adressen haben in einer primären Zone, die im Internet zugänglich ist, nichts verloren. Diese sollten nur vom DNS-Server im LAN abgebildet werden.'''

==== Sekundäre Zonen ====
Eine sekundäre Zone ist eine nur lesbare Kopie der Zonendaten. Meistens sind sekundäre (Slave) Zonen Kopien von primären Zonen, aber sie können auch Kopien von anderen sekundären Zonen oder Active Directory Zonen sein. Der Hauptverwendungszweck einer sekundären Zone ist, sie als Backup zur Verfügung zu stellen. Wenn die primäre Zone ausfällt, kann man noch immer Antworten auf die Anfragen für die Zone von seiner Kopie erhalten.

== Installation und Konfiguration von BIND ==
Die für die Installation von BIND benötigten Pakete sind ''bind918'' und ''bind-tools''. Diese lassen sich einfach mit pkg installieren.
<nowiki>root@rpi# pkg install -y bind918 bind-tools</nowiki>

Um BIND bei jedem Systemstart automatisch zu starten, muss man ihn noch in der ''/etc/rc.conf'' aktivieren.Die Erstellung des ''rndc''-Schlüssels übernimmt das Service-Script automatisch.
Der Service heißt '''named'''.
<nowiki>root@rpi# sysrc named_enable=YES</nowiki>

Der Service muss noch gestartet werden, damit er aktiv ist und die ''rndc''-Schlüssel-Datei erzeugt wird.
<nowiki>root@rpi# service named start</nowiki>

=== Konfiguration ===
Haben wir eine eigene Domäne und wollen dynamische Updates, erstellen wir noch einen ''rndc''-Schlüssel.
<nowiki>root@rpi# rndc-confgen -a -c /usr/local/etc/namedb/meinedomain.de.key -k meinedomainde-key</nowiki>

Um den Schlüssel in der Konfiguration nutzen zu können müssen wir ihn in die Datei ''/usr/local/etc/namedb/named.conf'' importieren.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Als Nächstes geht es um die Konfiguration des Nameservers. Die Konfiguration von BIND befindet sich in der Datei ''/usr/local/etc/namedb/named.conf''. Diese Datei wird bearbeitet. Eine genaue Spezifikation der Datei finden wir in der [https://bind9.readthedocs.io/en/v9_18_8/reference.html BIND9 Referenz].

Als Erstes suchen wir den Eintrag '''listen-on''' in den '''options''' und fügen hier den ''localhost'' (127.0.0.1) und die statische IP-Adresse unseres Servers ein.
<nowiki>options {
...

listen-on { 127.0.0.1; 192.168.1.254; };

...
};</nowiki>

Wer ein IPv6 Netzwerk betreibt, gibt mit der Option '''listen-on-v6''' noch die IPv6 Adressen an, auf welche der Server hören soll. Der Wert '''any''' erlaubt das Abhören aller, dem Server zugewiesenen IPv6 Adressen.
<nowiki>options {
...

listen-on-v6 {
fe80::2;
};

...
};</nowiki>

Der nächste Eintrag in den '''options''' ist der des Forwarders. In den Eintrag '''forwarders''' tragen wir die IP-Adresse von jenen DNS-Servern ein, die die Namensabfragen für uns erledigen sollen, wenn kein passender Eintrag im eigenen DNS vorhanden ist. Ich wählte zwei freie unzensierte DNS-Server aus. Wer ein IPv6 Netzwerk betreibt, kann noch die IPv6 Adressen der gewählten Server mit eintragen. 
(5.9.164.112 => digitalcourage, 80.241.218.68 => dismail.de, 192.168.1.1 => der eigene Router bzw. der DNS-Server des Providers)
<nowiki>
options {
...

forwarders {
5.9.164.112;
80.241.218.68;
192.168.1.1;
};

...
};</nowiki>
Meine Quelle und weitere DNS-Server findet ihr auf [https://www.kuketz-blog.de/empfehlungsecke/#dns https://www.kuketz-blog.de/empfehlungsecke/#dns].

Danach erstellen wir die jeweiligen Zonen. Wenn wir binden die entsprechenden Schlüsseldateien noch nicht eigebunden haben, tun wir es hier.
<nowiki>...

include "/usr/local/etc/namedb/meinedomain.de.key";

...</nowiki>

Nach Hinzufügen oder Ändern von Einstellungen oder Zonen sollte der Nameserver neu gestartet werden.
<nowiki># service named restart</nowiki>

==== Primäre Zonen ====
Jetzt erstellen wir die Zone. Diese fügen wir am besten am Ende der Datei ein.
<nowiki>zone "meinedomain.de" {
type primary;
allow-update {
"meinedomainde-key";
};
file "/usr/local/etc/namedb/primary/meinedomain.de";
allow-transfer {
192.168.1.253; // IP Adressen der Sekundären Server,
// die die Zone kopieren dürfen, kommen hier hin.
};
};</nowiki>

Es fehlt nur noch die Reverse Lookup Zone. Die Der IP-Adressbereich wird hier in umgekehrter Reihenfolge angegeben. 
<nowiki>zone "1.168.192.in-addr.arpa" {
type primary;
allow-update {
key "meinedomainde-key";
};
file "/usr/local/etc/namedb/dynamic/1.168.192.in_addr.arpa";
allow-transfer {
192.168.1.253;
};
};</nowiki>

==== Sekundäre Zonen ====
In einer sekundären Zone wird eine andere Zone kopiert und deren Einträge zur Verfügung gestellt. Die Einträge in einer sekundären Zone sind nicht veränderbar, sie dienen aber der Redundanz. Eine sekundäre Zone sieht in der ''/usr/local/etc/namedb/named.conf'' wie folgt aus. 
<nowiki>zone "meinedomain.de" {
type secondary;
file "/usr/local/etc/namedb/secondary/meinedomain.de";
primaries {
192.168.1.254; // Die IP-Adressen der primären
// Nameserver kommen hier hin
};
};</nowiki>

=== Erstellen der Zonendatei ===
Jede Zone beginnt mit einem TTL-Eintrag (time to live) bzw. wenn kein TTL angegeben wird mit einem '''SOA''' (Start Of Authority) Eintrag.

Der TTL Eintrag gibt an, wie lange diese Einträge gültig sind und im Cache gehalten werden sollen. Ein Beispiel für einen TTL Eintrag, der 3 Tage gültig ist, sieht wie folgt aus: 
<nowiki>$TTL 3D</nowiki>

Der SOA sollte der erste Eintrag, bzw. der zweite Eintrag sein, wenn kein TTL angegeben ist, in der Datei sein. Er enthält den Domänennamen mit abschließenden "." (z. B. meinedomain.de.) oder "@" für die aktuelle Domäne, den Namen des primären DNS-Servers, den Namen des primären E-Mail-Servers, die Seriennummer der Zone und Angaben über die Lebensdauer der Zone.

Ein Beispiel SOA-Eintrag sieht wie folgt aus: 
<nowiki>@ IN SOA ns1.meinedomain.de. mail.meinedomian.de. (
1 ; Seriennummer
1H ; Aktualisieren
1H ; Erneut Versuchen
1W ; Laeuft ab
1H ) ; Negatives Caching</nowiki>

Um diesen Eintrag zu erstellen, habe ich ein kleines Shell-Script geschrieben, dass ein SOA-Template für eine Zonendatei erstellt. [https://www.cmoser.org/scripts/FreeBSD/mkzone mkzone]

==== Erstellen der Forward Lookup Zone ====
Mit Hilfe der Forward Lookup Zone erfolgt die Auflösung der Host-Namen in IP-Adressen. Eine solche Zonendatei enthält neben den einzelnen Adresseinträgen, Einträge über die DNS- und Mail-Server der Domäne. Der Eintrag Host-Name '@' beschreibt die Domäne selbst.

Ein Beispiel für einen DNS-Eintrag (NS record) - Es sollte hier keine IP-Adresse, sondern ein Host-Name verwendet werden. '''Mindestens ein NS-Eintrag muss in jeder Zone vorhanden sein, damit diese gültig ist!!''' Auch auf den Punkt am Ende des Host-Namens ist zu achten, da es ansonsten zu fehlerhaften Ergebnissen bei der Namensauflösung kommen kann.
<nowiki>@ IN NS ns1.meinedomain.de.</nowiki>

Mail-Server werden in einem MX record abgebildet. Es sollten auch hier keine IP-Adressen verwendet werden, sondern Hostnamen. Die Zahl gibt die Priorität des Mail-Servers an. Der Mail-Server muss sich nicht zwingend in der eigenen Domain befinden. Es kann auch der Mail-Server Hosting Providers sein.
<nowiki>@ IN MX 30 mail.meinedomain.de.</nowiki>

Dann sind da noch die Adresseinträge. Diese werden mit '''A''' für IPv4 bzw. '''AAAA''' für IPv6, gefolgt von der Adresse, angegeben.
<nowiki>ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::2</nowiki>

Es gibt auch noch den CNAME-Eintrag, der auf den Namen eines anderen Hosts verweist. Dieser Eintrag dient als ein Alias-Name für einen Host.
<nowiki>drucker IN CNAME printer.meinedoamin.de.</nowiki>

Eine komplette Zone könnte wie folgt aussehen:
<nowiki>$TTL 1H
@ IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
6 ; Serial
1H ; Refresh
1H ; Retry
1W ; Expire
1H ) ; Negative Caching TTL

@ IN NS ns1.meinedoamin.de.
@ IN NS ns2.meinedomain.de.

@ IN MX 10 mail1.meinedomain.de.
@ IN MX 20 mail2.meinedoamain.de.

@ IN A 192.168.1.1
@ IN AAAA fe80::f435:344f:fe7f:8992

; Nameserver
ns1 IN A 192.168.1.254
ns1 IN AAAA fe80::1
ns2 IN A 192.168.1.253
ns2 IN AAAA fe80::2

; Mailserver
mail1 IN A 192.168.1.251
mail1 IN AAAA fe80::f435:344f:fe7f:f345
mail2 IN A 192.168.1.250
mail2 IN AAAA fe80::f435:344f:fe6f:f456

; LAN
router IN A 192.168.1.1
router IN AAAA fe80::2

server1 IN A 192.168.1.241
server1 IN AAAA fe80::3

server2 IN A 192.168.1.240
server2 IN AAAA fe80::4

printer IN A 192.168.1.2
printer IN AAAA fe80::1234:5678:9abc:1

; Alias
drucker1 IN CNAME printer1.meinedomain.de.</nowiki>

==== Erstellen einer Reverse Lookup Zone ====
Eine Reverse Lookup Zone macht eine umgekehrte Auflösung. Sie gibt den Hostnamen, der einer IP-Adresse zugewiesen ist, zurück. Diese Zone beinhaltet einen SOA- und mindestens einen NS-Eintrag. Diese Zone wird durch das aufzulösende IP-Netzwerk in umgekehrter Reihenfolge im Namensraum ''in-addr.arpa'', im Falle von IPv4 bzw. ''ip6.arpa'' angegenben. Wie z.B: <code>1.168.192.in.addr.arpa</code> bzw. <code>0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa</code>, im IPv6 Netzwerk ''fe80:0:0:0:x:x:x:x''.

Die Auflösung erfolgt über Zeiger-Einträge (PTR records), wobei der Netzwerkanteil wegfällt, da er durch die Zone bereits bestimmt wird.

In der IPv4 Zone würde ein PTR-Eintrag wie folgt aussehen:
<nowiki>1 IN PTR router.meinedomain.de.</nowiki>

In der IPv6 Zone:
<nowiki>2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR router.meinedomain.de.</nowiki>

Eine vollständige IPv4 Zone:
<nowiki>$TTL 1H
1.168.192.in-addr.arpa IN SOA ns1.meinedomain.de. mail1.meinedomain.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; negative cache TTL

; nameserver
IN NS ns1.meinedomain.de.
IN NS ns2.meinedomain.de.
; mailserver
IN MX 30 mail1.meinedomain.de.
IN MX 40 mail2.meinedomain.de.

; Einträge
1 IN PTR router.meinedomain.de.
2 IN PTR printer1.meinedomain.de.
240 IN PTR server2.meinedomain.de.
241 IN PTR server1.meinedomain.de.
250 IN PTR mail2.meinedomain.de.
251 IN PTR mail1.meinedomain.de.
253 IN PTR ns2.meinedomain.de.
254 IN PTR ns1.meinedomain.de.</nowiki>

Eine komplette IPv6 Zone sieht wie folgt aus:
<nowiki>$TTL 1H
0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN SOA ns1.cmoser.org. mx00.ionos.de. (
1 ; serial
1H ; refresh
1H ; retry
1W ; expire
1H) ; minimum

; Nameserver
IN NS ns1.meinedomain.de
IN NS ns2.meinedomain.de

; Mailserver
IN NS mail1.meinedomain.de.
IN NS mail2.meinedomain.de

; PTR Einträge
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.meinedomain.de.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.meinedomain.de.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail1.meinedoamin.de.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail2.meinedomain.de.
f.f.a.0.5.4.7.f.0.0.c.b.f.a.0.0 IN PTR router.meinedomian.de.
0.d.e.f.3.5.f.a.b.c.f.f.a.1.3.2 IN PTR client1.meinedomain.de.</nowiki>

==== Bearbeiten von Zonen ====
Zonen lassen sich mit BIND auch ohne Server-Neustart bearbeiten. Dazu dient das Werkzeug <code>rndc</code>.
Zuerst muss man die Zone einfrieren, damit keine dynamischen Änderungen an der Domäne durchgeführt werden können.
<nowiki># rndc freeze meinedomain.de</nowiki>

Dann kann man die Zone bearbeiten mit seinen bevorzugten Editor bearbeiten.
<nowiki># vi /usr/local/etc/namedb/dynamic/meinedoain.de</nowiki>

Nach dem man die Zone nach seinen Anforderungen editiert hat, muss man die Zone wieder auftauen. Die Zone wird dann automatisch neu geladen.
<nowiki># rndc thaw meinedomain.de</nowiki>
Schlägt das Laden der Zone fehl, hat man einen Syntaxfehler in der Zonendatei und man muss sie erneut editieren.