DNS & BIND

• Notizen und Anleitungen https://notes.defaultroutes.de

• DNS & BIND

• Benutzername: nutzerXX (siehe Aufkleber)
• Passwort: villa
• Root-Passwort: vogelsang

• das Ethernet-Kabel am Laptop ziehen (werden wir später verwenden) und den Laptop starten
• mit dem WLAN linuxhotel verbinden (kein Passwort)
• den Befehl dig nachinstallieren

sudo apt install dnsutils

• arbeite auf den virtuellen Maschinen
• erstelle eine Zonendatei mit einem SOA-Record mit einem Editor (nano, emacs, vim …) Deiner Wahl. Die Datei sollte im Verzeichnis /etc/namedb liegen

cd /etc/namedb
nano zoneXX.dnslab.org

• schreibe einen SOA-Record für das Netzwerk in dem Netzwerkplan (oben). XX durch die eigene Teilnehmernummer ersetzen.

  Ute	01
  Jan	02
  Carsten	03

• nach 10 Minuten wird hier eine Musterlösung erscheinen

• füge die NS-Records für das Beispiel-Netzwerk der Zonendatei hinzu

• DNS Round Robin and Destination IP address selection https://blogs.technet.microsoft.com/networking/2009/04/17/dns-round-robin-and-destination-ip-address-selection/

• Schreibe 7 A-Records für das Beispielnetzwerk
• die neue Zonendatei mit named-checkzone testen

• erstelle die 2 MX-Records für das Lab-Netzwerk

• wir schreiben eine Reverse-Zone für das Beispielnetzwerk
• das Reverse-Zone wird in zwei neue Dateien geschrieben /etc/namedb/53.168.192.in-addr.arpa.db und /etc/namedb/10.0.10.in-addr.arpa.db
• Jede Zonendatei sollte beeinhalten
  • 1x SOA (genau Nachdenken - was kommt in den SOA Record?)
  • 2x NS-Record für das Beispielnetzwerk (welche Nameserver sind authoritativ für die Daten?)
  • je einen Eintrag für jede IP-Adresse des Netzwerkes (4 für 192.168.53.0/24 und 3 für 10.0.10.0/24)
• die Zonendateien testen mit dem Befehl named-checkzone <zonen-name> <datei-name>

named-checkzone 53.168.192.in-addr.arpa  53.168.192.in-addr.arpa.db
named-checkzone 10.0.10.in-addr.arpa  10.0.10.in-addr.arpa.db

• Benutze die Shortcuts, um die Zonendatei zu verkleinern, Ziel: unter 300 Zeichen Grösse der Datei anzeigen
• Grösse der Zonendatei ausgeben

wc -c <datei-der-zone>

• Ausgangs-Zonendatei

zoneXX.dnslab.org.     30 IN SOA    serverXX.zoneXX.dnslab.org. ( 
                                        . 2 3600 300 3024000 3600 )
zoneXX.dnslab.org.     30 IN NS serverXX.zoneXX.dnslab.org.
zoneXX.dnslab.org.     30 IN NS gateway.zoneXX.dnslab.org.
zoneXX.dnslab.org.     30 IN MX 1 delta.zoneXX.dnslab.org.
zoneXX.dnslab.org.     30 IN MX 2 gateway.zoneXX.dnslab.org.
serverXX.zoneXX.dnslab.org.   30 IN A  192.168.53.1XX
beta.zoneXX.dnslab.org.    30 IN A  192.168.1.1
delta.zoneXX.dnslab.org.   30 IN A  192.168.1.25
gateway.zoneXX.dnslab.org. 30 IN A  192.168.1.100
gateway.zoneXX.dnslab.org. 30 IN A  10.0.10.100
whiskey.zoneXX.dnslab.org. 30 IN A  10.0.10.200
zulu.zoneXX.dnslab.org.    30 IN A  10.0.10.210

echo "nameserver 192.168.53.253" > /etc/resolv.conf

