DNS & BIND

1 Training Notes

2 Folien

3 Passwort Laptop

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

4 Aufgabe 1 (ca. 15 Minuten)

  • 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

4.1 ein paar Übungen

  • bei den folgenden Übungen die dig Ausgabe studieren
    • welche Flags sind gesetzt?
    • welche Informationen sind in welchen Sektionen?
    • ist die Antwort authoritativ?
    • gibt es EDNS0?
    • gibt es Informationen in der Additional-Sektion?
  • eine IPv4-Adresse abfragen
dig www.linuxhotel.de a
  • eine IPv6-Adresse abfragen
dig www.linuxhote.de aaaa
  • gibt es eine IPv4 und IPv6 Adresse für linuxhotel.de (ohne www)?
  • gibt es den Domain-Namen ftp.linuxhotel.de?
  • wonach wird gefragt, wenn nur der Befehl dig ohne Parameter ausgeführt wird
  • was sehen wir in der Antwort der Anfrage. Ist das eine Antwort? Ist diese Antwort authoritativ?
dig @a.nic.de www.linuxhotel.de a
  • wird die folgende Antwort über UDP empfangen?
dig @9.9.9.9 larger.dnssec.works txt +dnssec
  • in welcher Reihenfolge müssen bei dig die Parameter angegeben werden (ausprobieren)?
dig linuxhotel.de soa +multi
dig +multi soa linuxhotel.de
dig soa +multi linuxhotel.de
dig linuxhotel.de +multi soa
  • gibt es eine Additional Section bei der Antwort nach
dig strotmann.de mx
  • gibt es eine Additional Section bei der Antwort nach
dig strotmann.de mx ns3.myinfrastructure.org
  • gibt es eine Additional Section bei der Antwort nach
dig strotmann.de mx ns5.myinfrastructure.org

5 Aufgabe 2 - BIND 9 aus den Quellen installieren

5.1 IP-Adressen

  • Virtuelle Maschinen (Container)
    Ute 192.168.53.101
    Jan 192.168.53.102
    Carsten 192.168.53.103
    DNS-Resolver 192.168.53.253
    DNS-Authoritative 192.168.53.252

5.2 Passwort virtuelle Maschinen

  • Benutzername: nutzer
  • Passwort: dnslab
  • Root-Passwort: dnslab (via su -)

5.3 Verbindung zu den virtuellen Maschinen

ssh nutzer@192.168.53.10X

5.4 BIND 9 übersetzen

  • Der Quellcode von BIND 9 kann von http://ftp.isc.org/isc/bind9/ geladen werden. Auf den Servern in der Lab-Umgebung befindet sich der Quellcode von BIND 9.12.3-P1 schon im Verzeichnis /usr/src. BIND 9 Quellcode auspacken
su -
cd /usr/src
tar xvfz bind-9.12.3-P1.tar.gz
  • BIND 9 Quellcode konfigurieren. Die Konfigurationsdateien sollen in unserer Test-Installation im Verzeichnis /etc/namedb liegen
cd bind-9.12.2
./configure --sysconfdir=/etc/namedb
make
make install
cd ~
  • die Versionsnummer des installieren BIND 9 prüfen
named -V

6 Unser (Beispiel) Netzwerk

network.png

7 Aufgabe 3: Schreibe einen SOA-Record

  • 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

7.1 Mögliche Lösung

zoneXX.dnslab.org.   3600 IN SOA   serverXX.zoneXX.dnslab.org. (
                                   ; E-Mail des Admins hostmaster@zoneXX.dnslab.org
                                   hostmaster.zoneXX.dnslab.org.
                                   1001 ; SOA-Serial Nummer
                                   2h   ; Refresh
                                   15m  ; Retry
                                   5w   ; Expire
                                   2h ) ; negTTL

8 Aufgabe: Schreibe die NS-Records

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

8.1 Lösung

