// ****************************** named.conf ******************************

// ISC Bind Konfigurationsdatei 
// Konfig-Beschreibung: https://dokuwiki.nausch.org/doku.php/linux:bind

// ********** Variablendefinition für die unterschiedlichen ACLs **********
acl edmz {
  172.17.2.0/24;
  2003:a:e0d:7600::/64;
};

acl idmz {
  10.0.0.0/24;
  fd00::3:10:0:0:110/128;
  2003:a:e0d:7603::/64;
};

acl intra {
  10.0.10.0/24;
  fd00::7:10:0:10:110/128;
  2003:a:e0d:7607::/64;
};

acl primary {
  10.0.0.110/32;
  fd00::3:10:0:0:110/128;
  2003:a:e0d:7607:10::110/128;
};

acl interfaces {
  127.0.0.1;
  ::1;
  10.0.0.110/32;
  fd00::3:10:0:0:110/128;
  2003:a:e0d:7603:10::110/128;
  10.0.10.110/32;
  fd00::7:10:0:10:110/128;
  2003:a:e0d:7607:10:0:10:110/128;
};


acl local {
  127.0.0.1;
  ::1;
};


// *********************** rndc Schlüsseldefinition ***********************
include "/etc/rndc.key";

// *********************** rndc Control-Definition ************************
controls {
	inet 127.0.0.1 port 953
	allow { 127.0.0.1; } keys { "homelab-key"; };
};