• Kopiere die eigene Zonendatei nach /etc/namedb/
• Erstelle die BIND 9 Konfigurationsdatei /etc/namedb/named.conf

options {
  directory "/etc/namedb";
};

zone "zoneXX.dnslab.org" {
  type master;
  file "zoneXX.dnslab.org"; # Dateiname der Zonendatei
};

• BIND 9 Konfigurationsdatei prüfen

named-checkconf -z /etc/namedb/named.conf

• Benutzer für den BIND 9 Server Prozess anlegen (Debian spezifisch)

adduser --system --home /var/named --disabled-password named

• BIND 9 Konfigurationsverzeichnis dem Benutzer named zuweisen

chown named /etc/namedb

• BIND 9 im Vordergrund starten (zur Fehlersuche/Überprüfung des BIND 9 Startvorgangs). BIND 9 beenden mit CTRL+C

named -u named -g -c /etc/namedb/named.conf

• BIND 9 im Hintergrund starten

named -u named -c /etc/namedb/named.conf

• Unser Server ist nun ein Resolver und auch authoritativ für die Zone zoneXX.dnslab.org.
• lokaler Test

dig @localhost zoneXX.dnslab.org soa

• der DNS Resolver Teil des BIND 9 funktioniert hier in der Lab-Umgebung noch nicht, da die Root-Hints noch nicht stimmen. Bei einem Server im Internet würde die Resolver-Funktion nun schon funktionieren.
• Beispiel Anfragen via dem DNS-Resolver an den eigenen Server

dig serverXX.zoneXX.dnslab.org aaaa 
dig serverXX.zoneXX.dnslab.org a
dig zoneXX.dnslab.org any
dig zulu.zoneXX.dnslab.org

• wir wollen die Zone des Nachbarn als Slave-Zone auf unserem DNS-Server hosten
• dazu schreiben wir eine Zonen Definition in die named.conf Datei

[...]
zone "zoneYY.dnslab.org" {
 type slave;
 file "zoneYY.dnslab.org.slave";
 masters { 192.168.53.1YY; };
};

• BIND 9 Konfiguration testen

named-checkconf -z

• BIND 9 neu laden

pkill -HUP named

• wurde die Slave-Zonen-Datei erstellt?

ls -l /etc/namedb/zoneXX.dnslab.org.slave

• ist unser eigener DNS-Server nun authoritativ für die Zone (AA-Flag in der Antwort?)

dig @localhost zone09.dnslab.org soa

• Zonedatei der Slave-Zone anschauen (Aua, geht nicht mehr)

less /etc/namedb/zoneXX.dnslab.org.slave

• seit BIND 9.8 speichert BIND 9 die Datei für eine Slave-Zone in einem Binär-Format ab. Dieses Format lässt sich nicht ohne weiteres lesen.
• wir können BIND 9 sagen, die Dateien im Text-Format anzulegen (wie in BIND 9 < 9.8)

zone "zoneXX.dnslab.org" {
 type slave;
 file "zoneXX.dnslab.org.slave";
 masters { 192.168.53.1XX; };
 masterfile-format text;
};

• Konfiguration testen und BIND 9 neu laden

named-checkconf -z
pkill -HUP named

• Zonedatei der Slave-Zone anschauen (sollte nun gehen)

less /etc/namedb/zoneXX.dnslab.org.slave

• mit dem Befehl named-checkzone -D kann eine Zonendatei normalisiert werden (alle Abkürzungen werden aufgelöst)

named-checkzone -D <zonen-name> <datei-name>

• kryptografischen Schlüssel für die lokale rndc Anmeldung erstellen (schreibt die Datei /etc/namedb/rndc.key)

rndc-confgen -a
ls -l /etc/namedb/rndc.key
chown named /etc/namedb/rndc.key

• BIND 9 zum letzten Mal per pkill neu laden. BIND 9 liest die Datei rndc.key, wenn diese existiert, und erlaubt rndc Verbindungen auf Port 953

pkill -HUP named