zoneXX.dnslab.org.  3600 IN NS serverXX.zoneXX.dnslab.org.
zoneXX.dnslab.org.  3600 IN NS gateway.zoneXX.dnslab.org.

8.2 Zonendatei prüfen

named-checkzone zoneXX.dnslab.org /etc/namedb/zoneXX.dnslab.org

9 Warum DNS Round-Robin Last-Verteilung nicht mehr funktioniert

10 Aufgabe: A Records schreiben

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

10.1 Mögliche Lösung

serverXX.zoneXX.dnslab.org.   3600 IN  A    192.168.1.20
beta.zoneXX.dnslab.org.       3600 IN  A    192.168.1.1
delta.zoneXX.dnslab.org.      3600 IN  A    192.168.1.25
gateway.zoneXX.dnslab.org.    3600 IN  A    192.168.1.100
gateway.zoneXX.dnslab.org.    3600 IN  A    10.0.10.100
whiskey.zoneXX.dnslab.org.    3600 IN  A    10.0.10.200
zulu.zoneXX.dnslab.org.       3600 IN  A    10.0.10.210

11 Aufgabe: MX-Records schreiben

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

11.1 mögliche Lösung

zoneXX.dnslab.org. 3600 IN MX 10 delta.zoneXX.dnslab.org.
zoneXX.dnslab.org. 3600 IN MX 20 gateway.zoneXX.dnslab.org.

12 eine Reverse-Zone für das Beispiel-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

12.1 Lösung Zonendateien für Reverse-Auflösung

  • Zone 53.168.192.in-addr.arpa
53.168.192.in-addr.arpa.   IN SOA serverXX.zoneXX.dnslab.org. hostmaster.zoneXX.dnslab.org. (
                                    1000 2h 15m 51d 1h )
53.168.192.in-addr.arpa.    IN NS  serverXX.zoneXX.dnslab.org.
53.168.192.in-addr.arpa.    IN NS  gateway.zoneXX.dnslab.org.

10X.53.168.192.in-addr.arpa. IN PTR serverXX.zoneXX.dnslab.org.
1.53.168.192.in-addr.arpa.   IN PTR beta.zoneXX.dnslab.org.
25.53.168.192.in-addr.arpa.  IN PTR delta.zoneXX.dnslab.org.
100.53.168.192.in-addr.arpa. IN PTR gateway.zoneXX.dnslab.org.
  • Zone 10.0.10.in-addr.arpa
10.0.10.in-addr.arpa.    IN SOA serverXX.zoneXX.dnslab.org. hostmaster.zoneXX.dnslab.org. (
                                    1000 2h 15m 51d 1h )
10.0.10.in-addr.arpa.    IN NS  serverXX.zoneXX.dnslab.org.
10.0.10.in-addr.arpa.    IN NS  gateway.zoneXX.dnslab.org.

200.10.0.10.in-addr.arpa. IN PTR whiskey.zoneXX.dnslab.org.
210.10.0.10.in-addr.arpa. IN PTR zulu.zoneXX.dnslab.org.
100.10.0.10.in-addr.arpa. IN PTR gateway.zoneXX.dnslab.org.

13 Aufgabe: Zonendatei verkleinern

  • 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

13.1 Beispiel-Lösung (234 Zeichen)

$TTL 30
@ SOA serverXX . 1 1h 5m 5w 1h
 NS serverXX
 NS gateway
 MX 1 delta
 MX 2 gateway
serverXX A 192.168.1.20
beta A 192.168.1.1
delta A 192.168.1.25
gateway A 192.168.1.100
 A 10.0.10.100
whiskey A 10.0.10.200
zulu A 10.0.10.210

14 Lokale DNS-Resolver Konfiguration anpassen

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

15 Aufgabe: BIND 9 Konfigurtionsdatei schreiben

  • 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

16 eine Slave-Zone einrichten

  • 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

17 Pretty-Print für Zonedaten

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

