Vergangenen Freitag ging durch die einschlägigen Medien die Meldung über eine DDOS-Attacke auf InternetX, die einen Ausfall bzw. die Nicht-Erreichbarkeit ihrer Nameserver zur Folge hatte.
Die Nameserver vonInternetX werden z.B. von Schlund genutzt um die Domains ihrer Kunden darauf ‚abzulegen‘.
Auch ich bin ein Kunde von Schlund, alle meine Domains habe ich über das Webinterface ‚gekauft‘ und bisher auch darüber die Nameserver ns9.schlundtech.de und ns10.schlundtech.de ‚konfiguriert‘, sprich meine RR’s dort eingetragen.
Vergangenen Freitag konnte ich meine Domains dann allesamt nicht mehr auflösen. Etwas Recherche brachte zum Vorschein, dass die Nameserver von Schlund zwar wie DENIC vorschreibt in unterschiedlichen ‚Class C-Netzen‘ liegen, aber in einem gemeinsamen AS.
Seit der Einführung von CIDR (im Jahr 1993!) existieren aber diese Netzklassen so nicht mehr.
Wichtig ist spätestens seit dem, dass die Nameserver in unterschiedlichen autonomen Systemen (AS) liegen, da beim Ausfall des Routings zu einem AS dann immer noch der andere Nameserver erreichbar ist.
Nun gut, ich habe mich also am Samstag endlich daran gemacht, meinen eigenen BIND aufzusetzen. Alle Schritte, und die Einstellungen im Schlund-Interface, will ich beispielhaft im Folgenden dokumentieren. Ich konfiguriere einen primären und einen sekundären Nameserver und nutze den ns10 von Schlund als weiteren sekundären Nameserver.
Die 6 Schritte zum eigenen authoritativen Nameserver
- Namen und IP-Adressen der Nameserver in die Zone eintragen (nur die A-Records)
- sekundären BIND aufsetzen
- primären BIND aufsetzen
- Zonefiles schreiben
- Testen ob die Zone beim sekundären Nameserver ankommt
- Schlundtech konfigurieren
Das Szenario für dieses Beispiel
Es gibt zwei Server, 192.0.2.101 und 192.0.2.102, die als primärer und sekundärer Nameserver für die Domain example.org eingerichtet werden sollen. Für dieses Beispiel benutzen wir natürlich reservierte Namen und Adressen.
Namen und IP-Adressen in die Zone eintragen
DNS ist je nach Kofiguration ein recht träges System. Man weiss auch nie, welche Admins ihre Caches nicht im Griff haben, und auch nach Ablauf der TTL noch veraltete Daten ausliefern. Es ist daher immer gut, Änderungen die man später braucht, möglichst früh einzutragen und, wenn möglich, die TTL zu verringern. Auf das Verringern der TTL und ähnliches verzichten wir hier der Einfachheit aber mal, weil das Webinterface von Schlund da ein wenig unübersichtlich ist. Der von Schlund so genannte SOA-Level bleibt auf ‚Empfohlene Einstellungen‘.
Als erstes tragen wir die A-Records für unsere Nameserver ein.
ns01.example.org. IN A 192.0.2.101 ns02.example.org. IN A 192.0.2.102
Bitte bei Bind auf den Punkt am Ende der Namen achten oder die Domain und den Punkt weglassen. Bei Schlund: Entsprechend der vorhandenen Einträge machen – ich glaube ohne Punkt und ohne Domain ist korrekt.
Danach sollte man bei seinem Server-Hoster dafür sorgen, dass das Reverse-Lookup der IP-Adresse die oben angegebenen Namen liefert.
Jetzt können wir gemütlich einen Kaffee trinken gehen…nein, im Ernst, je nachdem wie paranoid man ist sollte man etwas warten, mindestens bis die Zeit für das negative Cachen abgelaufen ist. Da wir aber den ns10 weiter in Betrieb lassen kann es nur zu Verzögerungen beim Auflösen unserer Domain kommen, aber nicht zum Totalausfall, sofern ns10 noch zu erreichen ist.
Den sekundären BIND aufsetzen
Wir gehen davon aus, dass nach einem emerge -av net-dns/bind oder einem apt-get install bind9 der BIND installiert ist.
Die Konfiguration ist eigentlich ganz einfach – leider weichen bei Gentoo und Debian die Pfade ein wenig voneinander ab sowie das Konzept der Konfiguration.
Während bei Gentoo alles in einer Datei steht, teilt Debian die named.conf mittels include-Anweisungen in drei Dateien auf.
Wir gehen beim Sekundären mal von Debian aus…
In der Datei /etc/bind/named.conf müssen wir unter Debian nichts weiter für unser Beispiel einfügen, da diese zwei anderen Dateien inkludiert.
Man kann aber allerdings darüber nachdenken, den rootservern von .com und .net zu verbieten, nicht-registrierte Domains auf Suchseiten umzulenken:
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
In der Datei
named.conf.options
ändern wir am meisten, siehe Komentare in den Zeilen, es sollte selbsterklärend sein. Die folgende Datei ist ‚komplett‘:
acl myown-servers {
127.0.0.1;
# Hinweis: hier alle eigenen Server/Netze eintragen,
# die den Server als normalen DNS benutzen dürfen.
# Kann auch leer sein.
};
acl secondaries {
62.116.163.100; # InternetX/Schlund
62.116.162.121; # InternetX/Schlund
192.0.2.102; # unser sekundärer (dieser host selbst)
127.0.0.1;
};
options {
directory "/var/cache/bind";;
forwarders {
# wenn wir selber auflösen wollen:
192.0.2.14; # erster Nameserver des ISP
192.0.2.15; # zweiter Nameserver des ISP
};
listen-on-v6 { none; }; # wird hier IPv6 aktiviert, müssen
# in den ACLs die Adressen auch in der
# alternativen Schreibweise erscheinen.
listen-on { 127.0.0.1; 192.0.2.102;}; # logisch...
transfer-source 192.0.2.102; # von dieser Adresse
# machen wir Zonentransfers
version "get lost";
allow-transfer {"none";};
allow-recursion {myown-servers;};
notify no;
auth-nxdomain no; # conform to RFC1035
};
Nun folgen noch die Zonendefinitionen in der Datei named.conf.local:
zone "example.org" in{
type slave;
file "slv/example.org.slave";
masters {192.0.2.101;};
};
Danach das slv-Verzeichnis verlinken und eine leere Datei anlegen, in die bind schreiben darf:
# cd /etc/bind # ln -s /var/cache/bind/slv slv # touch slv/example.org.slave # chown bind:bind slv/example.org.slave
Das slv-Verzeichnis habe ich angelegt, um nicht immer überlegen zu müssen, ob ich auf meinem Debian oder meinem Gentoo-Server eingeloggt bin.
Damit ist der Sekundäre Nameserver Einsatzbereit und kann so bleiben. Wir laden die Zone nicht neu, das erledigt der Server nachher hoffentlich von alleine, wenn er das Notify von unserem primären Nameserver erhält.
Bei Hosts mit mehr als einer IP-Adresse sind die Quelladressen anzugeben, weil der primäre Nameserver sonst u.U. keine Zonentransfers erlaubt.
primären BIND aufsetzen
Mein primärer Nameserver läuft auf einem aktellen Gentoo, daher hier ein leicht anderer Ansatz, wir schreiben alles in eine Datei und müssen den Symlink für das slv-Verzeichnis nicht anlegen.
Nach einem emerge -av net-dns/bind editieren wir die
/etc/bind/named.conf:
ACHTUNG: In der Originaldatei sind schon einige Zonen definiert, diese bleiben erhalten, ausserdem hat dieser Server nur eine IP-Adresse, daher müssen wir die Anaben zu den Quelladressen wie bei unserem Secondary oben nicht machen. In der folgenden Konfiguration sind nur Änderungen und Erweiterungen zur Originalversion der Datei aufgeführt:
acl myown-servers {
127.0.0.1;
...; #hier also wieder alle unseren server
};
acl secondaries {
62.116.163.100; # InternetX/Schlund
62.116.162.121; # InternetX/Schlund
192.0.2.102; # unser sekundärer
127.0.0.1;
};
options {
directory "/var/bind";
// uncomment the following lines to turn on DNS forwarding,
// and change the forwarding ip address(es) :
forward first;
forwarders {
DNS1; # erster DNS unseres ISP
DNS2; # zweiter DNS unseres ISP
};
listen-on-v6 { none; };
listen-on { 127.0.0.1; 192.0.2.101;};
pid-file "/var/run/named/named.pid";
max-journal-size 50k;
version "get lost";
allow-transfer {"none";};
allow-recursion {myown-servers;};
};
zone "COM" { type delegation-only; };
zone "NET" { type delegation-only; };
zone "example.org" IN {
type master;
file "pri/example.org.zone";
allow-transfer { secondaries; };
notify yes; #bei Änderungen die secundaries informieren
};
Wir haben die Konfiguration des Dienstes geschafft, nun müssen wir ihm noch die Daten geben, die er verteilen soll.
Zonefiles schreiben
Jetzt kommt der unangenehmste Teil der Arbeit, das manuelle Kopieren aller Einträge aus dem Schlund-Webinterface in eine Zonendatei.
Das wichtigste zuerst: Bei jeder Änderung der Zone muss die serial hochgezählt werden, sonst wird die Zone nicht auf die sekundären Server kopiert. Ausserdem muss das Retry-Interval größer als 30 Minuten sein, sonst nimmt Schlund die Zone nicht an. Und immer auf die Punkte am Ende der Hostnamen achten, ohne Punkt wird die Domain eingesetzt!
Wir legen nun im Unterverzeichnis pri das Zonenfile pri/example.org.zone an:
$ORIGIN example.org.
$TTL 2d ; 172800 secs default TTL for zone
@ IN SOA ns01.example.org. hostmaster.example.org. (
2008112601 ; se = serial number
12h ; ref = refresh
35m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns01.example.org.
IN NS ns10.schlundtech.de.
IN NS ns02.example.org.
IN TXT "v=spf1 a mx ?all"
IN MX 10 mail1.example.org.
IN MX 20 mail2.example.org.
IN A 192.0.2.100
ns01 IN A 192.0.2.101
ns02 IN A 192.0.2.102
www IN CNAME example.org.
Das ORIGIN der ersten Zeile definiert für den Rest der Datei, welche Domain wir da eigentlich vor uns haben. Ab der dritten Zeile findet sich der SOA-Eintrag, in dem der primäre Nameserver angegeben ist und eine Emailadresse des zuständigen Admins. Hier: hostmaster@example.org, das @ wird durch einen Punkt ersetzt. Es folgt die serial number, die bei jeder Änderung erhöht werden muß. Es empfiehlt sich das Datum und einen Zähler mit der Zahl der Änderung an diesem Tag zu nutzen. Die serial darf kein Zeichen länger sein, da sie sonst von Bind nicht angenommen wird.
Es folgen dann eine ganze Reihe von Timeouts und Intervallen, das Beispiel passt schon so…
Weiter unten in der Zone sind die Nameserver der Domain angegeben. Das ist wichtig. Bei uns stehen die Nameserver sogar noch in derselben Domain, für die sie auch zuständig sind. Daher müssen wir nachher in das Webinterface bei Schlund noch zusätzlich die IP-Adressen der Server angeben.
In dieser Zone sind auch gleich Beispiele für einen SPF-Record, Nameserver und einen CNAME für den WWW-Host, der auf den A-Record der Domain zeigt.
Wir können nun den bind auch beim Systemstart hochfahren lassen und starten:
# rc-update add named default # /etc/init.d/named start
Damit sollte der primäre Nameserver fertig sein
Testen ob die Zone beim sekundären Nameserver ankommt
Wir loggen uns nun wieder bei unserem eben konfigurierten Sekundären Nameserver ein und schauen nach, ob die Zonendatei nun Daten enthält.
Wenn alles gut gegangen ist, hat der primäre Nameserver beim Starten unseren Secondaries ein Notify geschickt und sie zu einem Zonentransfer animiert. Der Server von Schlund ignoriert das Notify, da er unseren primären Nameserver ja noch nicht kennt.
Sollte die Zone noch leer sein, kann man vom sekundäen Server aus mit dem Utility dig mal einen Zonentransfer versuchen und dabei die Logausgaben des primären Nameservers anschauen.
dig axfr example.org @ns01.example.org
Hat man mehrere IP-Adressen hilft -b IP weiter.
Bei Änderungen an den Zonen muß der BIND nicht neu gestartet werden. Das Kommando rndc hilft weiter:
rndc reload
Schlundtech konfigurieren
Nachdem man die eigenen Server konfiguriert hat und alles funktioniert(!), kann man sich an das Webinterface von Schlund wagen.
Als Einrichtungsart unter ‚DNS-Einstellungen und Weiterleitungen‘ wählt man ’nur zweiter Nameserver‘ und auf dem ersten Registerblatt ‚Domain-Einstellungen‘ gibt man bei den Nameservern ein:
ns01.example.org 192.0.2.101 ns10.schlundtech.de ns02.example.org 192.0.2.102
Bei Nameservern, die in der Domain liegen, die sie auch verwalten, ist die Angabe der IP-Adresse essentiell!
Sobald man auf ‚Domain aktualisieren‘ klickt, sollte ein Zonentransfer vom primären DNS starten…
Um Fehlermeldungen zu lesen, die beim Zonentransfer auftreten können, muss man sich vom Webinterface abmelden, neu anmelden und auf der Startseite in der History klicken.
Der ns10 von Schlund erlaubt übrigens wohl gar keine Transfers.
Wenn alles gut geganten ist, kann man im whois seine Nameserver bewundern und bei einem dig nach den Nameservern der Domain die Additional-Records sehen, welche die IP-Adressen enthalten. Man sollte beim dig natürlich einen Nameserver vom ISP nehmen, nicht seinen eigenen, der funktioniert ja 😉
$ dig ns example.org [...] ;; ANSWER SECTION: example.org. 34422 IN NS ns01.example.org. example.org. 34422 IN NS ns02.example.org. example.org. 34422 IN NS ns10.schlundtech.de. ;; ADDITIONAL SECTION: ns01.example.org. 34265 IN A 192.0.2.101 ns02.example.org. 34265 IN A 192.0.2.102 ns10.schlundtech.de. 2167 IN A 62.116.163.100
Bei allem Debugging mit AS’en und Nameservern, etc, ist die Webseite von robtex sehr praktisch, da sie Graphen für AS-Zuordnungen und DNS-Einträge zeichnen kann.