• nun kann rndc benutzt werden. Hier wird der aktuelle Status des laufenden BIND 9 Servers abgefragt

rndc status

• BIND stoppen

rndc stop

• BIND Konfiguration und alle neuen und geänderten Zonen neu laden

rndc reload

• nur die BIND Konfiguration (named.conf) und neue Zonendateien laden

rndc reconfig

• Status einer Zone anzeigen

rndc zonestatus <zonename>

• eine geänderte Zone neu laden

rndc reload <zonename>

• eine Slave-Zone neu per Zonentransfer übertragen, wenn die Seriennummer auf dem Master höher ist

rndc refresh <zonename>

• eine Slave-Zone sofort und immer per Zonentransfer übertragen, auch wenn die Seriennummer gleich oder kleiner ist

rndc retransfer <zonename>

• von einer Masterzone notify DNS Meldungen an alle Slave-Server senden

rndc notify <zonename>

• Logging-Konfiguration in die Datei named.conf hinzufügen

logging {
  channel transfer_log {
     file "transfer.log" versions 10 size 10M;
     severity info;
     print-time yes;
     print-severity yes;
     print-category yes;
  };

  category xfer-in { transfer_log; };
  category xfer-out { transfer_log; };
};

• Datei sichern, prüfen und BIND 9 neu laden (nach Änderungen an der Logging Konfiguration muss bei älteren BIND 9 Versionen der DNS-Server neu gestartet werden, damit die Log-Dateien neu angelegt werden können)

named-checkconf -z
rndc reload

• Prüfen, das die Log-Datei angelegt wurde

ls -l /etc/namedb/

• einen Zonentransfer der eigenen Zone mit dig durchführen

dig @localhost zoneXX.dnslab.org axfr

• der Zonentransfer sollte einen Eintrag in der Log-Datei erzeugt haben

• Einen Channel für Query-Logging hinzufügen, Zieldatei ist /etc/namedb/queries.log. Die Kategorie queries in diesen Channel lenken

[...]
  channel queries_log {
     file "queries.log" versions 10 size 10M;
     severity info; print-time yes; 
  };
  category queries { queries_log; };
[...]

• BIND 9 Konfiguration neu laden

rndc reconfig

• Query-Logging anschalten

rndc querylog on

• eine DNS-Anfrage stellen

dig @localhost zoneXX.dnslab.org SOA

• die Query-Logging-Datei anschauen

less /etc/namedb/queries.log

• unser BIND 9 Server kennt die Root-Server im Lab-Netzwerk nicht. Wir müssen diese per Root-Hints Datei bereitstellen.
• die Root-Hints Datei ist eine vereinfachte Zonendatei mit den Namen und den IP-Adressen der Root-Nameserver

dig @192.168.53.252 ns . > /etc/namedb/root.hints

• Die Root-Hints Datei in der Datei /etc/namedb/named.conf eintragen

zone "." {
  type hint;
  file "root.hints";
};

• Konfiguration prüfen

named-checkconf -z 

• BIND 9 Server neu laden

rndc reload

• Test: nun sollte über unseren BIND 9 Server auch die Namen der anderen Teilnehmer auflösbar sein

dig @localhost zoneYY.dnslab.org soa

• Derzeit sind stellen unsere Zonen nicht die wirkliche DNS-Konfiguration dar. Z.B. ist unser zweiter DNS-Server "gateway", aber die Slave-Zone ist auf dem Server unseres Nachbarn im Kurs gehostet
• die TTL für alle Records der Zone im Lab auf 60 Sekunden setzen, so das wir im weiteren im Kurs nicht lange warten müssen, wenn falsche Daten im Cache landen
• Wir haben derzeit zwei authoritativen DNS-Server pro Zone: serverXX.dnslab.org (XX = eigene Teilnehmernummer) und serverYY.dnslab.org (YY = Nummer des Teilnehmers der die Slave-Zone hostet) .

