BIND 9 als Slave für MS DNS

Ein Domain-Name-System mit MS DNS als Master und BIND 9 als Slave ist das Ziel dieser Anleitung. Der Master wird  aufgrund seiner einfachen Handhabung und Konfiguration die Arbeit im geschützten LAN ausführen, den Slave mit Zonentransfers auf dem Laufenden halten. Selbst wird der Master aber keine Transfers ins Internet tätigen. BIND dagegen wird als Fels in der „Internet-Brandung“ stehen, sowie Zonentransfers für die Server des Providers zur Verfügung stellen. Der heterogene Verbund (MS/BIND) wird etabliert um das Beste aus beiden Welten zu bekommen:

1. Die einfache Handhabung des MS DNS
2. Die Robust- und Sicherheit eines gehärteten BIND

MS DNS

Die Administration (und Konfiguration) des DNS Servers von Microsoft besticht durch die Leichtigkeit und eine hohe Fehlertoleranz. Im Gegensatz zur manuellen Konfiguration eines BIND (mit allen Vorteilen) könnte man diese Aufgabe auch an einen zuverlässigen Mitarbeiter oder Freund delegieren. Mit guten Chancen auf Erfolg.

Der MS DNS Server basiert (im Beispiel) auf einer SBS2k8 Installation. Hier liegt ein maßgebender Unterschied zu einer W2k8 Installation, bzw. ein Grund für das Konstrukt. SBS2k8 sieht es nicht vor, den Server mit einem Interface ans Internet anzubinden. Bei der Initialisierung (Wizard gestützt) wird nur ein Netzwerkinterface mit einer IP nach RFC 1918 berücksichtigt. SBS2k8 bietet zudem mehr Dienste an als nur DNS und es ist das Ziel den Server keiner unmittelbaren Bedrohung durch das Internet auszusetzen.  DNS gehört schließlich zu den meist beanspruchten (angegriffenen) Diensten im Netz. Einen Ausfall des gesamten Servers aufgrund eines Angriffs kann in kleinen Infrastrukturen entsprechend schlecht kompensiert werden.

Typen gibt’s

Erste Hürde ist die Wahl des Zonen-Typs. Microsoft verfügt neben Primärer Zone und Sekundärer Zone auch noch über die Active Directory-integrierte Zone. Deren Vorteile liegen in den sehr effizienten Replikationsmechanismen über vorhandene ADS-DNS-Server. Auch Zonentransfers sind außen vor. Darum kümmert sich der Server quasi alleine. Und genau diese Vorteile machen diesen Typ für das geplante Konstrukt unbrauchbar. MS DNS wird zum Primary ohne ADS-Integration und repliziert an den BIND Secondary.

Die Leichtigkeit des Seins?

Nach der Entscheidung für den Typ, ist die erste Primär-Zone mit Hilfe des Wizards schnell angelegt.

1. Rechte Maustaste auf Forward-Lookupzonen und im Kontextmenü Neue Zone … selektieren
2. Primäre Zone auswählen und den Haken bei Zone in Active Directory speichern entfernen
3. Dem Wizard folgen und zunächst einen Zonennamen auswählen (z.B. example.com). Daraus generiert der Server dann die Zonendatei mit dem Namen example.com.dns und legt diese unter %SystemRoot%\system32\dns\ ab.
4. Dynamische Updates nicht zulassen

Damit ist die Grundkonfiguration bereits abgeschlossen.

Was der Wizard hier macht ist das Anlegen der SOA und eines ersten Nameservers. In einem Editor geöffnet sieht die Zone folgendermaßen aus

;
;  Database file example.com.dns for example.com zone.
;      Zone version:  1
;

@                       IN  SOA my-nameserver.example.local. hostmaster.example.local. (
                            1            ; serial number
                            900          ; refresh
                            600          ; retry
                            86400        ; expire
                            3600       ) ; default TTL

;
;  Zone NS records
;

@                       NS    my-nameserver.example.local.

;
;  Zone records
;

Ans Eingemachte

Mit der Fein-Konfiguration des Servers wird die Zone so angepasst das

• alle relevanten Records vorhanden sind
• die Seriennummer dem Format YYYYMMDDNN genügt und
• nur unser Secondary Server Zonentransfers erhält (siehe Abschnitt PUZZLE).

Dazu wird die Zone durch Anklicken mit der rechten Maustaste über den Kontext Eigenschaften editiert. Im Dialog Autoritätsursprung (SOA) wird also als erstes die Seriennummer gesetzt: 2010092400. Dann wird der Primäre Server geändert. Der Eintrag hier soll auf den Nameserver zeigen der die Zone im Internet für Transfers vorhält, nämlich BIND.

Wird das Dialogfenster das erste Mal sollte es nachfolgender Abbildung in etwa entsprechen.

