Netz - Rettung - Recht (Artikel mit Tag dns)

isc-dhcpd, Windows-7-Clients und kein DHCP?

nospam@example.com (Thomas Hochstein) — Sat, 22 Jan 2011 07:42:00 +0000

Manche Dinge muß man nicht verstehen - und sie sind auch furchtbar schwer einzugrenzen.

Man stelle sich folgende Situation vor:

Ein Netzwerk, in dem ein Server (Debian Squeez) und ein Desktop (WinXP) stehen, außerdem ein WLAN-Accesspoint, über den zwei Laptops (einmal WinXP, einmal Win7) an das Netz angebunden sind. Auf dem Server läuft ein isc-dhcpd, also der DHCP-Server des ISC, der die Clients mit IP-Adressen versorgt. Beide Rechner, die unter Windows XP laufen, bekommen problemlos DHCP-Leases, und alles ist gut.

Jetzt kommt der Rechner unter Windows 7 hinzu - und nichts geht mehr. Nicht nur, daß der Rechner keine IP-Adresse zugewiesen bekommt; auch der andere, über WLAN angebundene Laptop verliert während dieser Versuche, per DHCP eine Adresse zu bekommen, reproduzierbar die Verbindung zum Server, so daß SSH-Verbindungen abbrechen und die DNS-Auflösung nicht mehr funktioniert. Andere bestehende Verbindungen von diesem XP-Laptop aus bleiben aber bestehen. Im Log des DHCP-Servers spielen der Win7-Client und der Server Pingpong mit DHCPDISCOVER und DHCPOFFER, kommen aber nie weiter zu DHCPREQUEST und DHCPACK, d.h. der Client fragt nach einer IP-Adresse, er bekommt eine angeboten, registriert das aber nicht und wiederholt seine Anfrage ad nauseam.

Nach langem Lesen und Probieren wird als Probe aufs Exempel ein weiterer Laptop mit Win7 ins Netz gebracht, um auszuschließen, daß das Problem beim Laptop liegt - und tatsächlich, auch dieser Rechner bekommt per DHCP keine IP-Adresse zugewiesen! Das Problem ist also offenbar ein generelles.

Googeln wird bei diesem Thema dadurch erschwert, daß es haufenweise Treffer gibt, die aber im wesentlichen alle mit diesem Problem nichts zu tun haben und oft nur die Unkenntnis der Beteiligten über DHCP, Windows und diverse andere Gegenstände erkennbar machen. *seufz*

Hätte jemand zu diesem Problem auf Anhieb einen Lösungsansatz gehabt? (Außer dem Mitschneiden des Netzwerkverkehrs zwischen dem Client und dem nicht-funktionsfähigen DHCP-Server im Vergleich zum Verkehr zwischen dem Client und einem funktionierenden Server.)

Die Lösung des Problems fand sich dann am Ende doch via Google (im Archiv einer Mailingliste der Greater New Hampshire Linux User Group) - und hat keine für mich erkennbare Verbindung zum Problem:

Es ist falsch, in der DHCP-Konfiguration das Statement server-identifier auf den Namen des DHCP-Servers zu setzen; dort muß offenbar entweder dessen IP-Adresse oder ein per DNS auflösbarer Hostname stehen (oder am besten gar nichts); den Namen des DHCP-Servers kann man stattdessen mittels server-name setzen. Wenn man diese Änderung in der Konfiguration des dhcpd vornimmt und ihn neu startet, ist urplötzlich alles gut …

Keywords: DHCP isc-dhcpd Windows Seven Vista Win7 fail no lease no IP address problem

DHCP-Server und automatische DNS-Zone-Updates

nospam@example.com (Thomas Hochstein) — Fri, 21 Jan 2011 18:46:00 +0000

Für lokale Netze ist ein DHCP-Server eine nützliche Einrichtung, ermöglicht er doch die automatische Adreßvergabe. Die meisten Consumer-DSL-Router (und nicht nur diese) haben entsprechende Funktionalitäten eingebaut; noch schöner und flexibler ist es aber natürlich, selbst einen entsprechenden Dienst bereitzustellen, weil man ihn dann genau so konfigurieren kann, wie man ihn gerne hätte, um neben der automatischen Vergabe von IP-Adressen auch bestimmten Rechnern feste Adressen zuzuweisen und zugleich im internen Netz eine Namensauflösung zu organisieren.

Dafür bedarf es im Prinzip dreierlei:

Zunächst benötigt man einen DHCP-Server (dhcpd), bspw. den des ISC, der dann so konfiguriert werden muß, daß er die erwünschten Adressen an die Clients zuweist.
Dann benötigt man einen DNS-Server, bspw. den BIND des ISC, der dann so konfiguriert werden muß, daß er Namen im lokalen Netz zu IPs auflöst und umgekehrt lokale IPs zu den richtigen Namen.
Und letztlich muß man in einem zweiten Schritt die beiden so miteinander verheiraten, daß der DHCP-Server dem DNS-Server erzählt, welche IPs er an welche Maschinen dynamisch vergeben hat.

All das ist vergleichsweise einfach unter Debian möglich.

Im folgenden Beispiel gehe ich davon aus, daß das lokale Netz den IP-Bereich von 10.0.0.1-10.0.0.254 (10.0.0.1/24) umfassen soll und die Domain example.org verwendet wird. Der Host, auf dem DHCP- und DNS-Server laufen, heißt server.example.org und hat die (fest konfigurierte) IP-Adresse 10.0.0.1.

1. Installation und Einrichtung des DNS-Servers

aptitude -r install bind9

Die DNS-Zonen für das lokale Netz sollen später dynamische Updates zulassen; aufgrund der dann notwendigen Schreibrechte für den Benutzer bind auf diese Dateien darf man sie unter Debian nicht in /etc/bind/ anlegen, sondern im dafür vorgesehenen Verzeichnis /var/lib/bind. Also legen wir eine Zone-Datei /var/lib/bind/example.org für die Vorwärtsauflösung an, in der auch schon die Maschinen stehen, die feste IP-Adressen vergeben bekommen sollen:

$ORIGIN .
$TTL 604800     ; 1 week
example.org            IN SOA  server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN example.org.
server                  A       10.0.0.1
desktop                 A       10.0.0.11
laptop1                 A       10.0.0.21
laptop2                 A       10.0.0.22

Und dasselbe dann für die Rückwärtsauflösung:

$ORIGIN .
$TTL 604800     ; 1 week
0.0.10.in-addr.arpa            IN SOA  server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN 0.0.10.in-addr.arpa.
1            PTR    server.example.org.
11            PTR    desktop.example.org.
21            PTR    laptop1.example.org.
22            PTR    laptop2.example.org.

Jetzt werden die Zonen in die Nameserver-Konfiguration eingebunden, und zwar durch Anpassen der Datei /etc/bind/named.conf.local:

zone "example.org" {
  type master;
  file "/var/lib/bind/zone.example.org";
};

zone "0.0.10.in-addr.arpa" {
  type master;
  file "/var/lib/bind/zone.10.0.0";
};

Nach einem Reload der Zonen (rndc reload) sollte die Auflösung vor- und rückwärts funktionieren, was man mit host laptop1.example.org und dann mit host 10.0.0.21 testen kann.

2. Installation und Einrichtung des DHCP-Servers

aptitude -r install isc-dhcp-server

Nun ist /etc/dhcp/dhcpd.conf (ggf. nach Sicherung der Originaldatei) anzupassen:

server-name Server;

option domain-name "example.org";
option subnet-mask 255.255.255.0;
option domain-name-servers 10.0.0.1; # der oder die DNS-Server

default-lease-time 86400; # 24 h
max-lease-time 172800;    # 48 h

authoritative;
ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.101 10.0.0.199;          # DHCP-Adressen werden zwischen .101 und .199 vergeben
  option broadcast-address 10.0.0.255;
  option routers 10.0.0.200;            # das Gateway ins Internet, bspw. der DSL-Router
}

Das genügt zunächst einmal; nach einem /etc/init.d/isc-dhcp-server restart sollte der DHCP-Dienst funktionieren und IP-Adressen zwischen 10.0.0.101 und 10.0.0.199 vergeben. Die vergebenen Adressen lassen sich unter /var/lib/dhcp/dhcpd.leases ersehen.

Im Logfile (standardmäßig /var/log/daemon.log) kann man die Vergabe der Leases verfolgen; dort ersieht man auch die MAC-Adressen der Hosts, die sich per DHCP Adressen holen. Mit Hilfe dieser MAC-Adressen kann man dann den Hosts, die feste Adressen per DHCP vergeben erhalten sollen (im Beispiel sind das desktop, laptop1 und laptop2), ebensolche zuweisen. Nehmen wir an, desktop hat die MAC-Adresse 00:30:05:5a:db:a0, dann müßte der entsprechende Eintrag in der /etc/dhcp/dhcpd.conf folgendermaßen lauten:

host desktop {
  hardware ethernet 00:30:05:5a:db:a0;
  fixed-address 10.0.0.11;
}

Nach einem erneuten Restart des DHCP-Servers wird desktop jetzt immer fest diese DHCP-Adresse zugewiesen bekommen.

3. Dynamische Aktualisierung der DNS-Zonen