zoneXX.dnslab.org. IN SOA serverXX.dnslab.org. ....
zoneXX.dnslab.org. IN NS  serverXX.dnslab.org.
zoneXX.dnslab.org. IN NS  serverYY.dnslab.org.

• Seriennummer im SOA-Record hochzählen
• Datei speichern und Konfiguration prüfen

named-checkconf -z

• Änderungen in der Zone in den BIND 9 laden (per RNDC)

rndc reload zoneXX.dnslab.org

• Änderungen prüfen (lokale Abfrage, Antwort ist authoritativ)

dig @localhost ns zoneXX.dnslab.org

• Änderungen prüfen über den Referenz-Resolver (192.168.53.253), Antwort ist nicht authoritativ (indirekt über einen DNS-Resolver Cache)

dig @192.168.53.253 ns zoneXX.dnslab.org

• prüfen ob alle authoritative DNS-Server der Zone die gleiche SOA-Seriennummer haben

dig zoneXX.dnslab.org +nssearch

• eine Sammlung einfacher Monitoring-Skripte https://github.com/menandmice-services/dns-monitoring-scripts

• im Logging-Block in der Datei named.conf

category notify { transfer_log; };

• speichern, prüfen und Konfiguration neu laden
• Notifies für eigene Zone manuell senden

rndc notify zoneXX.dnslab.org

• In der Transfer-Logdatei schauen, ob Notifies gesendet und ob Notifies empfangen wurden

• füge einen TXT-Record mit einem beliebigen Text-Inhalt der eigenen Zone hinzu

text.zoneXX.dnslab.org.  30 IN TXT "Hallo Linuxhotel"

• SOA-Serial hochzählen
• Konfiguration prüfen und BIND 9 neu laden

named-checkconf -z
rndc reload zoneXX.dnslab.org

• prüfen das alle DNS-Server der Zone nun die neue SOA-Serial Nummer haben

dig zoneXX.dnslab.org +nssearch

• TXT-Record über den Resolver anfragen

dig text.zoneXX.dnslab.org. txt

• Eine Subzone der eigenen Zone soll auf den Server server03.dnslab.org delegiert werden. Diese Zone wird von einem anderen Administrator verwaltet.
• Die zu delegierende Zone hat den Namen delegated.zoneXX.dnslab.org
• vor der Delegation einer Zone prüfen, ob der Ziel-Server der Delegation schon authoritativ für die zu delegierende Zone ist (AA-Flag), um eine lame delegation zu vermeiden

dig @server03.dnslab.org delegated.zoneXX.dnslab.org soa

• Den Delegations-NS-Record in die eigene Zone einfügen, SOA-Serial hochzählen

delegated.zoneXX.dnslab.org. IN NS server03.dnslab.org.

• Speichern, Konfiguration testen, BIND 9 neu laden. Prüfen das die neuen Zoneninformationen auch auf dem Slave-Server sind (alle Server müssen die gleiche SOA-Seriennummer haben):

dig zoneXX.dnslab.org +nssearch

• Auflösung eines Eintrages der neuen Zone über einen DNS-Resolver testen (A-Record in der „Answer“ Sektion)

dig delegated.zoneXX.dnslab.org a

• Euer DNS-Server empfängt eine Delegation aus der Zone zone03.dnslab.org. Diese delegiert Zone hat den Namen delegatedXX.zone03.dnslab.org.
• Erstelle eine neue Zone auf dem eigenen DNS-Server (1x SOA, 1x NS, 1x A, 1x TXT Record, 1x SRV-Record für den Dienst rndc auf Port 953/TCP)
• Erstelle eine Zonenkonfiguration in der Datei named.conf für eine Masterzone, welche die neue Zonendatei lädt
• Konfiguration prüfen, BIND 9 neu laden testen, das der eigene Server authoritativ für die neue Zone ist

dig @localhost delegatedXX.zone03.dnslab.org soa

• den Trainer informieren, das nun die Delegation eingerichtet werden kann
• Delegation testen, den TXT Record und den SRV Record aus der neuen eigenen Zone über den Referenz-Resolver abfragen