// ***************** Definition der allgemeinen Optionen ******************
options {
  // Arbeitsverzeichnis des Servers
  directory "/var/named";

  // Das Verzeichnis, in dem sich die öffentlichen und privaten 
  // DNSSEC-Schlüsseldateien befinden sollen. 
  key-directory "/var/named/keys";

  // Das Verzeichnis, in dem die Dateien gespeichert werden, welche 
  // die verwalteten DNSSEC-Schlüssel verfolgen.
  managed-keys-directory "/var/named/dynamic";

  // Dies gibt das Verzeichnis an, in dem die Konfigurationsparameter für
  // Zonen gespeichert werden, die über rndc addzone hinzugefügt wurden.
  // Standardmäßig ist dies das Arbeitsverzeichnis.
  new-zones-directory "/var/named/zones";

  // Der Pfadname der Datei, auf die der Server die Datenbank übergibt, 
  // wenn er angewiesen wird.
  dump-file "/var/named/data/cache_dump.db";

  // Der Pfadname der Datei, an die der Server Statistiken anhängt, 
  // wenn er Server hierzu angewiesen wird.
  statistics-file "/var/named/data/named_stats.txt";

  // Hiermit werden Speicherstatistiken in die Datei geschrieben, die beim
  // Beenden durch memstatistics-file angegeben wird. Die Standardeinstell-
  // ung ist "no", es sei denn, -m record wird in der Befehlszeile angege-
  // ben. In diesem Fall lautet die Einstellung "yes".
  memstatistics yes;

  // Der Pfadname der Datei, in die der Server beim Beenden die 
  // Speicherverbrauchsstatistik schreibt.
  memstatistics-file "/var/named/data/named_mem_stats.txt";

  // Hiermit wird der Algorithmus festgelegt, der beim Generieren des Ser-
  // ver-Cookies verwendet werden soll. Die Optionen sind "aes", "sha1" 
  // oder "sha256". Der Standardwert ist "aes", sofern dies von der krypto-
  // grafischen Bibliothek unterstützt wird, andernfalls "sha256".
  // cookie-algorithm aes;

  // Der Pfadname der Datei, in die ein TSIG-Sitzungsschlüssel geschrieben 
  // werden soll, der mit named für die Verwendung durch nsupdate -l 
  // erzeugt wurde.
  session-keyfile "/run/named/session.key";

  // Der Pfadname der Datei, auf die der Server die security roots 
  // schreibt, wenn er hierzu angewiesen wird.
  secroots-file "/var/named/data/named_secroots.db";

  // Dies ist der für den TSIG-Sitzungsschlüssel zu verwendende Algorithmus.
  // Gültige Werte sind hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, 
  // hmac-sha512 und hmac-md5. Wenn nichts angegeben wird, ist der 
  // Standardwert hmac-sha256.
  session-keyalg hmac-sha512;

  // Hiermit wird die maximale RSA-Exponentengröße in Bits festgelegt, die
  // bei der Validierung akzeptiert wird. Gültige Werte sind 35 bis 4096
  // Bits. Der Standardwert Null wird ebenfalls akzeptiert und entspricht
  // 4096.
  max-rsa-exponent-size 4096;

  // Pfadname der Datei, in die der Server Abfragen, die gerade 
  // wiederkehren, ausgibt, wenn er dazu angewiesen wird.
  recursing-file "/var/named/data/named_recursing.db";

  // Pfadname der Datei, in die der Server seine Prozess-ID schreibt.
  pid-file "/run/named/named.pid";

  // Wird folgender Parameter auf "yes" gesetzt, dann fügt der Server 
  // bei der Generierung von Antworten nur dann Datensätze zur authority
  // und additional data sections hinzu, wenn sie benötigt werden.
  minimal-responses no;

  // Wird folgender Parameter auf "yes" gesetzt, dann wird der Server
  // versuchen bei einer rekursiven DNS-Abfrage, alles versuchen um die
  // Anfrage bestmöglich abzuarbeiten. Ist die Rekursion ausgeschaltet 
  // ist und der Server die Antwort noch nicht kennt, gibt er eine 
  // referral response (Empfehlungsantwort) zurück. 
  // Die Default-Einstellung ist "yes". 
  // Wichtig: Das Setzen der Rekursions-Option auf "no" verhindert nicht,
  // dass Clients Daten aus dem Server-Cache beziehen; es verhindert nur, 
  // dass neue Daten als Folge von Client-Abfragen zwischengespeichert werden.
  //      
  // Sofern der rekursiver DNS-Server über eine öffentliche IP-Adresse 
  // verfügt, MUSS zwingend eine Zugriffskontrolle aktiviert werden, um 
  // Abfragen auf die legitimen Benutzer zu beschränken!
  // Nichtbeachtung kann zu Folgen haben, dass sonst der Server ein Teil 
  // von groß angelegten DNS-Amplifikations-Angriffen werden könnte.
  // Die Implementierung von BCP38 in Ihrem Netzwerk würde diese 
  // Angriffsfläche erheblich reduzieren!
  recursion yes;

  // DNSsec-Validierung aktivieren und mit den Root-Zertificaten abgleichen.
  // "yes" = DNSSEC-Validierung ist aktiviert, aber ein Vertrauensanker muss 
  // manuell konfiguriert werden. Eine Validierung findet erst dann 
  // statt, wenn mindestens einen vertrauenswürdigen Schlüssel 
  // manuell konfiguriert haben. Dies ist die Voreinstellung.
  // "no"  = Die DNSSEC-Validierung ist deaktiviert, und rekursive Server 
  // verhalten sich in der "altmodischen" Art und Weise, unsichere 
  // DNS-Lookups durchzuführen.
  // "auto"= Die DNSSEC-Validierung ist aktiviert, und es wird ein 
  // Standard-Trust-Anker (als Teil von BIND enthalten) für die 
  // DNS-Rootzone verwendet.
  dnssec-validation auto;

  // Wird diese option gesetzt, stellt dnssec-lookaside dem validator eine 
  // alternative Methode zur Verfügung, um DNSKEY-Einträge bei Start einer
  // Zone (top of a zone) zu validieren. Wenn dnssec-lookaside auf auto 
  // gesetzt ist, dann werden die eingebauten Standardwerte für die 
  // DLV-Domäne und den Vertrauensanker verwendet, zusammen mit einem 
  // eingebauten Schlüssel für die Validierung.
  // dnssec-lookaside auto;

  // Diese Option wird verwendet, um den Zeichensatz und die Syntax 
  // bestimmter Domänennamen in Masterdateien und/oder DNS-Antworten, 
  // die vom Netzwerk empfangen werden, einzuschränken.
  check-names master warn;

  // Gibt an, welche Hosts diesen Server, einen Slave, zusätzlich zu den 
  // Zonen-Mastern über Zonenänderungen benachrichtigen dürfen. 
  allow-notify {
    ::1;
    127.0.0.1;
  };

  // Definiert welche Hosts gewöhnliche DNS-Fragen stellen dürfen.
  allow-query {
    edmz;
    idmz;
    intra;
    localhost;
  };

  // Definiert welche lokalen Adressen gewöhnliche DNS-Anfragen
  // annehmen können.
	allow-query-on {
        interfaces;
	};

  // Definiert welche Hosts Antworten aus dem Cache erhalten dürfen.
  allow-query-cache {
		edmz;
                idmz;
                intra;
                localhost;
	};

  // Definiert welche lokalen Adressen Antworten aus dem Cache senden können. 
  allow-query-cache-on {
		interfaces;
	};

  // Legt fest, welche Hosts rekursive Abfragen über diesen Server i
  // durchführen dürfen.
  allow-recursion {
    edmz;
    idmz;
    intra;
    localhost;
  };

  // Legt fest, welche lokalen Adressen rekursive Abfragen akzeptieren können. 
  allow-recursion-on {
		interfaces;
	};

  // Gibt an, welche Hosts Zonentransfers vom Server empfangen dürfen.
  allow-transfer {
    interfaces;
  };

  // Ist die dynamische Aktualisierung für eine Zone mit der Option 
  // "allow-update" aktiviert, darf KEINENFALLS die Zonendatei manuell 
  // bearbeitet werden!
  allow-update {
    none;
  };

  // Wenn ja,dann können Zonen zur Laufzeit über rndc addzone hinzugefügt
  // werden. Die Standardeinstellung ist "no". Die Konfigurationsparame-
  // ter neu hinzugefügter Zonen werden gespeichert, sodass sie nach einem
  // Neustart des Servers erhalten bleiben. Die Konfigurationsinformationen
  // werden in einer Datei namens "viewname.nzf" gespeichert (oder, wenn 
  // "named" mit liblmdb kompiliert wurde, in einer LMDB-Datenbankdatei 
  // namens "viewname.nzd"). "viewname" ist der Name der Ansicht, es sei
  // denn, der Name der Ansicht enthält Zeichen, die nicht mit der Verwen-
  // dung als Dateiname kompatibel sind. In diesem Fall wird stattdessen
  // ein kryptografischer Hash des Ansichtsnamens verwendet. Konfigurati-
  // onen für Zonen, die zur Laufzeit hinzugefügt werden, werden entweder
  // in einer New-Zone-Datei (NZF) oder einer New-Zone-Datenbank (NZD) 
  // gespeichert, je nachdem, ob named zum Zeitpunkt der Kompilierung mit
  // liblmdb verknüpft wurde. Weitere Informationen zu rndc addzone finden
  // Sie unter rndc – Name-Server-Steuerungsprogramm.
  allow-new-zones no;

  // Gibt eine Liste von Adressen an, von denen der Server keine Anfragen 
  // annimmt oder die zur Lösung einer Anfrage verwendet werden. Anfragen 
  // von diesen Adressen werden nicht beantwortet.
  blackhole { none; };

  // Die Schnittstellen und Ports, von denen der Server Anfragen beantwortet,
  // können mit der Listen-On-Option angegeben werden.
  listen-on port 53 { interfaces; };
  listen-on-v6 port 53 { interfaces; };

  // Sofern der Server die Antwort auf eine Frage nicht kennt, fragt er 
  // andere Nameserver ab. query-source gibt die Adresse und den Port an, 
  // die für solche Abfragen verwendet werden.
  query-source address * ;

  // Die Abfrageprotokollierung bietet ein vollständiges Protokoll aller
  // eingehenden Abfragen und aller Abfragefehler. Dies bietet einen besseren
  // Einblick in die Serveraktivität, allerdings mit einem erheblichen 
  // Leistungsabfall bei stark ausgelasteten Servern. Die Option "querylog"
  // gibt an, ob die Abfrageprotokollierung beim ersten Start von named
  // aktiv sein soll.
  querylog no;

  // Maximale Größe jeder Journaldatei fest. 
  // (default ist unbegrenzt, was auch 2 Gigabyte bedeutet)
  max-journal-size unlimited;

  // Maximale Anzahl gleichzeitiger rekursiver Suchvorgänge, die der Server
  // für Clients durchführt. Der Standardwert ist 1000.
  recursive-clients 1000;

  // Maximale Anzahl gleichzeitiger TCP Verbindungen die der Server von 
  // Clients akzeptiert. Der Standardwert ist 100.
  tcp-clients 100;

  // Maximale Menge an Arbeitsspeicher (in Bytes), die für den Server-Cache 
  // verwendet werden kann. Ein Wert von 0 ist speziell, d.h. Datensätze 
  // werden nur aus dem Cache gelöscht, wenn ihre TTLs ablaufen ist. Ein 
  // weiteres spezielles Schlüsselwort unlimited bedeutet den maximalen Wert
  // von 32-Bit-Ganzzahlen ohne Vorzeichen (0xffffffffffff), die haben nicht
  // den gleichen Effekt wie 0 auf Maschinen, die mehr als 32 Bit unterstützen.
  // Alle positiven Werte kleiner als 2MB werden ignoriert und auf 2MB gesetzt.
  // Bei einem Server mit mehreren Views gilt die Begrenzung separat für
  // den Cache der einzelnen Views. Der Standardwert ist 0.
  max-cache-size 2048;

  // List Queue Depth: Die Standardeinstellung und das Minimum ist 10. Sofern
  // der Kernel Accept-Filter-Verbindungen unterstützt, werden die Daten im
  // Kernel-Space gehalten und gewartet bevor die Anfrage weiterverarbeitet
  // wird. Werte ungleich 0 unter 10 werden stillschweigend erhöht. 
  // ein Wert von 0 kann gesetzt werden und definiert auf den meisten 
  // Plattformen, dass die Länge der Listen-Warteschlange auf einen 
  // systembedingter Standardwert gesetzt wird.
  tcp-listen-queue 10;

  // Der Server scannt die Liste der Netzwerkschnittstellen in regelmäßigen
  // Abständen (Minuten). Die Standardeinstellung ist 60 Minuten. Der 
  // Maximalwert beträgt 28 Tage (40320 Minuten). Wird der wert auf 0 gesetzt,
  // erfolgt die Überprüfung der Schnittstelle nur dann, wenn die 
  // Konfigurationsdatei geladen wird. Nach dem Scan beginnt der Server mit 
  // dem Abhören von Abfragen auf neu entdeckte Interfaces (vorausgesetzt, sie 
  // sind durch die Listen-On-Konfiguration erlaubt) und hört auf, auf nicht 
  // mehr vorhandene Interfaces zu hören.
  interface-interval 0;

  // Definiert die Zeit in Sekunden, in denen eine lahme Serveranzeige 
  // zwischengespeichert wird. 0 deaktiviert das Caching.
  // Dieser Wert ist immer auf 0 gesetzt. Weitere Informationen finden sich
  // im Sicherheitshinweis zu CVE-2021-25219.
  lame-ttl 0;

  // Um den Netzwerkverkehr zu reduzieren und die Leistung zu erhöhen, 
  // speichert der Server negative Antworten. max-ncache-ttl wird verwendet, 
  // um eine maximale Aufbewahrungszeit für diese Antworten im Server in 
  // Sekunden festzulegen. Die Standardeinstellung von max-ncache-ttl ist 
  // 10800 Sekunden (3 Stunden). max-ncache-ttl kann nicht länger als 7 Tage 
  // dauern und wird stillschweigend auf 7 Tage gekürzt, sollte er auf einen 
  // größeren Wert gesetzt werden!
  max-ncache-ttl 10800;

  // Legt die maximale Zeit fest, für die der Server gewöhnliche (positive) 
  // Antworten zwischenspeichert. Der Standardwert ist eine Woche (7 Tage). 
  // Ein Wert von Null kann dazu führen, dass alle Abfragen SERVFAIL 
  // zurückgeben, da im Auflösungsprozess verloren gegangene Caches von 
  // Zwischen-RRsets (z.B. NS und glue AAAA/A-Records) verloren gehen!
  max-cache-ttl 604800;

  // Definiert die Größe des angebotenen EDNS UDP-Puffers (in Bytes), um 
  // die Größe der empfangenen Pakete zu kontrollieren. Gültige Werte sind 
  // 512 bis 4096 (Werte außerhalb dieses Bereichs werden stillschweigend 
  // angepasst). Der Standardwert ist 4096. Der übliche Grund für das 
  // Setzen von edns-udp-size auf einen nicht standardmäßigen Wert ist es, 
  // UDP-Antworten zu erhalten, um durch gebrochene Firewalls zu gehen, die 
  // fragmentierte Pakete blockieren und/oder UDP-Pakete blockieren, die 
  // größer als 512 Bytes sind. named wird auf die Verwendung von 512 Bytes 
  // zurückgreifen, wenn es eine Reihe von Zeitüberschreitungen beim 
  // Anfangswert erhält. 512 Bytes werden nicht angeboten, um Websites zu 
  // ermutigen, ihre Firewalls zu reparieren. Kleine EDNS UDP-Größen führen 
  // zu einer übermäßigen Nutzung von TCP. 
  edns-udp-size 4096;

  // Legt die maximale EDNS UDP-Nachrichtengröße fest, die in Bytes gesendet 
  // wird. Gültige Werte sind 512 bis 4096 (Werte außerhalb dieses Bereichs 
  // werden stillschweigend angepasst). Der Standardwert ist 4096. Der 
  // übliche Grund für das Setzen von max-udp-size auf einen nicht 
  // standardmäßigen Wert ist es, UDP-Antworten zu erhalten, um durch defekte 
  // Firewalls zu gehen, die fragmentierte Pakete blockieren und/oder 
  // UDP-Pakete blockieren, die größer als 512 Bytes sind. Dies ist unabhängig
  // vom beworbenen Empfangspuffer (edns-udp-size). Wird dieser Wert auf einen 
  // niedrigen Wert gesetzt, wird zusätzlicher TCP-Verkehr zum Nameserver 
  // erzeugt!
  max-udp-size 4096;

  // Definiert den Anfangswert (Minimum) der Anzahl rekursiver gleichzeitiger 
  // Clients für eine beliebige Abfrage (<qname,qtype,qclass>) fest, die der 
  // Server akzeptiert, bevor er weitere Clients ignorieren wird. Named wird 
  // versuchen, diesen Wert selbst zu tunen und Änderungen werden 
  // protokolliert. Der Standardwerte ist 10.
  clients-per-query 10;

  // Definiert den Anfangswert (Maximum) der Anzahl rekursiver gleichzeitiger 
  // Clients für eine beliebige Abfrage (<qname,qtype,qclass>) fest, die der 
  // Server akzeptiert, bevor er neue Client-Verbindungen anlehnen wird.
  // Named wird versuchen, diesen Wert selbst zu tunen und Änderungen werden 
  // protokolliert. Die Standardeinstellung ist 100.
  max-clients-per-query 100;

  // Festlegung der Angaben (Version), die der Server über eine Abfrage des
  // Namens version.bind mit dem Typ TXT, Klasse CHAOS, melden soll. Der
  // Default-Wert ist die reale Versionsnummer des Servers. Durch die Angabe
  // der Version none wird die Verarbeitung der Abfragen deaktiviert.
  version "DNS - nausch.org";

  // Der Hostname, den der Server über eine Abfrage des Namens hostname.bind 
  // mit dem Typ TXT, Klasse CHAOS, melden soll. Dies ist standardmäßig der 
  // Hostname des Rechners, auf dem sich der Name-Server befindet, wie er von
  // der Funktion gethostname() gefunden wird. Die ID, die der Server beim 
  // Empfang einer NSID-Abfrage (Name Server Identifier) oder einer Abfrage 
  // des Namens ID.SERVER vom Typ TXT, Klasse CHAOS, melden soll. Der primäre 
  // Zweck solcher Abfragen ist es, herauszufinden, welcher einer Gruppe von 
  // Anycast-Servern Ihre Anfragen tatsächlich beantwortet. 
  // Angabe von server-id none; deaktiviert die Verarbeitung der Abfragen. 
  // Die Angabe von server-id hostname; bewirkt, dass named den Hostnamen 
  // verwendet, wie er durch die Funktion gethostname() gefunden wurde. 
  // Der Standardwert ist none.
  hostname none;
  server-id none;

  // BIND 9-Zugriffskontrolllisten werden verwendet, um den Zugriff auf ver-
  // schiedene Serverfunktionen entsprechend der IP-Adresse des Anfragenden 
  // zu beschränken. BIND 9.10 kann Daten aus MaxMind GeoIP-Datenbanken ver-
  // wenden, um Beschränkungen basierend auf dem (vermuteten) geografischen
  // Standort dieser Adresse zu erreichen.
  geoip-directory none;


};

