Skip to main content

DNS-Auftrag

Aufgabenstellung

Einrichtung des Labors:

  • Ein Debian Linux-Server wird konfiguriert, um als DNS-Server zu dienen, wobei BIND (Berkeley Internet Name Domain) als Softwarelösung zum Einsatz kommt.

Konfiguration des DNS-Servers:

  • Installation von BIND: Der BIND-DNS-Server wird auf dem Debian Linux-System installiert.
  • Einrichtung der Zonen-Dateien: Konfiguration und Einrichtung der primären DNS-Zone für eine Domäne. Dabei wird besonderer Wert auf die Erstellung und Konfiguration der Zonendatei gelegt, einschließlich aller relevanten DNS-Einträge und des SOA (Start of Authority) Records.
  • Konfiguration eines sekundären DNS-Servers: Einrichtung eines sekundären (Slave) DNS-Servers für Redundanz und zur Demonstration der automatisierten Zonensynchronisation.

Analyse und erweiterte Konfiguration:

  • Analyse der DNS-Anfragen: Verwendung von Wireshark zur Aufzeichnung und Analyse der DNS-Anfragen. Dies umfasst das Verständnis der rekursiven Anfragen und der Antwortpakete.
  • Erforschung verschiedener DNS-Record-Typen: Untersuchung und Erläuterung unterschiedlicher Arten von DNS-Einträgen (wie A, AAAA, MX, CNAME, TXT) und deren Anwendung.
  • Dynamische DNS-Updates: Experimentieren mit dynamischen Updates von DNS-Einträgen. Nutzung von tsig-keygen zur Generierung sicherer Schlüssel für die Authentifizierung von Update-Anfragen.
  • Integration in bestehende Netzwerkumgebungen: Einbeziehung des konfigurierten DNS-Servers in ein bestehendes Netzwerk, eventuell unter Nutzung von exotischen Betriebssystemen, um deren Kompatibilität und Funktionalität in Bezug auf DNS-Anfragen zu testen.
  • Erforschung von DNS unter IPv6: Untersuchung der Besonderheiten und Konfigurationen von DNS in IPv6-Netzwerken, einschließlich Reverse-DNS.

image.png

DNS-Auftrag.excalidraw

Theorie

DNS Einträge

A (Address Record)

  • Verwendung: Verknüpft einen Domainnamen mit der IP-Adresse eines Servers.
  • Beispiel: example.com A 192.0.2.1
  • Seit: Das A-Record ist einer der ursprünglichen DNS-Einträge, eingeführt mit dem Start des DNS-Systems 1983.

AAAA (IPv6 Address Record)

  • Verwendung: Ähnlich wie das A-Record, aber für IPv6-Adressen.
  • Beispiel: example.com AAAA 2001:0db8::1
  • Seit: Eingeführt Anfang der 1990er Jahre als Teil der Einführung von IPv6.

PTR (Pointer Record)

  • Verwendung: Wird für Reverse DNS (rDNS) Lookups verwendet, um eine IP-Adresse in den zugehörigen Hostnamen zu übersetzen.
  • Beispiel: 1.2.0.192.in-addr.arpa PTR example.com
  • Seit: Seit den Anfängen von DNS, 1983.

TXT (Text Record)

  • Verwendung: Ermöglicht es einem Administrator, beliebigen Text in einem DNS-Eintrag zu speichern.
  • Beispiel: example.com TXT "v=spf1 include:_spf.google.com ~all"
  • Seit: Eingeführt in den 1990er Jahren.

MX (Mail Exchange Record)

  • Verwendung: Definiert die Mailserver, die für den Empfang von E-Mails für eine Domain zuständig sind.
  • Beispiel: example.com MX 10 mail.example.com
  • Seit: Seit den Anfängen von DNS, 1983.

SRV (Service Record)

  • Verwendung: Spezifiziert den Standort der Server für bestimmte Dienste.
  • Beispiel: _sip._tcp.example.com SRV 10 5 5060 sipserver.example.com
  • Seit: Eingeführt in den späten 1990ern.

SPF (Sender Policy Framework)

  • Verwendung: Hilft dabei, E-Mail-Spoofing zu verhindern, indem festgelegt wird, welche Mailserver E-Mails für eine Domain senden dürfen.
  • Beispiel: example.com TXT "v=spf1 ip4:192.0.2.0/24 -all"
  • Seit: Eingeführt 2004, aber 2014 offiziell als veraltet erklärt und durch DMARC ersetzt.

