BIND
Siehe auch
Der Berkeley Internet Name Domain Server (BIND) ist der verbreitetste DNS. Mitte der 80er Jahre erschienen, gilt BIND seit 2007 als DNS-Referenzsoftware. Version 9 erschien im Jahr 2000, seit 2013 ist BIND 10 verfügbar. In RHEL 7 kommt BIND 9.9 zum Einsatz, in RHEL 8 Bind 9.11.
Ein Caching Only Nameserver ist ein nicht-autoritativer Nameserver, der keine eigene Zone (wie beispielsweise example.com) verwaltet. Er muss daher alle eintreffenden DNS-Anfragen über andere Nameserver (Forwarder) auflösen, und speichert das Ergebnis zwecks Caching im lokalen RAM ab. Jeder Cache-Eintrag besitzt ein eigenes Verfallsdatum (TTL, Time To Live), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt.
- Links:
DNS allgemein, schön erklärt: https://calomel.org/unbound_dns.html
Begriffe:
ARPA: Address and Routing Parameter Area
SOA: Start of Authority
Installation
Auf RHEL: Das Paket heisst „bind“, der Service heisst „named“.
yum -y install bind
systemctl enable --now named.service
firewall-cmd --permanent --add-service=dns
firewall-cmd --reload
Wird der named-Server das erste mal gestartet und bleibt mit der Meldung Generating /etc/rndc.key hängen, falls man per SSH eingeloggt ist: Direkt auf die (VM-)Konsole wechseln und dort den ersten Start ausführen. Der Grund liegt in der Erstellung eines starken, kryptographischen Schlüssels für den DNS, für die Zufallsinformationen aus Tastatur- und Maus-Streams bezogen werden - die beim Zugang per SSH fehlen können.
Beispiel-Konfiguration
Standalone-DNS
Konfiguration:
Lokaler DNS, standalone
verwaltet die Forward-Zone example.com
verwaltet die Reverse-Zone 192.0.2.x
bietet nur IPv4
leitet Anfragen ausserhalb seiner Zonen an Cloudflare DNS-Server weiter
versteckt seine Versionsnummer in DNS-Anfragen
Auf RHEL:
OPTIONS=-4
acl "trusted" {
localhost;
localnets;
192.0.2.0/24;
};
options {
allow-query-cache { trusted; };
allow-recursion { trusted; };
allow-transfer { none; };
directory "/var/named";
disable-empty-zone yes;
dnssec-enable no;
dnssec-validation no;
dump-file "/var/named/data/cache_dump.db";
filter-aaaa-on-v4 yes;
forward only;
forwarders {
1.1.1.1;
1.0.0.1;
};
listen-on port 53 { any; };
listen-on-v6 { none; };
managed-keys-directory "/var/named/dynamic";
memstatistics-file "/var/named/data/named_mem_stats.txt";
pid-file "/run/named/named.pid";
recursion yes;
session-keyfile "/run/named/session.key";
statistics-file "/var/named/data/named_stats.txt";
version "Linuxfabrik";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
zone "example.com" IN {
type master;
file "forward.zone";
// do normal iterative resolution (do not forward)
forwarders { };
allow-query { trusted; };
allow-transfer { trusted; };
allow-update { none; };
};
zone "2.0.192.in-addr.arpa" IN {
type master;
file "reverse.zone";
// do normal iterative resolution (do not forward)
forwarders { };
allow-query { trusted; };
allow-transfer { trusted; };
allow-update { none; };
};
$TTL 1H
@ IN SOA infra01.example.com. info@example.com. (
2024041601 ; <SERNO>
1H ; <TIME-TO-REFRESH>
1H ; <TIME-TO-RETRY>
1W ; <TIME-TO-EXPIRE>
1D ) ; <minimum-TTL>
@ IN NS infra01.example.com.
srv01 IN A 192.0.2.2
srv06 IN A 192.0.2.10
srv07 IN A 192.0.2.11
srv08 IN A 192.0.2.12
mail IN CNAME diogenes-ch.mail.protection.outlook.com.
$TTL 1H
@ IN SOA infra01.example.com. info@example.com. (
2024041601 ; <SERNO>
1H ; <TIME-TO-REFRESH>
1H ; <TIME-TO-RETRY>
1W ; <TIME-TO-EXPIRE>
1D ) ; <minimum-TTL>
@ IN NS infra01.example.com.
2 IN PTR srv01.example.com.
10 IN PTR srv06.example.com.
11 IN PTR srv07.example.com.
12 IN PTR srv08.example.com.
Konfiguration prüfen:
named-checkzone example.com /var/named/example.com.zone
named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone
Primary-Secondary mit LFOps
Siehe LFOps linuxfabrik.lfops.bind README.
Ein erfogreicher Transfer der Zonenfiles sieht in den Logs (journalctl -xeu named) so aus:
named[1821615]: client @0x7fbf0c469da0 192.0.2.3#50599 (example.com): transfer of 'example.com/IN': AXFR started (serial 2024091101)
named[1821615]: client @0x7fbf0c469da0 192.0.2.3#50599 (example.com): transfer of 'example.com/IN': AXFR ended
named[1821615]: client @0x7fbf0c43ff00 192.0.2.3#47313 (2.0.192.in-addr.arpa): transfer of '2.0.192.in-addr.arpa/IN': AXFR started (serial 2024091101)
named[1821615]: client @0x7fbf0c43ff00 192.0.2.3#47313 (2.0.192.in-addr.arpa): transfer of '2.0.192.in-addr.arpa/IN': AXFR ended
named[1821615]: client @0x7fbf0c44bb60 192.0.2.3#48433 (rpz): transfer of 'rpz/IN': AXFR started (serial 2024091101)
named[1821615]: client @0x7fbf0c44bb60 192.0.2.3#48433 (rpz): transfer of 'rpz/IN': AXFR ended
systemd[1]: Started Berkeley Internet Name Domain (DNS).
named[145801]: running
named[145801]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
named[145801]: zone example.com/IN: Transfer started.
named[145801]: zone 2.0.192.in-addr.arpa/IN: Transfer started.
named[145801]: zone rpz/IN: zone transfer deferred due to quota
named[145801]: transfer of 'example.com/IN' from 192.0.2.2#53: connected using 192.0.2.3#50599
named[145801]: transfer of '2.0.192.in-addr.arpa/IN' from 192.0.2.2#53: connected using 192.0.2.3#47313
named[145801]: zone example.com/IN: transferred serial 2024091101
named[145801]: zone rpz/IN: Transfer started.
named[145801]: transfer of 'example.com/IN' from 192.0.2.2#53: Transfer status: success
named[145801]: transfer of 'example.com/IN' from 192.0.2.2#53: Transfer completed: 1 messages, 27 records, 816 bytes, 0.001 secs (816000 bytes/sec) (serial 2024091101)
named[145801]: zone example.com/IN: sending notifies (serial 2024091101)
named[145801]: zone 2.0.192.in-addr.arpa/IN: transferred serial 2024091101
named[145801]: transfer of '2.0.192.in-addr.arpa/IN' from 192.0.2.2#53: Transfer status: success
named[145801]: transfer of '2.0.192.in-addr.arpa/IN' from 192.0.2.2#53: Transfer completed: 1 messages, 25 records, 802 bytes, 0.001 secs (802000 bytes/sec) (serial 2024091101)
named[145801]: zone 2.0.192.in-addr.arpa/IN: sending notifies (serial 2024091101)
named[145801]: transfer of 'rpz/IN' from 192.0.2.2#53: connected using 192.0.2.3#48433
named[145801]: zone rpz/IN: transferred serial 2024091101
named[145801]: transfer of 'rpz/IN' from 192.0.2.2#53: Transfer status: success
named[145801]: transfer of 'rpz/IN' from 192.0.2.2#53: Transfer completed: 1 messages, 20 records, 582 bytes, 0.001 secs (582000 bytes/sec) (serial 2024091101)
named[145801]: zone rpz/IN: sending notifies (serial 2024091101)
named[145801]: rpz: rpz: reload start
named[145801]: rpz: rpz: reload done
Hardening
Wer die Versionssnummer des BIND verstecken möchte, verwendet:
options {
version "my-namesrv :-)";
filter-aaaa-on-v4 yes;
....
Wer im Vulnerability-Scanner „Nessus“ das Finding „DNS Server Cache Snooping Remote Information Disclosure“ erhält, muss sich überlegen, ob das Finding nur möglich war, weil der Nessus-Client genau im erlaubten Netzsegment steckt.
Domain Name Service Response Policy Zones
DNS RPZ ermöglicht einem Nameserver-Administrator, ähnlich einer /etc/hosts benutzerdefinierte Antworten über das globale DNS zu legen (BIND 9.8+, auch „DNS-Firewall“ genannt). Hauptmotivation für die Entwicklung war der Wunsch, schnell bösartige Domänennamen, IP-Adressen oder Nameserver überschreiben zu können:
Clients kann so der Zugriff auf bösartige Hosts verwehrt werden.
Kennt man eine fehlerhafte IP-Adresse, kann man Clients den Zugriff auf Hostnamen, die darauf verweisen, verwehren.
Wenn man einen Nameserver kennt, der bösartige Domains verwaltet, kann man den Zugriff auf dessen DNS-Informationen blockieren.
IPv6 Reverse Zone
Reverse Zones für IPv6 sind im Prinzip gleichen wie für IPv4. Allerdings ist die Handhabung aufgrund der langen Adressen etwas mühsamer. Am einfachsten ist es wie folgt, wenn zum Beispiel einen Eintrag für 2001:db8:cafe:f9::d3 auf test.example.com eingerichtet werden muss:
Im Bind eine Zone
ip6.arpaanlegen. Wie bei IPv4 muss die Adresse entsprechend der Subnetzmaske komplett invertiert werden. Aus2001:db8:cafe:f9::/64wird also9.f.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa. Dabei hilft auch das „Full Network“ ausipcalc 2001:db8:cafe:f9::/64.Nun kann per
digherausgefunden werden, wie derPTR-Eintrag aussehen muss:dig -x 2001:db8:cafe:f9::d3 | grep QUESTION -A1 # ;; QUESTION SECTION: # ;3.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.f.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
Nun muss der Teil der Zone von der Adresse entfernt werden. Aus
9.f.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpaund3.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.f.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpaergibt sich also3.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0. Dies kann nun als3.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR test.example.comin der Zone eingetragen werden.
Logging aller Queries
BIND bietet die Möglichkeit, alle Queries zu protokollieren. Dies kann jedoch auf stark ausgelasteten Servern zu einer deutlich höheren Auslastung führen. Es wird daher empfohlen, diese Option nur kurzzeitig für Debugging-Zwecke zu aktivieren:
rndc querylog on
journalctl --follow --pager-end --unit named.service
rndc querylog off
Tipp
„rndc“ steht für Remote Name Daemon Control. rndc ist der Nachfolger von ndc.
Um die Query-Logging dauerhaft zu aktivieren, muss in der Datei /etc/named.conf die Option options {querylog yes;} gesetzt werden. Dabei ist zu beachten, dass die Option nur beim Start von BIND eingelesen wird - also nicht bei einem systemctl reload named.service.
Built on 2025-01-06