// Die BIND 9-Statistiken können auch über das HTTP-Protokoll von 
// einem laufenden BIND 9-Server abgerufen werden. BIND 9 verfügt 
// über einen winzigen integrierten Webserver, der die Statistik-
// daten im XML- oder JSON-Format bereitstellt.
statistics-channels {
  inet 127.0.0.1 port 8080 allow {
    127.0.0.1;
  };
};

// ******************** Definition der Views and Zones ********************
//
//                                 WICHTIG:
//                                 ========
// 
//            Die Reihenfolge der View-Anweisungen ist signifikant. 
//            Eine Client-Anfrage wird im Kontext der ersten Ansicht 
//                       beantwortet, zu der sie passt!
//
//   ACHTUNG: Eine Zone kann entweder durch Bearbeiten von Zonendateien 
//            und Neuladen des Servers oder durch dynamisches Update 
//            aktualisiert werden, aber NIEMALS durch beides! 
//            Ist die dynamische Aktualisierung für eine Zone mit der 
//            Option "allow-update" aktiviert, darf KEINENFALLS die 
//            Zonendatei manuell bearbeitet werden! Der Server würde 
//            dann nicht mehr versuchen, die Informationen zur Zone
//            aus der Datei zu laden!

view "intern" IN {
  // Ist der Anfragende Client aus dem Intranet (Zone intra)?
  match-clients {
                  local;
                  intra;
                  idmz;
                };

  // View: intern - Zone: localhost
  zone "localhost" IN {
    type master;
    file "localhost.zone";
  };

  // View: intern - Zone: localhost IPv4 (reverse)
  zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "127.0.0.zone";
  };

  // View: intern - Zone: localhost IPv6 (reverse)
  zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
    type master;
    file "localhost.ip6.zone";                                                                                      
  };

  // View: intern - Zone: root server
  zone "." IN {
    type hint;
    file "named.root";
  };

  // View: intern - Zone: intra.nausch.org (forward)
  zone "intra.nausch.org" IN {
    type master;
    file "zones/i.intra.nausch.org.db";
  };

  // View: intern - Zone: intra.nausch.org (reverse)
  zone "10.0.10.in-addr.arpa" IN {
    type master;
    file "zones/i.intra.nausch.org.in-addr.db";
  };

  // View: intern - Zone: intra.nausch.org (IPv6 ULA reverse)
  zone "7.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
    type master;
    file "zones/i.intra.nausch.org.ip6.db";
  };

  // View: intern - Zone: idmz.nausch.org (forward)
  zone "idmz.nausch.org" IN {
    type master;  
    file "zones/i.idmz.nausch.org.db";
  };

  // View: intern - Zone: idmz.nausch.org (reverse)
  zone "0.0.10.in-addr.arpa" IN {
    type master;
    file "zones/i.idmz.nausch.org.in-addr.db";
  };

  // View: intern - Zone: idmz.nausch.org (IPv6 ULA reverse)
  zone "3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
    type master;
    file "zones/i.idmz.nausch.org.ip6.db";
  };

  // View: intern - Zone: edmz.nausch.org (forward)
  zone "edmz.nausch.org" IN {
    type master;  
    file "zones/i.edmz.nausch.org.db";
  };

  // View: intern - Zone: edmz.nausch.org (reverse)
  zone "2.17.172.in-addr.arpa" IN {
    type master;
    file "zones/i.edmz.nausch.org.in-addr.db";
  };

  // View: intern - Zone: edmz.nausch.org (IPv6 ULA reverse)
  zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
    type master;
    file "zones/i.edmz.nausch.org.ip6.db";
  };

  // View: intern - Zone: nausch.org (forward)
  zone "nausch.org" IN {
    type master;  
    file "zones/i.nausch.org.db";
  };

};