dig @192.168.53.253 <name-des-TXT-RR>.delegatedXX.zone03.dnslab.org. TXT
dig @192.168.53.253 _rndc._tcp.delegatedXX.zone03.dnslab.org. SRV

zone "delegatedXX.zone03.dnslab.org" {
  type master;
  file "delegatedXX.zone03.dnslab.org";
};

$ORIGIN delegatedXX.zone03.dnslab.org.
$TTl 3600
@     IN SOA serverXX.dnslab.org. hostmaster.dnslab.org. 1 2h 15m 4w 30
      IN NS  serverXX.dnslab.org.

www   IN A   1.2.3.4
text  IN TXT "Hallo, dies ist ein Text-Record"

_rndc._tcp   IN SRV 0 0 953 serverXX.dnslab.org.

• wir machen die Zone delegatedXX.zone03.dnslab.org dynamisch
• in der named.conf in der Zonendefinition für delegatedXX.zone03.dnslab.org eintragen

zone "delegatedXX.zone03.dnslab.org" {
[...]
   allow-update { 192.168.53.0/24; };
};

• BIND 9 Konfiguration speicher, prüfen, neu laden
• per nsudpate einen neuen Record hinzufügen

nsupdate
> add dyn.delegatedXX.zone03.dnslab.org. 30 IN TXT "dynamischer Record"
> send
> quit

• Record abfragen

dig dyn.delegatedXX.zone03.dnslab.org. TXT

• Journal anschauen

named-journalprint /etc/namedb/delegatedXX.zone03.dnslab.org.jnl

• die Änderungen der Zone wieder auf die Platte schreiben (oder 15 Minuten warten)

rndc sync

• die neu-geschriebene Zonendatei anschauen

less /etc/namedb/delegatedXX.zone03.dnslab.org

• Record wieder löschen

nsupdate
> del dyn.delegatedXX.zone03.dnslab.org TXT
> send
> answer 
> quit

• einen TSIG-Schlüssel erstellen

tsig-keygen

• den Schlüssel in der named.conf eintragen (am Anfang der Datei)

key ddns-tsig-key {
  algorithm hmac-sha256;
  secret "<base-64-key>";
};

• den gleichen Inhalt auch in eine separate Datei /root/ddns-tsig.key schreiben. Der Name des Schlüssels muss in beiden Dateien (named.conf und ddns-tsig.key gleich sein)

key ddns-tsig-key {
  algorithm hmac-sha256;
  secret "<base-64-key>";
};

• Update nur für den DDNS-TSIG Schlüssel erlauben

zone "delegatedXX.zone09.dnslab.org" {
[...]
   allow-update { key ddns-tsig-key; };
};

• BIND 9 Konfiguration speichern, prüfen, BIND 9 neu laden
• nsupdate mit TSIG Schlüssel testen

nsupdate -k /root/ddns-tsig.key
> ttl 30
> add testrec.delegatedXX.zone09.dnslab.org. A 1.2.3.4
> show
> send
> answer
> quit

• nsupdate ohne TSIG Schlüssel testen (sollte nicht funktionieren)

nsupdate
> ttl 30
> add testrec2.delegatedXX.zone09.dnslab.org. A 1.2.3.4
> show
> send

• erweitere die BIND 9 Log-Konfiguration, so das die Kategories update und update-security in eine Datei mit dem Dateinamen update.log geschrieben werden
• Änderungen in der Zone mit nsupdate testen, einmal mit, einmal ohne TSIG-Schlüssel. Die neuen Log-Einträge in der Datei anschauen.

• In der Datei named.conf in der eigenen Master-Zonen Konfiguration fügen wir eine neue Zeile hinzu. Diese Zeile erlaubt Zonentransfer nur noch von der angegebenen IP-Adresse. Alle anderen IP-Adressen sind damit nicht mehr erlaubt:

zone "zoneXX.dnslab.org" {
  [...]
  allow-transfer { 192.168.53.1ZZ; };
};