NAPTR (Naming Authority Pointer)

  • Verwendung: Wird verwendet in Verbindung mit SIP und ENUM zum Routing von Telefonanrufen über das Internet.
  • Beispiel: 2.0.2.4.1.2.9.e164.arpa NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:number@example.com!" .
  • Seit: Eingeführt in den späten 1990er Jahren.

CAA (Certificate Authority Authorization)

  • Verwendung: Gibt an, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen.
  • Beispiel: example.com CAA 0 issue "letsencrypt.org"
  • Seit: Eingeführt 2013.

NS (Name Server Record)

  • Verwendung: Gibt die Nameserver an, die für eine bestimmte Domain zuständig sind.
  • Beispiel: example.com NS ns1.example.com
  • Seit: Seit den Anfängen von DNS, 1983.

DS (Delegation Signer)

  • Verwendung: Wird im DNSSEC-Protokoll verwendet, um die Authentizität der Nameserver-Informationen einer Domain zu bestätigen.
  • Beispiel: example.com DS 12345 5 1 49FD46E6C4B45C55D4AC69DB588D2B9411AEDB4F
  • Seit: Eingeführt mit DNSSEC in den 2000er Jahren.

Hauptunterschiede und Änderungen bei DNS über IPv6

  1. IPv6-Adressen:

    • IPv6-Adressen sind länger und komplexer als IPv4-Adressen. Sie bestehen aus 128 Bit und werden in hexadezimaler Notation dargestellt, z. B. 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

  2. AAAA-Records:

    • Für IPv6-Adressen wird der AAAA-Record (Quad-A-Record) anstelle des A-Records verwendet, um eine Hostadresse zu speichern. Ein AAAA-Record kann eine IPv6-Adresse zu einem Domainnamen auflösen.
    • Beispiel:
      www.example.com. 3600 IN AAAA 2001:0db8:85a3::8a2e:0370:7334

       

  3. Reverse DNS:
  • Reverse DNS-Lookups für IPv6-Adressen verwenden PTR-Records, die in der ip6.arpa.-Domain gespeichert werden.
  • Ein Beispiel für eine PTR-Zeile für IPv6 sieht folgendermaßen aus:
    4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.3.a.5.8.b.0.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR www.example

Aufbau der Umgebung

Konfiguration des DNS Servers (Master)

Schritt 1: Installation von BIND

Paketdatenbank aktualisieren:
sudo apt-get update
BIND Installieren:

Alle nötigen Bind9 Packete installieren

sudo apt-get install bind9 bind9utils bind9-doc dnsutils

Schritt 2: Konfiguration von BIND

Edit the named.conf.options file:

Im named.conf.options file stehen allgemeine Konfigurationen drin wie zum beispiel, welches Subnetz abfragen machen darf oder zu welchem DNS die restlichen DNS Abfragen forgewarded werden sollen.

sudo nano /etc/bind/named.conf.options
acl LAN {
192.168.1.0/26;
};
options {
        directory "/var/cache/bind"; // default directory
        allow-query { localhost; LAN; }; // allow queries from localhost and 192.168.1.0-192.168.1.255
        forwarders { 1.1.1.1; }; // use CloudFlare 1.1.1.1 DNS as a forwarder
        recursion yes;  // allow recursive queries
};

Mit named-checkconf kann man alle bind9 Dateien auf Syntax errors kontrollieren.

named-checkconf /etc/bind/named.conf.options

image.png

Edit the named.conf.local file

Im named.conf.local file stehen die Einstellungen für die einzelnen Zonen.

sudo nano /etc/bind/named.conf.local
zone "test.local" {
    type master;
    file "/etc/bind/zones/db.test.local"; # Pfad zur Zonendatei
    allow-transfer { 192.168.1.5; }; # IP des sekundären DNS-Servers
};
zone "1.168.192.in-addr.arpa" IN {
     type master;
     file "/etc/bind/zones/db.test.local.rev"; # Pfad zur Zonendatei
     allow-transfer { 192.168.1.5; }; # IP des sekundären DNS-Servers
}
named-checkconf /etc/bind/named.conf.local

image.png