// Ist der Anfragende Client aus der DMZ?
view "extern" IN {
  match-clients {
                  edmz;
                };

  // View: extern - Zone: localhost
  zone "localhost" IN {
    type master;
    file "localhost.zone";
  };

  // View: extern - Zone: localhost (reverse IPv4)
  zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "127.0.0.zone";                                                                                             
  };

  // View: extern - Zone: localhost (reverse IPv6) 
  zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
    type master;
    file "localhost.ip6.zone";
  };

  // View: extern - Zone: root server
  zone "." IN {
    type hint;
    file "named.root";
  };

  // View: extern - Zone: idmz.nausch.org (forward)
  zone "idmz.nausch.org" IN {
    type master;  
    file "zones/e.idmz.nausch.org.db";
  };

  // View: extern - Zone: idmz.nausch.org (reverse)
  zone "0.0.10.in-addr.arpa" IN {
    type master;
    file "zones/e.idmz.nausch.org.in-addr.db";
  };

  // View: extern - Zone: idmz.nausch.org (IPv6 ULA reverse)
  zone "3.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
    type master;
    file "zones/e.idmz.nausch.org.ip6.db";
  };

  // View: extern - Zone: edmz.nausch.org (forward)
  zone "edmz.nausch.org" IN {
    type master;         
    file "zones/e.edmz.nausch.org.db";
  };

  // View: extern - Zone: edmz.nausch.org (reverse)
  zone "2.17.217.in-addr.arpa" IN {
    type master;
    file "zones/e.edmz.nausch.org.in-addr.db";
  };

  // View: extern - Zone: edmz.nausch.org (IPv6 ULA reverse)
  zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa" IN {
    type master;
    file "zones/e.edmz.nausch.org.ip6.db";
  };

  // View: extern - Zone: nausch.org (forward)
  zone "nausch.org" IN { 
    type master;             
    file "zones/e.nausch.org.db";  
  };

  // View: extern - Zone: nausch.org (reverse)
  zone "131.13.92.217.in-addr.arpa" IN {
    type master;
    file "zones/e.nausch.org.in-addr.db";
  };

  // View: extern - Zone: nausch.org (IPv6 GUA reverse)
  zone "3.0.6.7.d.0.e.0.a.0.0.0.3.0.0.2.ip6.arpa" IN {
    type master;
    file "zones/e.nausch.org.ip6.db";
  };

};