Unter Primärer Server den Namen des BIND eintragen unter dem er vom Internet aus erreichbar ist oder sein wird. Zum Beispiel ns.example.com. Es ist darauf zu achten, dass der korrespondierende A-Record auflösbar ist. Ob der Secondary Server nun tatsächlich diese IP-Adresse hat, oder die IP-Adresse auf den Server via NAT zeigt ist irrelevant.

In hier beschriebenem Beispiel befindet sich der Secondary DNS im gleichen (RFC 1918) Netz wie der Master Server. Aus Sicht des Internets wird er aber über eine IP aus einem öffentlichen C-Netz bedient. Die Network Address Translation kurz NAT und die Zuweisung der IP übernimmt ein Firewall.

In weiteren Schritten wird der Nameserver entfernt (Dialogreiter Nameserver) und die Zonenübertragung zunächst deaktiviert (Dialogreiter Zonenübertragung). Abschließend die Änderungen mit Übernehmen gespeichert.

Jetzt wäre ein guter Zeitpunkt die Zone für die Übertragung zum Secondary vorzubereiten. Dazu wird die Zone mit MX-, A-, CNAME-Einträgen bevölkert.

BIND 9

Nicht auf Sand bauen

BIND füllt Bücher und kann wohl zurecht als eine der Säulen des Internets bezeichnet werden.  Als Basis für die Installation dient u.a. die ausgezeichnete Konfigurationsanleitung von Rob Thomas. Beim Einrichten eines DNS Servers schadet es nicht, auch den anderen verlinkten Anleitungen von Rob Beachtung zu schenken, z.B. die zur Absicherung des IP Stacks.

Wer sich einen Überblick über seine Kernel-Parameter verschaffen möchte, um beispielsweise die Parameter aus dem Tutorial von Rob Thomas mit seinen zu vergleichen, greift einfach zu

sysctl -a

Eventuell auch etwas dedizierter mit

sysctl -a | grep suchstring

Änderungen an dem hier verwendete Ubuntu 10.04 finden zum Großteil durch Anpassungen von /etc/sysctl.conf statt und werden mit

sysctl -p

neu eingelesen.

Zu Tisch

Mit Hilfe des Paketmanagers der Distribution wird das Paket installiert. Debian/Ubuntu Administratoren greifen hier zu apt-get.

apt-get install bind9 bindutils

Wer eine RedHat basierende Distribution einsetzt verwendet stattdessen yum. Nach der Installation wird der Server gestoppt.

service bind9 stop

Ältere Versionen von Ubuntu/Debian verwenden noch /etc/init.d/bind9 {start|stop|...} um die Laufzeit zu manipulieren.

Gehe in das Gefängnis, begib Dich direkt dort hin … BIND einsperren mit chroot()

Auf dem System auf dem BIND zum Einsatz kommt (Ubuntu 10.04 LTS) ist AppArmor am Start. Ob der Einsatz dieses Werkzeugs alleine ausreicht oder nicht steht hier nicht zur Diskussion. Die Konfiguration des Jail beginnt in der Datei /etc/default/bind9 (u.U. auch in /etc/init.d/bind9) mit der Definition der Laufzeitumgebung des Servers. Hier den OPTIONS-Parameter so anpassen, dass er auf „das neue Zuhause“ zeigt.

OPTIONS="-u bind -t /var/lib/named"

Neue Heimat

Bind sträubt sich gegen sein neues Zuhause. Zumindest so lange, bis /var/lib/named neu eingerichtet ist.

mkdir -p /var/lib/named/{etc,dev}
mkdir -p /var/lib/named/var/{cache,run}
mkdir -p /var/lib/named/var/cache/bind
mkdir -p /var/lib/named/var/run/bind/run
mv /etc/bind /var/lib/named/etc/
ln -s /var/lib/named/etc/bind /etc/bind

Devices und Berechtigungen

mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8
chmod 666 /var/lib/named/dev/{null,random}
chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind

Kannst Du schon lesen und schreiben?

Was noch fehlt ist die Anpassung des System Log-Dienstes. Je nach Distribution (und Version) sind Anpassungen am Syslogd oder Rsyslogd vorzunehmen.

Syslogd wird in /etc/default/syslogd angepasst. Der Daemon wird mit ‚-a‚ wie append angewiesen ein weiteres Logdevice zu überwachen. Aus

SYSLOGD=""

wird

SYSLOGD="-a /var/lib/named/dev/log"

Ähnliche Anpassungen sind auch für Rsyslogd notwendig. Hier muss in /etc/rsyslog.d eine neue Datei angelegt, oder eine bestehende manipuliert werden. Auch hier wird der Daemon angehalten einen neuen Socket abzuhören.

$AddUnixListenSocket /var/lib/named/dev/log

AppArmor am Start

Bis zu diesem Punkt funktioniert alles, bis auf den Versuch das System zu starten.

service bind9 start

erzeugt ungefähr folgende Logausgabe.