• Datei speichern, prüfen und den BIND 9 neu laden

named-checkconf -z
rndc reload

• Die SOA-Serialnummer in der eigenen Zone hochzählen (um zu Testen, das der Zonentransfer zum Slave-Server noch funktioniert), Zonendatei speichern, prüfen und BIND 9 neu laden
• Prüfen, das der Slave-Server die Zone mit der neuen SOA-Seriennummer bekommen hat

dig zoneXX.dnslab.org +nssearch
tail /etc/namedb/transfer.log

• Prüfen, das der Zonentransfer von der lokalen Loopback Adresse nicht mehr erlaubt ist

dig @localhost zoneXX.dnslab.org axfr

• in der named.conf den Statistik-Kanal anschalten

statistics-channels {
        inet * port 8053 allow { 192.168.53.0/24; };
};

• Konfiguration prüfen, BIND 9 neu laden, mit dem Browser auf http://192.168.53.1XX:8053 gehen

• eine Sicherheitskopie der Datei /etc/namedb/named.conf erstellen
• die named.conf neu schreiben, so das eine reine DNS-Resolver Konfiguration entsteht (ohne Zonen-Blöcke)

options {
  directory "/etc/namedb";
  allow-recursion { 192.168.53.0/24; localhost; };
};

zone "." {
   type hint;
   file "root.hints";
};

• Datei sichern, prüfen, BIND 9 neu laden
• nun ist unser Server ein DNS-Resolver (DNS-Cache)
• wir stellen die lokale Linux-DNS Konfiguration so ein, das nun der eigene DNS-Server als DNS-Resolver benutzt wird

echo "nameserver 127.0.0.1" > /etc/resolv.conf

• Test: die folgenden DNS-Anfragen sollten positive Antworten zurückgeben

dig serverXX.dnslab.org
dig www.isc.org
dig SOA dnslab.org

• Test: die Zone internal.dnslab.org ist nicht direkt über die rekursive Namensauflösung erreichbar (RCODE: NXDOMAIN). Man sagt „die Zone ist nicht delegiert“. Es gibt keine NS-Record Einträge für die Zone in der Eltern-Zone dnslab.org. Daher kann die Zone nicht über die normale DNS rekursive Auflösung gefunden werden:

dig internal.dnslab.org a

• Aufgabe: erstelle eine Forward-Zone in der named.conf für die Zone internal.dnslab.org
• die Zone ist auf dem Server 192.168.53.103 als authoritative Zone verfügbar

zone "internal.dnslab.org" {
  type forward;
  forwarders { 192.168.53.103; };
};

• BIND 9 Konfiguration speichern, prüfen und BIND 9 neu laden

named-checkconf -z
rndc reconfig

• Test: die Zone internal.dnslab.org ist nun über den eigenen DNS-Resolver erreichbar (RCODE: NOERROR mit Antwort)

dig internal.dnslab.org a

• Test: die Zone lab.dnslab.org ist nicht direkt über die rekursive Namensauflösung erreichbar (RCODE: NXDOMAIN)

dig lab.dnslab.org a

• erstelle eine Stub-Zone in der named.conf für die Zone lab.dnslab.org
• die Zone ist auf dem Server 192.168.53.103 authoritative

zone "lab.dnslab.org" {
  type stub;
  masters { 192.168.53.103; };
  file "lab.dnslab.org.stub";
};

• BIND 9 Konfiguration speichern, prüfen und BIND 9 neu laden

named-checkconf -z
rndc reconfig

• Test: die Zone lab.dnslab.org ist nun über den eigenen DNS-Resolver erreichbar (RCODE: NOERROR mit Antwort)

dig lab.dnslab.org a

• Zonendatei anschauen

less /etc/namedb/lab.dnslab.org.stub

• https://www.menandmice.com/training/training-certification-program/
• E-Mail an <training@menandmice.com>

options {
  [...]
  dnssec-validation auto;
};