Der letzte Schritt sorgt jetzt dafür, daß durch den DHCP-Server dynamisch vergebene Adressen (10.0.0.101-199) in den Zonen-Dateien des Nameservers mit dem entsprechenden Namen erfasst werden. Diese Updates kann man entweder durch jedes Programm, das auf dem Server läuft, erlauben, oder kryptographisch absichern. Ich stelle hier ersteres dar.

Die Konfiguration des DNS-Servers in /etc/bind/named.conf.local ist folgendermaßen zu ergänzen:

zone "example.org" {
  type master;
  file "/var/lib/bind/zone.example.org";
  allow-update { localhost; };
};

zone "0.0.10.in-addr.arpa" {
  type master;
  file "/var/lib/bind/zone.10.0.0";
  allow-update { localhost; };
};

Reloaden der Konfiguration nicht vergessen!

Die Konfiguration des DHCP-Servers in /etc/dhcp/dhcpd.conf ist folgendermaßen zu ergänzen:

[...]

ddns-update-style interim;
ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.101 10.0.0.199; # DHCP-Adressen werden zwischen .101 und .199 vergeben
  option broadcast-address 10.0.0.255;
  option routers 10.0.0.200; # das Gateway ins Internet, bspw. der DSL-Router
  ddns-domainname "gast.example.org"

  zone example.org. {
    primary 127.0.0.1;
  }

  zone 0.0.10.in-addr.arpa. {
    primary 127.0.0.1;
  }
}

Restart des DHCP-Servers nicht vergessen!

Nunmehr wird die Maschine, die sich - bspw. - als gastnetbook meldet und eine IP möchtet, bspw. die IP 10.0.0.105 zugewiesen bekommen; in die Nameserver-Zonen werden jetzt entsprechende Einträge für 10.0.0.105 und gastnetbook.gast.example.org vorgenommen. Das erfolgt zunächst in Dateien, die den Namen der jeweiligen Zone plus die Endung “.jnl” (für “Journal”) tragen; regelmäßig werden aber auch die Zonendateien aktualisiert.

Manuelle Änderungen der DNS-Zonen dürfen dann nicht mehr ohne weiteres vorgenommen werden! Zunächst müssen die dynamischen Updates unterbrochen werden, danach kann man Änderungen vornehmen und die dynamischen Updates wieder starten:

rndc freeze example.org
vim /var/lib/bind/zone.example.org
rndc thaw example.org

oder

rndc freeze 0.0.10.in-addr.arpa 
vim /var/lib/bind/zone.10.0.0
rndc thaw 0.0.10.in-addr.arpa

Das .de-Internet steht still, auch wenn DENIC das nicht will

nospam@example.com (Thomas Hochstein) — Thu, 13 May 2010 10:41:00 +0000

Am gestrigen Tage war ein guter Teil des deutschsprachigen Internets nicht erreichbar, weil die Nameserver der DENIC fehlerhaft arbeiteten. Aber was genau war passiert?

Grundlagen des DNS

Zunächst eine - verkürzte und oberflächliche - Einführung in die Grundlagen des Domain Name Systems (DNS).

Allen mit dem Internet verbundenen Rechnern - seien es Web- oder Mailserver oder der heimische Rechner zuhause, mit dem man "online geht" - ist eine numerische IP-Adresse zugewiesen, die auf technischer Ebene genutzt wird, um mit einem dieser Rechner zu kommunizieren. Weil es aber u.a. ausgesprochen unpraktisch ist, sich mehrere Milliarden Nummern zu merken, benutzt man in der Regel nicht die IP-Adresse eines Rechners, sondern einen Namen; dieser Name muß aber von der verwendeten Software wieder in die zugehörige IP-Adresse umgesetzt werden. Zu diesem Zweck kann die zu einem Namen gehörende Adresse bei einem DNS-Server abgefragt werden.

Um die Last der ungezählten Abfragen zu verteilen und die Vielzahl der bestehenden Domains und Rechnernamen handhabbar zu machen, aber auch, um die Verantwortung für Domains delegieren zu können, ist das DNS hierarchisch organisiert. Jeder DNS-Server muß (nur) die festen IP-Adressen der sog. Root-Nameserver kennen; alle weiteren notwendigen Auskünfte erhält er durch rekursive Anfragen bei den jeweils zuständigen Nameservern. Nehmen wir an, es wird die IP-Adresse für den Rechner www.th-h.de gesucht. Ein DNS-Server würde zunächst bei einem der Root-Nameserver nachfragen, wer denn für die Top-Level-Domain ".de" zuständig ist; der Root-Nameserver würde ihn dann an einen der Nameserver der DENIC verweisen. Unser DNS-Server fragt jetzt einen dieser Nameserver, wer denn für "th-h.de" zuständig sein mag, und erhält dann als Antwort die Nameserver meines Providers. Diese wiederum fragt er dann nach "www.th-h.de" und erhält schließlich die korrekte IP-Adresse.