Sep 17 13:59:08 vm02 named[6648]: loading configuration from '/etc/bind/named.conf'
Sep 17 13:59:08 vm02 named[6648]: none:0: open: /etc/bind/named.conf: permission denied
Sep 17 13:59:08 vm02 named[6648]: loading configuration: permission denied
Sep 17 13:59:08 vm02 named[6648]: exiting (due to fatal error)

Das es sich um das Abwehren des Zugriffs von /usr/sbin/named auf das neue Verzeichnis handelt steht hier nicht. AppArmor wird im Logfile nicht erwähnt. Ein schnelles service apparmor stop mit anschließender Wiederholung des Startbefehls von BIND verdeutlicht dies allerdings. Denn je nach Konfigurationsfortschritt (Anlegen von Zonen und Laufzeitkonfiguration) lässt sich Bind plötzlich starten, oder gibt andere Fehlermeldungen aus.

Update: apparmor_status listet BIND als Profil

[14:22:33] root[tty1]/var/lib/named $ apparmor_status
apparmor module is loaded.
6 profiles are loaded.
6 profiles are in enforce mode.
   /sbin/dhclient3
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/mysqld
   /usr/sbin/named
   /usr/sbin/tcpdump

Soll AppArmor weiterhin seinen Dienst verrichten, dann schafft die Manipulation der Datei /etc/apparmor.d/usr.sbin.named Abhilfe. Durch Einfügen der Zeile

/var/lib/named/** rw,

am Ende der Datei, vor der schließenden geschweiften Klammer ‚}‘ und ein Restart services apparmor restart lösen das Problem.

Weitere Informationen zu AppArmor in 10.04:
https://help.ubuntu.com/10.04/serverguide/C/apparmor.html

Im Reich des Sklaven

Soweit die Absicherung und die Konfiguration. Nachfolgend muss BIND angewiesen werden, die Slave-Zonen anzunehmen und Zonentransfers zu den Servern des Providers zuzulassen.

In der Datei named.conf kann eine neue Datei inkludiert werden.

include "/etc/bind/named.conf.secondary";

Diese Datei nimmt eine View auf, die sich alleine um die Zonen kümmert die im Internet präsent sein sollen.

view "external-in slave" in {

        match-clients { any; };
        recursion no;

        additional-from-auth no;
        additional-from-cache no;

        zone "example.com" in {
                type slave;
                file "/etc/bind/secondary/db.example.com";
                allow-query { any; };
                allow-transfer {
                    providerns;
                    internalns;
                };
                masters { 10.0.0.100;};
        };

        zone "example.de" in {
                type slave;
                file "/etc/bind/secondary/db.example.de";
                allow-query { any; };
                allow-transfer {
                     providerns;
                     internalns;
                };
                masters { 10.0.0.100;};
        };

        // Weitere Zonen könnten hier folgen...

};

Zu beachten gilt es, dass unter allow-transfer { definition; }; zwei Eintragungen sind, die als „acl“ bezeichnet werden. Mit Hilfe einer acl muss man eine bestimmte Berechtigungsgruppe nur einmal definieren und kann dann über alle Konfigurationsdateien immer wieder darauf referenzieren. Diese werden gängiger weise in named.conf.options definiert.

Am Beispiel

acl "internalns" {
        10.0.0.100;
};

masters { ip-address; }; definiert die oder den Master-Server. Es handelt sich dabei um die IP unseres MS-DNS und von hier befüttert sich BIND mit Informationen um die Zones.

PUZZLE

Wie fügt sich jetzt das Bild zusammen?

Nachdem BIND mit service bind9 start gestartet wurde wartet er, mehr oder weniger sehnsüchtig, auf die ersten Transfers. Und hier wird abschließend angesetzt. Zurück in den Eigenschaften der Zone (MS DNS Master) wird bei Zonenübertragung die IP-Adresse des BIND Servers eingetragen.

Mit Benachrichtigen … kann ein erster Zonentransfer initiiert werden, der sich auch im Logfile von Ubuntu wiederfinden oder mit tail -f /var/log/syslog verfolgen lässt.

named[6546]: zone example.com/IN/external-in slave: loaded serial 2010092401
named[6546]: zone example.de/IN/external-in slave: loaded serial 2010092401

Die Seriennummer sollte bereits inkrementiert sein da Eintragungen in der Zone automatisch den Zähler hoch setzen. Anhand der Seriennummer wird überhaupt erst erkannt ob die Zone aktualisiert und damit die DNS Server des Providers benachrichtigt werden müssen.

Hinweis: Firewall um jeden Preis

BIND sieht sich in unserer Konstruktion dem Internet ausgesetzt und handhabt Anfragen für unsere Domäne. Der Server sollte daher hinter einem Firewall stehen (DMZ). Darüber hinaus empfiehlt sich auch der Einsatz eines eigenen Paketfilters auf dem Server.