// ******************* Definition der Logging-Parameter *******************
logging {

  // Definition der unterschiedlichen Kanäle

	channel default_log {
		file "/var/log/named/default" versions 4 size 20m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel auth_servers_log {
		file "/var/log/named/auth_servers" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel dnssec_log {
		file "/var/log/named/dnssec" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel zone_transfers_log {
		file "/var/log/named/zone_transfers" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel ddns_log {
		file "/var/log/named/ddns" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel client_security_log {
		file "/var/log/named/client_security" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel rate_limiting_log {
		file "/var/log/named/rate_limiting" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel rpz_log {
 		file "/var/log/named/rpz" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

	channel dnstap_log {
		file "/var/log/named/dnstap" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};
  // Wenn man die Kategorie "queries" definiert hat und standardmässig keine 
  // Abfrageprotokollierung wünscht, stellt man sicher, dass Sie die Option 
  // "querylog no"“ vorhanden ist. So kann man anschliessend die Abfrage-
  // protokollierung mit dem Befehl "rndc querylog" ein- und ausschalten.
	channel queries_log {
		file "/var/log/named/queries" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity info;
	};

  // Dieser Kanal ist dynamisch, sodass bei einer Erhöhung des Debug-Levels
  // mit Hilfe von rndc bei laufendem Server zusätzliche Informationen über
  // fehlgeschlagene Abfragen protokolliert werden.
  // Andere Debug-Informationen für andere Kategorien werden an den Kanal 
  // default_debug (der ebenfalls dynamisch ist) gesendet, ohne jedoch die
  // reguläre Protokollierung zu beeinträchtigen.
	channel query-errors_log {
		file "/var/log/named/query-errors" versions 4 size 2m;
		print-time yes;
		print-category yes;
		print-severity yes;
		severity dynamic;
	};

  // Dies ist der Standard-Syslog-Kanal, der hier der Übersichtlichkeit 
  // halber definiert wurde. Man muss ihn nicht verwenden, wenn man lieber
  // in eigenen Kanälen protokollieren möchte. Er sendet an die Daemon-
  // Einrichtung von syslog und sendet nur protokollierte Nachrichten mit
  // der Priorität "info" und höher. (Die Optionen zum Ausgeben von Zeit,
  // Kategorie und Severity sind nicht standardmäßig.)
	channel default_syslog {
		print-time yes;
		print-category yes;
		print-severity yes;
		syslog daemon;
		severity info;
	};

  // Dies ist der Standard-Debug-Ausgabekanal, welcher hier aus Gründen
  // der Übersichtlichkeit definiert wurde. Man kann natürlich das Ausgabe-
  // ziel auch neu definieren, wenn dies nicht zu den eigenen lokalen 
  // Systemadministrationsplan für die Protokollierung passt. Es handelt
  // sich auch um einen speziellen Kanal, der nur dann eine Ausgabe erzeugt,
  // wenn der Debug-Level ungleich Null ist.
	channel default_debug {
		print-time yes;
		print-category yes;
		print-severity yes;
		file "/var/log/named/named.run";
		severity dynamic;
	};

  // Protokollieren von Routinevorgängen in Syslog und Standardprotokoll

	category default { default_syslog; default_debug; default_log; };
	category config { default_syslog; default_debug; default_log; };
	category dispatch { default_syslog; default_debug; default_log; };
	category network { default_syslog; default_debug; default_log; };
	category general { default_syslog; default_debug; default_log; };

  // Ab BIND 9.12 und neuer kann man die Zonenlastprotokollierung mit der
  // neuen Kategorie "zoneload logging" auf einen anderen Kanal umleiten.
  // Wenn dies als nützlich erachtet wird, muss man zunächst den neuen 
  // Kanal definieren und bearbeitet dann die folgende Zeile, um die 
  // Kategorie dorthin umzuleiten, anstatt sie an syslog und das Standard-
  // protokoll zu senden:
	category zoneload { default_syslog; default_debug; default_log; };

  // Protokollnachrichten, die sich auf das beziehen, was wir während der
  // Rekursion von autoritativen Servern zurückerhalten haben (z.B. wenn
  // Lame-Server und deaktivierte DNS-Server andere Nachrichten verdecken,
  // kann man diese an ihren eigenen Kanal oder an null gesendet werden).
  // Manchmal sind diese Protokollnachrichten nützlich, um zu untersuchen,
  // warum einige Domains nicht oder nicht zuverlässig aufgelöst werden.
	category resolver { auth_servers_log; default_debug; };       
	category cname { auth_servers_log; default_debug; };       
	// category delegation-only { auth_servers_log; default_debug; };
  category lame-servers { auth_servers_log; default_debug; };
	category edns-disabled { auth_servers_log; default_debug; };

  // Protokollieren von Problemen mit DNSSEC:
	category dnssec { dnssec_log; default_debug; };

  // Protokollieren aller Nachrichten, die sich auf die autoritative 
  // Zonen Propagation (Ausbreitung) beziehen.
	category notify { zone_transfers_log; default_debug; };       
	category xfer-in { zone_transfers_log; default_debug; };       
	category xfer-out { zone_transfers_log; default_debug; };

  // Protokollieren aller Nachrichten, die sich auf dynamische Aktualisie-
  // rungen von DNS-Zonendaten beziehen.
	category update{ ddns_log; default_debug; };
	category update-security { ddns_log; default_debug; };

  // Protokollieren aller Nachrichten, die sich auf den Client-Zugriff und
  // die Sicherheit beziehen. (Es gibt eine zusätzliche Kategorie "unmatched",
  // die standardmässig an null gesendet wird, aber hier hinzugefügt werden
  // kann, wenn man mehr als die einzeilige Zusammenfassung wünscht, die für
  // Fehler bei der Zuordnung zu einer Ansicht protokolliert wird).
	category client{ client_security_log; default_debug; };       
	category security { client_security_log; default_debug; };

  // Protokollieren aller Nachrichten, die wahrscheinlich mit der Rate-Limiting
  // zusammenhängen. Dies umfasst RRL (Response Rate Limiting) – wird normaler-
  // weise auf autorisierenden Servern und Abrufen pro Server/Zone eingesetzt.
  // Hierbei ist zu beachten, dass dies nicht die Protokollierung von Änderun-
  // gen für Clients pro Abfrage umfasst (die im Cateory Resolver protokolliert
  // werden). Wichtig ist hier auch, dass gelegentlich andere Protokollnach-
  // richten von der Datenbankkategorie ausgegeben werden können, die sich 
  // nicht auf das Rate-Limiting Verhalten von named beziehen.
	category rate-limit { rate_limiting_log; default_debug; };       
	category spill { rate_limiting_log; default_debug; };       
	category database { rate_limiting_log; default_debug; };

  // Protokollieren von DNS-RPZ-Meldungen (Response Policy Zone), sofern DNS-
  // -RPZ nicht verwendet wird, kann man diese Kategorie und den zugehörigen
  // Kanal auskommentieren.
	category rpz { rpz_log; default_debug; };

  // Protokollnachrichten zum DNS-Verkehrserfassungssystem "dnstap". (Wenn 
  // man dnstap nicht verwenden will, muss man diese Kategorie und den zugehö-
  // rigen Kanal auskommentieren).
	category dnstap { dnstap_log; default_debug; };

  // Sofern mane einen Server betreiben (z. B. einen der Internet-Root-Name-
  // server), der RFC 5011-Vertrauensanker-Updates bereitstellt, dann ist es 
  // unter Umständen von Interesse, die Vertrauensanker-Telemetrieberichte zu 
  // protokollieren, die der Server empfängt, um die Trust Anchor Propagierungs-
  // raten während eines Schlüsselwechsels zu analysieren. 
  // Erachtet man dies als nützlich, konfiguriert man zunächst den neuen Kanal
  // und entfernt dann das Kommentarzeichen und die folgende Zeile, um die 
  // Kategorie dorthin zu leiten, anstatt zu syslog und default log:
  category trust-anchor-telemetry { default_syslog; default_debug; default_log; };

  // Wenn man die Kategorie "queries" definiert hat und standardmäßig keine Ab-
  // frageprotokollierung wünschen, muss man sicherstellen, dass Sie die Option 
  // "querylog no"“ hinzufügt wurde. Anschliessend kann man da die Abfrageproto-
  // kollierung mit dem Befehl "rndc querylog" ein- und wieder ausschalten.
	category queries { queries_log; };

  // Diese Protokollkategorie gibt nur Meldungen auf Debug-Ebene 1 oder höher 
  // aus. Sie kann bei der Fehlerbehebung nützlich sein, wenn Abfragen zu einer 
  // SERVFAIL-Antwort führen.
	category query-errors { query-errors_log; };

};