207.2 Erstellen und Verwalten von DNS-Zonen Gewichtung 3
207.2 Erstellen und Verwalten von DNS-Zonen
Kandidaten sollten eine Zonendatei für eine Vorwärts- oder Rückwärtszone und Hints für Root-Level-Server erstellen können. Dieses Lernziel umfasst das Einstellen korrekter Werte für Records, das Hinzufügen von Hosts in Zonen und das Hinzufügen von Zonen zum DNS. Kandidaten sollten außerdem Zonen an einen anderen DNS-Server delegieren können.
Hauptwissensgebiete:
- BIND-9-Konfigurationsdateien, Begriffe und Hilfsprogramme
- Werkzeuge, um Informationen vom DNS-Server abzurufen
- Anordnung, Inhalt und Speicherort der BIND-Zonendateien
- Verschiedene Methoden, um einen neuen Rechnernamen in die Zonendateien aufzunehmen (auch Rückwärtszonen)
Dies ist eine auszugsweise Liste der verwendeten Dateien, Begriffe und Hilfsprogramme:
- /var/named/
- Syntax von Zonendateien
- Formate von Resource-Records
- named-checkzone
- named-compilezone
- masterfile-format
- dig
- nslookup
- host
Prüfen der Konfigurationsfiles mit named-checkconf
Das wichtigste zuerst. Ein Neustart oder Neuladen einer fehlerhaften Konfiguration kann den gesamten DNS-Server zum erliegen bringen. Deshalb immer vorher testen!
die gesamte Konfiguration testen:
dazu nimmt man das Kommando named-checkconf mit dem Paramter -z. Der zusätzlich alle eingebundenen Zonenfiles mit überprüft.
Siehe auch man named-checkconf
root@ubuntu:/etc/bind# named-checkconf -z && echo "===============>>>>>>>>>>>>> Die Konfiguration ist OK! <<<<<<<<<<<<<<<<<<================"
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
zone lpic2.test/IN: loaded serial 2019120801
zone 17.191.10.in-addr.arpa/IN: loaded serial 2018120801
zone 18.191.10.in-addr.arpa/IN: loaded serial 2018120801
===============>>>>>>>>>>>>> Die Konfiguration ist OK! <<<<<<<<<<<<<<<<<<================
Hier ist alles in Ordnung. Wie es mit einem Fehler aussieht, sieht man hier:
root@ubuntu:/etc/bind# named-checkconf -z && echo "===============>>>>>>>>>>>>> Die Konfiguration ist OK! <<<<<<<<<<<<<<<<<<================"
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
zone lpic2.test/IN: loaded serial 2019120801
zone 17.191.10.in-addr.arpa/IN: loaded serial 2018120801
dns_rdata_fromtext: /etc/bind/zones/db.18.191.10:7: near eol: unexpected end of input
zone 18.191.10.in-addr.arpa/IN: loading from master file /etc/bind/zones/db.18.191.10 failed: unexpected end of input
zone 18.191.10.in-addr.arpa/IN: not loaded due to errors.
_default/18.191.10.in-addr.arpa/IN: unexpected end of input
Wenn man sich nur für den Fehler interessiert, dann lenkt man den stdout nach /dev/null um, dann kommt nur stderr zur Anzeige:
named-checkconf -z > /dev/null
_default/18.191.10.in-addr.arpa/IN: unexpected end of input
Prüfen eines Zoenenfiles mit named-checkzone
Ein Zonefile ohne Fehler bringt die folgende Ausgabe:
root@ubuntu:/etc/bind# named-checkzone db.18.191.10 /etc/bind/zones/db.18.191.10
zone db.18.191.10/IN: loaded serial 2018120801
OK
Nun kommentiere ich mal die serial-number aus und teste noch mal. Die Datei sieht dann so aus:
root@ubuntu:/etc/bind# cat /etc/bind/zones/db.18.191.10
$TTL 300 ; time-to-live - 5 min
@ IN SOA ns1.lpic2.test. root.localhost. (
; 2018120801 ; Serial
604800 ; Refresh (every 7 days)
86400 ; Retry (every 24h)
2419200 ; Expire (after 28 days)
604800 ) ; TTL Negativ Cache (7 days)
IN NS ns1.lpic2.test.
9 IN PTR 18.test.
root@ubuntu:/etc/bind# named-checkzone db.18.191.10 /etc/bind/zones/db.18.191.10
dns_rdata_fromtext: /etc/bind/zones/db.18.191.10:7: near eol: unexpected end of input
zone db.18.191.10/IN: loading from master file /etc/bind/zones/db.18.191.10 failed: unexpected end of input
zone db.18.191.10/IN: not loaded due to errors.
Hier wird auf Zeile 7 hingewiesen, das ist die Zeile in der die Konfiguration des SOA-Records abgeschlossen wird. Also sollte man dort den Fehler suchen. Ein Fehler der mir
gerne passiert, ich erstelle keine Mail-Adresse des Zonen-Verantwortlichen. In diesem Beispiel ist das die Angabe root.localhost. , das wird dann zu der Email root@localhost
übersetzt.
Aufbau der Zonendatei
siehe https://de.wikipedia.org/wiki/Zonendatei
SOA Record
siehe https://de.wikipedia.org/wiki/SOA_Resource_Record
@ ist ein Platzhalter für den Zonennamen
<Name der Zone, meist @> <TTL in Sekunden: optional, wird meist weggelassen> <Zonetype: meist IN für Internet> SOA <Primary/Master für diese Zone, also der DNS-Master> <Email-Adresse des Zonenverantwortlichen>
Name der Zone TTL gibt in Sekunden an, wie lange dieser RR in einem Cache gültig sein darf IN Zonenklasse (meist IN für Internet) SOA Kürzel für Start Of Authority Primary Primary Master für diese Zone: er definiert, an wen dynamische Updates gesendet werden sollen (siehe: Dynamisches Update) er gibt an, an wen keine Notifies gesendet werden (siehe: Zonentransfer) Mail-Adresse des Verantwortlichen für diese Zone. (Das @ wird durch . ersetzt. Punkte vor dem @ werden durch . ersetzt; beispielsweise max.mustermann.wikipedia.org für die E-Mail-Adresse max.mustermann@wikipedia.org) Seriennummer wird bei jeder Änderung inkrementiert (vorzugsweise JJJJMMTTVV; dient als Hinweis, wann die Zone zuletzt aktualisiert wurde[1]) Refresh Sekundenabstand, in dem sekundäre Nameserver die Seriennummer vom primären Master abfragen sollen, um Änderungen der Zone festzustellen.[2] Empfehlung vom RIPE NCC für kleine und stabile Zonen: 86400 ≙ 24 Stunden.[1] Retry Sekundenabstand, in dem, bei ausbleibender Antwort des Masters, sekundäre Nameserver nochmals seine Seriennummer abfragen sollen. Dieser Wert muss kleiner als jener zum Refresh sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 7200 ≙ 2 Stunden.[1] Expire Sekundenabstand, nach dem bei ausbleibender Antwort des Masters sekundäre Nameserver keine Antworten über die Zone mehr geben sollen. Dieser Wert muss größer als die Summe jener zum Refresh und Retry sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600000 ≙ 1000 Stunden.[1] Minimum Time to Live für Negatives Caching (Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600 ≙ 1 Stunde[1]). Ursprünglich hatte dieses Feld die Bedeutung eines Minimum-TTL-Werts für alle Resource Records der Zone[3] und wurde in der Praxis als Standardwert verwendet, wenn bei einem Resource Record kein TTL-Wert angegeben war; diese Bedeutung wurde mit RFC 2308 abgeschafft.[4]
Weitere Record-Typen
Ein seltener aber wichtiger Typ der nich direkt als Typ so deklariert wird, ist der GLU-Record. Der GLU-Record verweisst auf eine IP-Adresse. Seine spezielle Bezeichnung bekommt er daher, dass dieser A bzw. AAAA Record die IP-Adresse des Nameservers enthält, auf die sein eigenes Zonefile verweisst.
Aus [stackoverflow][https://serverfault.com/questions/309622/what-is-a-glue-record] habe ich folgende Beschreibung, in’s deutsche übersetzt.
- Ein GLU-Record ist ein Begriff für einen Datensatz, der von einem DNS-Server bereitgestellt wird, der nicht für die Zone autorisiert ist, um die Bedingung unmöglicher Abhängigkeiten für eine DNS-Zone zu vermeiden.
- Angenommen, ich besitze eine DNS-Zone für example.com. Ich möchte DNS-Server haben, die die autorisierende Zone für diese Domain hosten, damit ich sie tatsächlich verwenden kann - Hinzufügen von Einträgen für den Stamm der Domain, www, E-Mail usw. . Also habe ich die Nameserver in der Registrierung an die ich sie delegiere - das sind immer Namen, also geben wir ns1.example.com und ns2.example.com ein.
- Da ist der Trick. Die Server der TLD werden an die DNS-Server im whois-Datensatz delegiert - sie befinden sich jedoch innerhalb von example.com. Sie versuchen, ns1.example.com zu finden, fragen die .com-Server und werden zurück zu … ns1.example.com verwiesen.
- Glue Records ermöglichen es den Servern der TLD, zusätzliche Informationen in ihrer Antwort auf die Abfrage für die Zone example.com zu senden, um die IP-Adresse zu senden, die auch für die Nameserver konfiguriert ist. Es ist nicht autorisierend, aber es ist ein Zeiger auf die autorisierenden Server, sodass die Schleife aufgelöst werden kann.
Wie sieht ein GLU-Record aus?
Erstellen einer privaten Zone
folgender Link hat mir bei der Einrichtung geholfen: http://www.technik-tipps-und-tricks.de/raspberry-pi/raspberry-pi-projekte/lokaler-dns-server-mit-bind/
Zum Testen erstelle ich eine Zone die nur von meinem DNS-Server aufgelöst wird. Das heißt, die Clients, die meine Zone auflösen wollen, müssen diesen DNS-Server eingetragen haben.
-
- Zonen-File anlegen für Forward-Resolution
root@ubuntu:/etc/bind# cat /etc/bind/zones/lpic2.test
$TTL 300
@ IN SOA ns1.lpic2.test. root.localhost (; mail-Adresse root@localhost
2019120801 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS ns1.lpic2.test.
ns1 IN A 10.191.17.9
@ IN A 10.191.17.9
www IN A 10.191.17.9
-
- Zonen-File anlegen für Backward-Resolution:
root@ubuntu:/etc/bind# cat /etc/bind/zones/db.17.191.10
$TTL 300 ; time-to-live - 5 min
@ IN SOA ns1.lpic2.test. root.localhost. (
2018120801 ; Serial
604800 ; Refresh (every 7 days)
86400 ; Retry (every 24h)
2419200 ; Expire (after 28 days)
604800 ) ; TTL Negativ Cache (7 days)
IN NS ns1.lpic2.test.
9 IN PTR lpic2.test.
-
- neue Zonen-Files in einer Konfigdatei einbinden und dem DNS-Server über
type master;mitteilen, dass er der Master der Zonen ist:
- neue Zonen-Files in einer Konfigdatei einbinden und dem DNS-Server über
root@ubuntu:/etc/bind# cat ./named.conf.master-zones
zone "lpic2.test" {
type master;
file "/etc/bind/zones/lpic2.test";
};
zone "17.191.10.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.17.191.10";
};
-
- die Konfigdatei in die Hauptkonfiguration einbinden, falls noch nicht geschehen:
root@ubuntu:/etc/bind# tail -1 ./named.conf
include "/etc/bind/named.conf.master-zones";
-
- TESTEN
vorwärtz:
root@ubuntu:/etc/bind# dig @127.0.0.1 +noall +answer lpic2.test
lpic2.test. 300 IN A 10.191.17.9
und rückwärtz:
root@ubuntu:/etc/bind# dig @127.0.0.1 +noall +answer -x 10.191.17.9
9.17.191.10.in-addr.arpa. 300 IN PTR lpic2.test.