[[Vorlage(Getestet, jammy)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:IP-Adresse_wechseln:] [:Editor: Einen Editor öffnen] [:mit Root-Rechten arbeiten:] [:dig: Abfragen von Informationen von DNS-Servern] }}} [[Inhaltsverzeichnis(2)]] BIND, auch bekannt als "named" (Kurzform für: "Berkeley Internet Name Daemon"), ist ein von der Universität Berkeley (USA) entwickelter [wikipedia:BIND:DNS-Server], der eine hohe Verbreitung in mittleren bis großen Netzen findet. Er ist als [wikipedia:Open_Source:Open Source] erhältlich und wurde auf fast jedes Betriebssystem portiert. Bis heute gilt BIND als "die Referenz" unter den DNS-Servern und bildet den Grundstock des heutigen Internets. Inzwischen wurde die Entwicklung des BIND-Servers vom herstellerunabhängigen [https://www.isc.org Internet Systems Consortium (ISC)] {en} übernommen. Dieser Artikel behandelt die Version 9 der Software. Als alternativer DNS-Server für kleinere (Heim-)Netze steht auch [:Dnsmasq:] zur Verfügung, der besonders einfach konfiguriert werden kann, jedoch lange nicht den Funktionsumfang von BIND bietet. {{{#!vorlage Hinweis Ein DNS-Server, der von anderen Rechner angesprochen wird, __muss__ eine statische IP-Adresse haben [3], damit er von den Clients gefunden werden kann. Er kann logischerweise __nicht__ per Domainnamen angesprochen werden, da er für die Auflösung solcher angesprochen wird und daher die IP bekannt sein muss. Ein rein lokaler DNS-Server, der nur auf dem gleichen Rechner erreicht werden muss, benötigt keine spezielle IP-Konfiguration. }}} {{{#!vorlage Hinweis Standardmäßig läuft auf dem System der Dienst [:systemd/systemd-resolved:systemd-resolved], welcher auf 127.0.0.53 lauscht. Diesen sollte man abschalten, wenn man BIND installieren möchte. }}} = Installation = Folgendes Paket ist zu installieren [1]: {{{#!vorlage Paketinstallation bind9 }}} BIND ist nach der Installation bereits voll funktionsfähig und läuft im Cache-Mode, d.h. er bezieht DNS-Informationen von den Root-Servern und gibt sie an die Clients weiter. = Erstkonfiguration = Die Konfiguration des BIND-Servers erfolgt über das Verzeichnis '''/etc/bind'''. Nach der Installation sollten sich hier folgende Dateien finden: {{{ db.0 db.local named.conf named.conf.default-zones db.127 db.empty named.conf.local rndc.key db.255 named.conf.options zones.rfc1918 }}} In den Dateien, die mit '''named.''' beginnen, wird die allgemeine Funktion des Servers konfiguriert. Die '''db.'''-Dateien sind dagegen die Zonendateien, in denen die eigentlichen DNS-Daten abgelegt werden. In älteren Ubuntu-Versionen gab es noch die Datei '''db.root''' mit der Liste der Rootserver. Diese befindet sich nun in '''/usr/share/dns/root.hints'''. {{{#!vorlage Hinweis Wichtig ist hierbei die __genaue__ __Einhaltung__ der Syntax, da BIND hier __extrem__ __pingelig__ ist. }}} == Betriebsmodi == Ein DNS-Server kann ebenso mehrere Rollen einnehmen, welche in folgender Tabelle erläutert werden. BIND kann z.B. gleichzeitig für bestimmte Zonen autoritativ sein und gleichzeitig für das eigene Netz einen Resolver bereitstellen. {{{#!vorlage Tabelle Resolver/Recursor DNS-Server, der auf rekursive Anfragen antwortet und die Informationen dazu hierarchisch von der root-Zone beginnend abfragt. Er kann die Antworten zwischenspeichern, um Anfragen schneller zu beantworten zu können und Traffic zu vermeiden. +++ Forwarder/stub-Resolver DNS-Server, der auf rekursive Anfragen antwortet, diese jedoch einfach an einen Resolver weiterleitet und die Antworten zwischenspeichert (Cache). +++ autoritativer Server DNS-Server, der Zonendateien mit Records enthält, die von anderen Resolvern abgefragt werden. }}} == Einstellungen in named.conf.options == Die Datei '''/etc/bind/named.conf.options''' muss mit Root-Rechten[5] editiert[4] werden. === Vertrauenswürdige Clients festlegen === Man erstellt __vor__ dem options-Block einen neuen Block `acl `: {{{ acl goodclients { // Name kann frei gewählt werden 192.168.0.0/24; // Lokales Netz (IP-Adressbereich anpassen) 10.0.10.45; // einzelner Client im Netz 2001:db8::/32; //IPv6-Netz localhost; // localhost sollte immer eingetragen sein, da es der Rechner ist, auf dem BIND lauscht localnets; //Netze, auf denen BIND lauscht, bei 10.0.0.5/24 würden alle Rechner aus 10.0.0.0/24 zugelassen sein }; }}} Danach muss im options-Block diese ACL (Access Control List) aktiviert werden: {{{ options { directory "/var/cache/bind"; allow-recursion { goodclients; }; //ACL-Name von oben, erlaubt das rekursive Abfragen von Zonen, für die BIND nicht autoritativ ist allow-query { any; }; //Erlaubt die generelle Abfrage von autoritativen Zonen, bei einem autoritativen DNS-Server `any` verwenden, da von jeder IP-Adresse zugegriffen werden muss! ... }; }}} === Netzwerkschnittstellen === Ein für eine öffentliche Zone autoritativer Server muss über eine öffentliche IPv6- und IPv4-Adresse erreichbar sein. Ein reiner Resolver für das interne Netz kann ausschließlich auf einer site-local-IPv6-Adresse (z.B. ULA) und einer privaten IPv4-Adresse lauschen. Zur Änderung der Netzwerkschnittstellen muss man in einem Editor mit Root-Rechten [5] die Datei '''named.conf.options''' bearbeiten und die folgende Zeile in den ''options''-Block eintragen: {{{ listen-on-v6 { ::1; 2001:db8::1234;}; listen-on { 127.0.0.1; 192.168.0.10; 10.0.20.25; }; }}} Die Beispieladressen müssen natürlich an die IP-Adressen des Bind-Servers im lokalen Netzwerk angepasst werden. Wichtig ist auch, den `localhost`, also `127.0.0.1` und `::1`, nicht zu vergessen, sowie auf die korrekte Verwendung der Semikolons zu achten. Ist kein listen-on definiert, so wird auf allen Schnittstellen gelauscht. === Forwarder-Mode festlegen (optional) === Will man DNS-Abfragen nicht an die Root-Server stellen, kann man Bind im Forwarder-Mode konfigurieren. So leitet er Anfragen an andere DNS-Server (z.B. vom ISP) weiter. Im options'-Block wird dazu ein neuer forwarders-Block angelegt. Hier können auch mehrere Server eingetragen werden: {{{ forwarders { 10.0.0.1; 2001:db8::1234; }; }}} Jetzt kann der Server wie folgt neu gestartet werden: {{{#!vorlage Befehl sudo service named restart }}} Testen kann man dies mit dem Befehl dig[6]: {{{#!vorlage Befehl dig ubuntuusers.de @::1 }}} == Das Anlegen der Zonendateien == Im DNS gibt es 2 Arten von Zonen, einmal Forwarding-Zonen, die für Domainnamen wie `example.org` zuständig sind und Reverse-Zonen, welche für die Auflösung von IP-Adressen in Domainnamen zuständig sind (z.B. 1.0.0.2.ip6.arpa.). Eine Datei mit dem Namen '''db.''example.org''''' ist für die Forwardlookup-Zone und eine Datei namens '''db.''z.y.x''''' für die Reverselookup-Zone zuständig. === Forward Lookup === Die Datei '''db.example.org''' könnte so aussehen: {{{ ;; db.example.org ;; Forwardlookupzone für example.org ;; $TTL 2D @ IN SOA rechnername.example.org. mail.example.org. ( 2006032201 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 3H ) ; NX (TTL Negativ Cache) @ IN NS rechnername.example.org. IN MX 10 mailserver.example.org. IN A 192.168.0.10 IN AAAA 2001:db8::1 rechnername IN A 192.168.0.10 rechner1 IN A 192.168.0.200 mailserver IN A 192.168.0.201 rechner2 IN CNAME mailserver }}} ## Eintrag für localhost ist korrekt, bitte drin lassen. Ressourcen von MX-Records (in diesem Beispiel also der "mailserver") müssen immer auf einen AAAA- oder A-Record verweisen (RFC 2181), CNAME ist nicht erlaubt. Besonders wichtig an dieser Stelle ist eine Leerzeile am Ende der Datei! Das `TTL` (Time To Live) gibt an, wie lange Informationen im Cache der Clients gültig bleiben und danach neu angefordert werden sollen (in diesem Fall `2D`ays, also 2 Tage). Als nächstes kommt dann der `SOA` (Start Of Authority resource records), welcher folgende Werte für den Bereich der Domäne festlegt: * `zone-origin` ist der vollqualifizierte Domainname (`FQDN`) des primären DNS-Servers. (In diesem Fall ''server.example.org.'', der Name des Servers, den gerade konfigurieren wird.) Der Punkt am Ende ist übrigens wichtig! * `zone-contact` ist die Mail-Adresse des DNS-Verwalters. Das "@" wird hier jedoch durch einen Punkt ersetzt, somit müsste hier "mail.example.org." eingetragen werden. Auch hier den Punkt am Ende nicht vergessen! * `serial` ist eine Seriennummer, die der Administrator nach seinen Vorstellungen vergeben kann. Allerdings muss die Seriennummer bei jeder Änderung erhöht werden, da diese Nummer sekundären DNS-Servern als Indiz dafür dient, dass sich was geändert hat. Nach allgemeiner Konvention benutzt man deswegen die Form YYYYMMDDSS, mit YYYY=Jahr, MM=Monat, DD=Tag und SS=zweistellige Seriennummer, die bei mehreren Änderungen an einem Tag jeweils um eins erhöht wird. * Die folgenden Einträge des SOA-Abschnitts befinden sich für die meisten Fälle schon auf vernünftigen Voreinstellungen und müssen im Allgemeinen nicht angetastet werden. {{{#!vorlage Experten * `refresh` gibt die Zeit in Sekunden an, die ein sekundärer Server wartet, bis er beim primären Server nachfragt, ob sich die Zonendateien verändert haben. * `retry` gibt die Zeit in Sekunden an, die ein sekundärer Server wartet, bis er eine Anfrage an den primären Server wiederholt, wenn dieser auf die vorherige Anfrage nicht geantwortet haben sollte (z.B. weil er offline war). * `expire` gibt die Zeit in Sekunden an, die ein sekundärer Server auf einen erfolgreichen Kontakt zum primären Server wartet, bevor er die Zonendatei für ungültig erklärt. * `nx` gibt die Zeit an, während der eine negativ beschiedene DNS Anfrage ("Name Error" / "NXDOMAIN") zwischengespeichert werden soll (zwischen 0 Sekunden und 3 Stunden). }}} Als nächstes kommen die Einträge der DNS-Server, die für die Zone verantwortlich sind. Diese haben alle die Form {{{ Name IN RR Wert }}} Der Name kann dabei weggelassen werden, in welchem Fall er aus der vorherigen Zeile übernommen wird. Namen ohne Punkt am Ende werden dabei durch den Zonen-(Domain-)namen ergänzt, Namen mit Punkt gelten als vollqualifiziert. Ein besonderer Name ist das Zeichen '''@''', das dem Zonennamen entspricht. RR (Resource Record) muss einer von mehreren offiziellen RR-Bezeichnungen sein und der Wert hängt von der Art des RR ab. Einige RRs: || RR || Wert || Beschreibung || || NS || FQDN eines DNS-Servers || alle primären und sekundären DNS-Server der Domain sollten einen Eintrag besitzen || || A || IP-Adresse || "normaler" Eintrag: Name -> IP || || CNAME || richtiger Name || Alias-Definition - richtiger Name muss kein FQDN sein, sollte aber kein weiterer CNAME sein || || MX || Priorität Name || Mailserver, der Mail für die Domain annimmt - Priorität muss eine Zahl sein (niedriger: zuerst probieren), Name ist der Name des Mailservers || || PTR || FQDN || umgekehrte Auflösung: IP -> Name || Weitere Resource Records finden sich in [wikipedia:Resource_Record:Wikipedia] oder in der Fachliteratur. === Reverse Lookup === In der Datei '''db.z.y.x''', bspw. '''db.0.168.192''' für das Subnetz 192.168.0.0, befinden sich überwiegend die Einträge aus der '''db.example.org''', allerdings erfolgt der Lookup nun in umgekehrter Richtung: {{{ ;; db.0.168.192 ;; Reverselookupzone für 192.168.0.0/24 ;; $TTL 2D @ IN SOA rechnername.example.org. mail.example.org. ( 2006032201 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 3H ) ; TTL Negative Cache @ IN NS rechnername.example.org. 10 IN PTR rechnername.example.org. 200 IN PTR rechner1.example.org. 201 IN PTR rechner2.example.org. }}} Man beachte die PTR-Records, die für die Rückwärtsübersetzung von IP-Adressen in Namen zuständig sind. Die Zahlen in der ersten Spalte stellen dabei das letzte Byte der IP-Adresse dar. Wichtig ist, dass die übersetzten Namen FQDNs (mit Punkt am Ende) sind. Alias-Einträge, MX-Records, etc. werden hier nicht nochmal aufgeführt. Die Datei '''db.8.b.d.0.1.0.0.2.ip6.arpa''' dient für den IPv6-Reverse-Lookup. {{{ ;; Reverse-Lookup für 2001:db8::/32 $TTL 2D @ IN SOA rechnername.example.org. mail.example.org. ( 2006032201 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 3H ) ; TTL Negative Cache @ IN NS rechnername.example.org. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR rechnername.example.org. }}} == Globale Konfiguration in named.conf.local == Nun müssen die Zonendateien dem Server noch bekannt gemacht werden. Dies geschieht durch folgenden Eintrag in der Datei '''named.conf.local''', die in der eigentlichen '''named.conf'''-Datei referenziert wird: {{{ zone "example.org" { type master; file "/etc/bind/db.example.org"; }; zone "0.168.192.in-addr.arpa" { type master; file "/etc/bind/db.0.168.192"; }; zone "8.b.d.0.1.0.0.2.ip6.arpa" { //Reverse-Zone für 2001:db8::/32 type master; file "/etc/bind/db.8.b.d.0.1.0.0.2.ip6.arpa"; }; }}} `.in-addr.arpa` ist die offizielle "Domain für IPv4-Adressen". Diese sind pro Byte in Subdomains aufgeteilt. `0.168.192.in-addr.arpa` ist also die Subdomain für alle Adressen von 192.168.0.0 bis 192.168.0.255. Beim IPv6-Reverse-Lookup wird die Adresse zeichenweise durch einen Punkt getrennt (aus `2001:db::3` wird `3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.ip6.arpa.`). Die übergeordnete Zone ist `.ip6.arpa.`. Diese Bezeichnung aus der ''zone''-Direktive ist auch gleichzeitig das, was in den Zonendateien als '''@''' referenziert werden kann. Die Option `master` sagt dem Server, dass er der für die Domain verantwortliche Server ist, also der ''primäre Server'' und das `file` verweist lediglich noch auf die Zonendateien. = Starten des DNS und testen der Funktion = Nun kann man den Server mal probeweise starten: {{{#!vorlage Befehl sudo service named start }}} Wenn keine Fehlermeldungen in der Datei '''/var/log/syslog''' auftauchen, kann der Server mit dem Werkzeug [:dig:] getestet werden: {{{#!vorlage Befehl dig @127.0.0.1 rechnername.example.org }}} Als Antwort sollte dann so etwas kommen: {{{ ; <<>> DiG 9.3.2 <<>> rechnername.example.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54891 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;rechnername.example.org. IN A ;; ANSWER SECTION: rechnername.example.org. 172800 IN A 192.168.0.10 ;; AUTHORITY SECTION: example.org. 172800 IN NS rechnername.example.org. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Mar 25 04:34:52 2006 ;; MSG SIZE rcvd: 92 }}} = Benutzung = Wenn bis hierhin alles geklappt hat, muss man nur noch allen Client-Rechnern im Netz den neuen Nameserver bekannt machen, angefangen beim Server-Rechner selber. Wie das unter Ubuntu geht steht im Artikel [:DNS-Konfiguration:]. Auf den Clients können unterschiedliche Methoden notwendig sein. Am einfachsten funktioniert das, wenn man einen [:ISC-DHCPD: DHCP-Server] einsetzt. Dann braucht man die DNS-Einstellungen nur dort verändern. Ansonsten auf jedem Client einzeln. Natürlich muss man dafür dann die richtige IP-Adresse des Servers verwenden und nicht die 127.0.0.1. Für IPv6 kann neben DHCPv6 noch das IPv6-Router-Advertisement eingesetzt werden. = Problembehebung = Mit diesem Befehl werden die Statusinformationen und die letzten Logmeldungen angezeigt: {{{#!vorlage Befehl sudo service bind9 status }}} Bind hat keine eigene Logdatei, sondern schreibt alle Meldungen unter dem alten Namen 'named' in das Syslog (/var/log/syslog). = Links = * [:DNS-Server_Bind/Sekundäre_Nameserver:Sekundäre Nameserver] - Nameserver spiegeln, um die Ausfallsicherheit zu erhöhen * [https://ctaas.de/bind9.htm ctaas.de/bind9] {de} - Howto: bind9 DNS caching & forwarding Server, einschließlich logging & eigener Zonen (Einstieg). ## * [:Baustelle/Bind_mit_LDAP_Backend:] - Bind mit OpenLDAP-Backend betreiben # tag: Server, Netzwerk, dns