Soweit der grundsätzliche Ablauf. Hinzu kommt, daß Rechner von Endbenutzern üblicherweise diese rekursiven Abfragen nicht selbst vornehmen; ihnen sind vielmehr ein oder mehrere DNS-Server des jeweiligen Providers zugewiesen, denen sie ihre Fragen stellen. Diese DNS-Server übernehmen dann einerseits den Aufwand der rekursiven Abfragen und speichern andererseits die Antworten für eine gewisse Zeit zwischen, um bei neuen Anfragen nach genau diesem Hostnamen ohne erneute Abfrage sofort antworten zu können.

Das gestrige Problem

Üblicherweise ist das DNS ein recht robuster Dienst; auch die DENIC unterhält nicht nur einen, sondern eine Vielzahl von Nameservern, hinter denen zudem teilweise geographisch weit verteilte Serverfarmen stehen. Fällt eine Maschine oder ein ganzer Cluster aus oder ist überlastet, gibt es immer noch genügend Redundanzen. Schlimmstenfalls werden Anfragen nicht oder mit der Fehlermeldung, daß der Nameserver vorübergehend nicht erreichbar ist, beantwortet.

All das schützt aber nicht gegen die Art technischer Pannen, die dem gestrigen Problem zugrunde lag. Aus wohl immer noch nicht geklärter Ursache haben nämlich die meisten der Nameserver der DENIC beim alle zwei Stunden stattfinden Update der Zone für ".de" nur eine unvollständige Kopie geladen, die - alphabetisch sortiert - nur Domains mit den Anfangsbuchstaben A-F (oder Zahlen am Anfang) enthielt. Alle anderen Domains waren daher für diese Nameserver nicht existent. Anfragen wurden daher nicht mit Fehlermeldungen beantwortet, sondern mit der verbindlichen Antwort, die betreffende .de-Domain existiere nicht bzw. sei nicht registriert. Benutzer, die zufällig einen der wenigen intakten Nameserver kontaktierten oder deren Provider die korrekten Angaben noch zwischengespeichert hatten, waren von diesem Problem hingegen nicht betroffen.

Für die betroffenen Benutzer stellte sich als unmittelbare Folge zunächst einmal die Nichterreichbarkeit aller Rechner in den betreffenden Domains dar; Webseiten konnten nicht aufgerufen werden, und auch alle anderen Dienste - E-Mail, Usenet-News, FTP, IRC, SSH etc. pp. - auf Rechnern mit Namen innerhalb dieser Domains waren nicht erreichbar. Dieses Problem bestand nicht nur bis zum korrekten Reload der .de-Zone auf den entsprechenden Nameservern der DENIC, sondern teilweise auch darüber hinaus, weil auch die falschen Antworten "diese Domain gibt es nicht" natürlich zwischengespeichert wurden.

Eine weitere, noch gravierendere und erst auf den zweiten Blick erkennbare Folge betraf den E-Mail-Verkehr. Auch E-Mails an nicht-existente Domains sind nicht zustellbar; sie werden nicht nur - wie beim Ausfall von Nameservern - verzögert und über Stunden oder Tage erneut zuzustellen versucht, sondern gehen sofort als unzustellbar zurück. "Zurück" kann aber auch bedeuten, daß sie an eine E-Mail-Adresse in einer ebenfalls angeblich nicht existenten Domain gesendet werden müßten, mit der Folge, daß auch die Unzustellbarkeitsnachricht nicht versandt werden kann und so weder Empfänger noch Absender dieser E-Mail etwas davon erfahren, daß sie nicht zugestellt werden konnte. Dazu kommt weiter, daß E-Mails mit Absendern in (angeblich) nicht existenten Domains regelmäßig gar nicht erst angenommen werden. Der DNS-Ausfall dürfte also zu nicht unerheblichen Zustellproblemen und ggf. zunächst kaum erkennbaren Mailverlusten geführt haben. Weitere Folgen können sich anschließen, so zum Beispiel die automatische Austragung aus Mailinglisten und Newslettern, weil die Empfängeradresse ja nicht mehr existent ist.

Schließlich kam es zu einem enormen Run auf die Registrierungssysteme der DENIC - schließlich war der größte Teil der .de-Domains ja scheinbar "nicht registriert" (weil nicht im DNS eingetragen).

Update: Die DENIC hat mittlerweile eine ausführliche Erklärung der Hintergründe und Folgen des Ausfalls veröffentlicht.

Update: Inzwischen hat auch Isotopp etwas zum Thema geschrieben.