18 Aufgabe 'RNDC' für BIND 9 einrichten

  • 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

19 wichtige RNDC Befehle

  • 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>

20 Aufgabe: BIND 9 Logging

  • 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

21 Aufgabe: Query-Logging

  • 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

22 Root-Hints für den DNS Resolver im BIND 9 einrichten

  • 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

23 Aufgabe: DNS Zone an die Lab-Umgebung anpassen

  • 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

24 DNS/DNSSEC Monitoring Skripte

25 Aufgabe: Notify Logging

  • 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

26 Zone ändern, prüfen das der Zonentransfer funktioniert

  • 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

27 Aufgabe: Zonen-Delegation - Zone delegieren

  • 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

28 Aufgabe: Zonen-Delegation: Delegation empfangen

  • 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

29 Lösung BIND Konfiguration "named.conf"

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

30 Lösung Zonendatei

$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.

31 Aufgabe: Dynamische Zone

  • 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

31.1 Wichtig:

  • eine dynamische Zone darf niemals mit einem Editor editiert und geschrieben werden!
  • der BIND DNS-Server wird die Zone nicht mehr laden und weitere dynamische Updates werden abgewiesen
  • Wer dennoch nicht auf das Editieren von DNS-Zonen verzichten möchte: https://dotat.at/prog/nsdiff/

32 Aufgabe: dynamisches DNS per TSIG absichern

  • 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

33 Logging für dynamische Updates

  • 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.

33.1 Lösung

logging {
  [...]
  channel update_log { file "update.log" versions 10 size 10M; };
  [...]
  category update           { update_log; };
  category update-security  { update_log; };
};

34 Aufgabe: Zonentransfer beschränken

  • 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

35 BIND 9 Statistiken

  • in der named.conf den Statistik-Kanal anschalten
statistics-channels {
        inet * port 8053 allow { 192.168.53.0/24; };
};

36 Aufgabe: eine DNS-Resolver Konfiguration

  • 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

37 Aufgabe: eine Forward-Zone

  • 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

38 Aufgabe: eine Stub-Zone

  • 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

39 Men & Mice Certification Programm

40 DNSSEC Zone signieren

40.1 DNSSEC Schlüssel erstellen

  • ein neues/leeres Verzeichnis für die DNSSEC-Schlüssel erstellen
mkdir /etc/namedb/keys
  • den ZSK-Schlüssel für die Zone zoneXX.dnslab.org erstellen
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -K /etc/namedb/keys \
  zoneXX.dnslab.org
  • den KSK-Schlüssel für die Zone zoneXX.dnslab.org erstellen (grösserer Schlüssel und KSK-Flag)
dnssec-keygen -a RSASHA256 -b 2560 -f KSK -n ZONE -K /etc/namedb/keys \
  zoneXX.dnslab.org
  • Schlüssel ID-Nummern notieren (5-stellige Nummer)
  • Rechte auf den Schlüsseldateien anpassen
chown named /etc/namedb/keys/*
  • die DNS-Zone für DNSSEC vorbereiten. In der named.conf:
options {
[...]
  key-directory "keys";
};

zone "zoneXX.dnslab.org" {
  type master;
  file "zoneXX.dnslab.org";
  auto-dnssec maintain;
  inline-signing yes;
};

  • BIND 9 Konfiguration speichern, prüfen und BIND 9 neu laden
  • Zone signieren
rndc sign zoneXX.dnslab.org
  • Testen, das die Zone signiert ist. Es muss ein RRSIG Record unter der Antwort erscheinen
dig @localhost zoneXX.dnslab.org SOA +dnssec
  • DS-Record für die Eltern-Zone erstellen
dnssec-dsfromkey -2 /etc/namedb/keys/KzoneXX.dnslab.org+008+<ID-des-KSK>.key
  • DS-Record an den Betreiber des Elternzone übermitteln (machen wir hier im Kurs heute nicht)

41 DNSSEC Resolver

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