Zone Folder erstellen:
mkdir /etc/bind/zones
Forward Zone File erstellen:
nano /etc/bind/zones/db.test.local
$TTL    604800
@       IN      SOA     ns1.test.local. admin.test.local. (
                           3         ; Serial
                      604800         ; Refresh
                       86400         ; Retry
                     2419200         ; Expire
                      604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.test.local.
@       IN      NS      ns2.test.local.
ns1     IN      A       192.168.1.4
ns2     IN      A       192.168.1.5
router  IN      A       192.168.1.1
named-checkzone test.local /etc/bind/zones/db.test.local

image.png

Reverse Zone File erstellen:
nano /etc/bind/zones/db.test.local.rev
$TTL    604800
; SOA record with MNAME and RNAME updated
@       IN      SOA     cherry.example. root.cherry.example. (
                              2         ; Serial Note: increment after each change
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; Name server record
@       IN      NS      ns1.test.local.
@       IN      NS      ns2.test.local.
; A record for name server
ns1     IN      A       192.168.1.4
ns2     IN      A       192.168.1.5
; PTR record for name server
4       IN      PTR     ns1.test.local.
5       IN      PTR     ns2.test.local.
; PTR record for clients
1       IN      PTR     router.test.local.
named-checkzone test.local /etc/bind/zones/db.test.local.rev

image.png

Bind Neustarten
systemctl restart bind9

Testen des DNS Servers

Forward Zone
nslookup ns1.test.local 192.168.1.4
nslookup ns2.test.local 192.168.1.4
nslookup router.test.local 192.168.1.4

image.png

Reverse Zone
nslookup 192.168.1.1 192.168.1.4
nslookup 192.168.1.4 192.168.1.4
nslookup 192.168.1.5 192.168.1.4

image.png

Konfiguration des DNS Servers (Slave)

Schritt 1: Installation von BIND

Paketdatenbank aktualisieren:
sudo apt-get update
BIND Installieren:
sudo apt-get install bind9 bind9utils bind9-doc dnsutils

Schritt 2: Konfiguration von BIND

Edit the named.conf.options file:
sudo nano /etc/bind/named.conf.options
acl LAN {
192.168.1.0/26;
};
options {
        directory "/var/cache/bind"; // default directory
        allow-query { localhost; LAN; }; // allow queries from localhost and 192.168.1.0-192.168.1.255
        forwarders { 1.1.1.1; }; // use CloudFlare 1.1.1.1 DNS as a forwarder
        recursion yes;  // allow recursive queries
};
named-checkconf /etc/bind/named.conf.options

image.png

Edit the named.conf.local file
sudo nano /etc/bind/named.conf.local
zone "test.local" {
    type slave;
    file "secondary/db.test.local"; # Pfad für die sekundäre Zonendatei
    masters { 192.168.1.4; }; # IP des primären DNS-Servers
};
zone "1.168.192.in-addr.arpa" IN {
     type slave;
     file "secondary/db.test.local.rev";
     masters { 192.168.1.4; };
};
named-checkconf /etc/bind/named.conf.local

image.png

Bind Neustarten
systemctl restart bind9

Testen des DNS Servers

Forward Zone
nslookup ns1.test.local 192.168.1.5
nslookup ns2.test.local 192.168.1.5
nslookup router.test.local 192.168.1.5

image.png

Reverse Zone
nslookup 192.168.1.1 192.168.1.5
nslookup 192.168.1.4 192.168.1.5
nslookup 192.168.1.5 192.168.1.5

image.png

Erweiterte Konfiguration und Analyse

Einbinden in vorhandenes Netzwerk

vogelsrv42002 - DHCP Konfiguration ändern
sudo nano /etc/dhcp/dhcpd.conf
# minimal sample /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;

subnet 192.168.1.0 netmask 255.255.255.192 {
 range 192.168.1.10 192.168.1.50;
 option routers 192.168.1.1;
 option domain-name-servers 192.168.1.4, 192.168.1.5;
}
systemctl restart isc-dhcp-server
Testen der neuen Konfiguration
nslookup /release
nslookup /all

image.png

Wireshark Analyse der DNS abfragen

Forward abfragen

image.png

PTR-Auflösung des DNS-Servers:

  • Beschreibung: Zeigt eine PTR-Abfrage von einem Client (192.168.1.9) an einen DNS-Server (192.168.1.4) zur Auflösung der IP-Adresse.
  • Wireshark-Filter: dns and ip.src == 192.168.1.9 and ip.dst == 192.168.1.4
  • Erwartete Anzeige:
    • Anfrage: PTR (Pointer) für eine bestimmte IP-Adresse.
    • Quelle: 192.168.1.9
    • Ziel: 192.168.1.4

image.png

Response der PTR-Auflösung:

  • Beschreibung: Antwort des DNS-Servers (192.168.1.4) an den Client (192.168.1.9) mit der aufgelösten Domain.
  • Wireshark-Filter: dns and ip.src == 192.168.1.4 and ip.dst == 192.168.1.9
  • Erwartete Anzeige:
    • Antwort: PTR (Pointer) mit dem entsprechenden Domainnamen.
    • Quelle: 192.168.1.4
    • Ziel: 192.168.1.9

image.png

A-Auflösung des DNS-Namens router.test.local:

  • Beschreibung: Zeigt eine A-Abfrage von einem Client (192.168.1.9) an einen DNS-Server (192.168.1.4) zur Auflösung des DNS-Namens router.test.local.
  • Wireshark-Filter: dns and ip.src == 192.168.1.9 and ip.dst == 192.168.1.4
  • Erwartete Anzeige:
    • Anfrage: A (Address) für router.test.local.
    • Quelle: 192.168.1.9
    • Ziel: 192.168.1.4

image.png

Response der A-Auflösung:

  • Beschreibung: Antwort des DNS-Servers (192.168.1.4) an den Client (192.168.1.9) mit der IP-Adresse von router.test.local.
  • Wireshark-Filter: dns and ip.src == 192.168.1.4 and ip.dst == 192.168.1.9
  • Erwartete Anzeige:
    • Antwort: A (Address) mit der IP-Adresse 192.168.1.1.
    • Quelle: 192.168.1.4
    • Ziel: 192.168.1.9

image.png

AAAA-Auflösung des DNS-Namens router.test.local:

  • Beschreibung: Zeigt eine AAAA-Abfrage von einem Client (192.168.1.9) an einen DNS-Server (192.168.1.4) zur Auflösung des DNS-Namens router.test.local.
  • Wireshark-Filter: dns and ip.src == 192.168.1.9 and ip.dst == 192.168.1.4
  • Erwartete Anzeige:
    • Anfrage: AAAA (IPv6 Address) für router.test.local.
    • Quelle: 192.168.1.9
    • Ziel: 192.168.1.4

image.png

Response der AAAA-Auflösung:

  • Beschreibung: Antwort des DNS-Servers (192.168.1.4) an den Client (192.168.1.9) mit der IPv6-Adresse von router.test.local oder einer leeren Antwort, wenn keine IPv6-Adresse vorhanden ist.
  • Wireshark-Filter: dns and ip.src == 192.168.1.4 and ip.dst == 192.168.1.9
  • Erwartete Anzeige:
    • Antwort: keine Antwort (leer).
    • Quelle: 192.168.1.4
    • Ziel: 192.168.1.9

image.png

Reverse abfragen

PTR-Auflösung des DNS-Servers:

  • Beschreibung: Zeigt eine PTR-Abfrage von einem Client (192.168.1.9) an einen DNS-Server (192.168.1.4) zur Auflösung der IP-Adresse.
  • Wireshark-Filter: dns and ip.src == 192.168.1.9 and ip.dst == 192.168.1.4
  • Erwartete Anzeige:
    • Anfrage: PTR (Pointer) für eine bestimmte IP-Adresse.
    • Quelle: 192.168.1.9
    • Ziel: 192.168.1.4

image.png

Response der PTR-Auflösung:

  • Beschreibung: Antwort des DNS-Servers (192.168.1.4) an den Client (192.168.1.9) mit der aufgelösten Domain.
  • Wireshark-Filter: dns and ip.src == 192.168.1.4 and ip.dst == 192.168.1.9
  • Erwartete Anzeige:
    • Antwort: PTR (Pointer) mit dem entsprechenden Domainnamen.
    • Quelle: 192.168.1.4
    • Ziel: 192.168.1.9

image.png

PTR-Auflösung der IP-Adresse:

  • Beschreibung: Zeigt eine PTR-Abfrage von einem Client (192.168.1.9) an einen DNS-Server (192.168.1.4) zur Auflösung der IP-Adresse.
  • Wireshark-Filter: dns and ip.src == 192.168.1.9 and ip.dst == 192.168.1.4
  • Erwartete Anzeige:
    • Anfrage: PTR (Pointer) für die IP-Adresse 192.168.1.1.
    • Quelle: 192.168.1.9
    • Ziel: 192.168.1.4

image.png

Response der PTR-Auflösung:

  • Beschreibung: Antwort des DNS-Servers (192.168.1.4) an den Client (192.168.1.9) mit der aufgelösten Domain.
  • Wireshark-Filter: dns and ip.src == 192.168.1.4 and ip.dst == 192.168.1.9
  • Erwartete Anzeige:
    • Antwort: router.test.local.
    • Quelle: 192.168.1.4
    • Ziel: 192.168.1.9

image.png

Cloud DNS (AWS)

In AWS besitze Ich bereits eine DNS Zone Namens mregli.cloud. Die Zone wird gemanaged in einem Service Namens Route 53 (DNS-Service). Das UI sieht wie folgt aus:

image.png

In AWS kann man die folgenden DNS Einträge erstellen:

image.png

Der Grund wieso man den AWS DNS benutzen soll ist da man die DNS Server im Hintergrund nicht selber Managen muss und da die DNS Server eine 100% Verfügbarkeit versprechen da die DNS Funktion niemals ausfallen darf.

Dynamische DNS-Updates (Local)

Verzeichnis für Geheimnisse erstellen: Erstellen Sie ein Verzeichnis, um die generierten Schlüssel sicher zu speichern.

mkdir /secrets
tsig-keygen ddns >> /secrets/ddns

TSIG-Schlüssel (Transaction Signature) generieren: Erstellen Sie einen TSIG-Schlüssel, der zur Authentifizierung von DNS-Updates verwendet wird.

key "ddns" {
        algorithm hmac-sha256;
        secret "TYkYPXTJXYVc9gM3cDvSbuwSaZ73bLf6LVfeKmDCB78=";
};

DNS-Zonendatei konfigurieren: Konfigurieren Sie Ihre DNS-Zonendatei, um dynamische Updates zu ermöglichen. Diese Konfiguration definiert die Zone, die als Master fungiert, und legt die Datei fest, in der die Zonendaten gespeichert werden.

key "ddns" {
        algorithm hmac-sha256;
        secret "D/Y0qfay469q2Nk7ROASD48oSCnjfUUvw1hLirl6Gqc=";
};
...
zone "test.local" {
    type master;
    file "/etc/bind/zones/db.test.local"; # Pfad zur Zonendatei
    allow-transfer { 192.168.1.5; }; # IP des sekundären DNS-Servers
    allow-update { key "ddns"; };
};
...

Anpassung des AppArmor-Profils für BIND

AppArmor ist ein Sicherheitsmodul, das die Berechtigungen von Anwendungen auf Systemebene einschränkt. Um dynamische DNS-Updates zuzulassen, müssen Sie das AppArmor-Profil für den BIND-DNS-Server anpassen:

AppArmor-Profil für BIND lokalisieren: Das AppArmor-Profil für BIND befindet sich normalerweise unter /etc/apparmor.d/usr.sbin.named. Öffnen Sie diese Datei zur Bearbeitung:

sudo nano /etc/apparmor.d/usr.sbin.named

AppArmor-Profil ändern: Fügen Sie die erforderlichen Berechtigungen für das Verzeichnis und die Dateien hinzu, die mit den DNS-Updates verbunden sind. Stellen Sie sicher, dass die folgenden Zeilen (oder ähnliche) enthalten und korrekt konfiguriert sind:

image.png

AppArmor-Profile neu laden: Nachdem Sie das Profil geändert haben, laden Sie die AppArmor-Profile neu, um die Änderungen anzuwenden:

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.named

Berechtigungen überprüfen: Stellen Sie sicher, dass der BIND-Benutzer (named oder ähnlich) die erforderlichen Berechtigungen hat, um in das Verzeichnis /etc/bind/zones zu schreiben und die Datei db.test.local.jnl zu erstellen oder zu ändern. Falls dies noch nicht geschehen ist, passen Sie die Berechtigungen an:

sudo chown -R bind:bind /etc/bind/zones
sudo chmod -R 755 /etc/bind/zones

BIND neu starten: Starten Sie den BIND-Dienst neu, um die Änderungen anzuwenden:

systemctl restart bind9

Update erneut versuchen: Versuchen Sie, das DDNS-Update erneut durchzuführen:

nsupdate -k /secrets/ddns
> server ns1.test.local
> update add home.test.local 200 A 1.2.3.4
> send

Testen kann man es dann über einen einfachen normalen nslookup.

nslookup home.test.local

image.png

Dynamische DNS-Updates (Maas)

image.png

TSIG-Schlüssel speichern: Erstellen Sie die Datei /secrets/maas und fügen Sie den TSIG-Schlüssel ein:

nano /secrets/maas

Fügen Sie den folgenden Inhalt in die Datei ein:

key "manuel.regli" {
	algorithm hmac-sha256;
	secret "m5W38E9ugk8hIsi0dav9FkOoIFIny2yiyISpn0MMDtA=";
};

Speichern Sie die Datei und schließen Sie den Editor.

Berechtigungen setzen: Stellen Sie sicher, dass die Datei die richtigen Berechtigungen hat, sodass nur der notwendige Benutzer (in diesem Fall der Benutzer, der nsupdate ausführt) darauf zugreifen kann:

sudo chown root:root /secrets/maas
sudo chmod 600 /secrets/maas

DNS-Update durchführen: Verwenden Sie nsupdate, um den DNS-Eintrag zu aktualisieren:

nsupdate -k /secrets/maas
> server ns.users.bbw-it.ch.
> update add test.manuel.regli.users.bbw-it.ch. 200 IN A 2.12.21.2
> send

Überprüfung des Updates: Überprüfen Sie den neuen DNS-Eintrag mit nslookup:

nslookup test.manuel.regli.users.bbw-it.ch

image.png

nslookup test.manuel.regli.users.bbw-it.ch ns.users.bbw-it.ch

image.png

image.png

IPv6

Forward Zone file bearbeiten

Öffnen Sie die Zonendatei zur Bearbeitung:

nano /etc/bind/zones/db.test.local

Fügen Sie die IPv6-Einträge und andere DNS-Einträge wie folgt hinzu:

$ORIGIN .
$TTL 604800     ; 1 week
test.local              IN SOA  ns1.test.local. admin.test.local. (
                                4          ; serial
                                604800     ; refresh (1 week)
                                86400      ; retry (1 day)
                                2419200    ; expire (4 weeks)
                                604800     ; minimum (1 week)
                                )
                        NS      ns1.test.local.
                        NS      ns2.test.local.
$ORIGIN test.local.
$TTL 200        ; 3 minutes 20 seconds
home                    A       1.2.3.4
$TTL 604800     ; 1 week
ns1                     A       192.168.1.4
ns1                     AAAA    fe80::250:56ff:fe9e:7055
ns2                     A       192.168.1.5
router                  A       192.168.1.1
Reverse Zone file bearbeiten

Um herauszufinden wie der Eintrag lauten muss kann man den folgenden Trick verwenden:

dig -x fe80::250:56ff:fe9e:7055

image.png

Reverse Zone Datei bearbeiten: Öffnen Sie die Datei zur Bearbeitung:

nano /etc/bind/zones/db.8.e.f.ip6.arpa

Inhalt der Reverse Zone Datei: Fügen Sie die PTR-Einträge hinzu, um die IPv6-Adresse aufzulösen:

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
            2024052601 ; Seriennummer
            3600       ; Refresh
            1800       ; Retry
            1209600    ; Expire
            3600 )     ; Minimum TTL

@    IN  NS  ns1.test.local.
@    IN  NS  ns2.test.local.

5.5.0.7.e.9.e.f.f.f.6.5.0.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. 3600 IN PTR ns1.test.local.
Konfiguration in named.conf.local

named.conf.local bearbeiten: Öffnen Sie die Datei zur Bearbeitung:

nano /etc/bind/named.conf.local

Konfigurationsblock für die Reverse Zone hinzufügen: Fügen Sie den folgenden Block hinzu:

zone "8.e.f.ip6.arpa" IN {
     type master;
     file "/etc/bind/zones/db.8.e.f.ip6.arpa";
     allow-transfer { 192.168.1.5; };
};
Testen

Forward Zone

image.png

Reverse Zone:

dig -x fe80::250:56ff:fe9e:7055

image.png

Reflexion

Zusammenfassend kann ich sagen, dass die Arbeit an sich Spass gemacht hat, ausser vielleicht der Teil mit IPv6, aber das liegt eher an mir und meinem Hass darauf. Probleme an sich hatte ich nur einmal mit Dyndns als der Bind9 Server die Journaldatei nicht erstellen wollte und ich 2 Stunden gebraucht habe um herauszufinden das es am AppArmor lag. Ansonsten war es im Grossen und Ganzen ein angenehmer Auftrag.

Back to top