Abhilfe ist im Prinzip nicht schwer. Anstelle den NAT-Router als DNS-Server zu verwenden, wie es meist der Fall ist, wenn man seine Rechner vom Router per DHCP konfigurieren lässt, trägt man die DNS-Server des Providers, freie DNS-Server oder die DNS-Server von Google ein, siehe Bild 4.
Endanwender, die von der neuen Sicherheit bei DNS profitieren möchten, müssen zunächst enttäuscht werden. Um den eigenen Rechner sicher zu machen, muss man einen Resolver-Mechanismus auf seinem Rechner installieren, der DNSSEC unterstützt. Das ist nicht grundsätzlich unmöglich, jedoch mit Schwierigkeiten verbunden.
Windows hat einen DNS-Client, der die Namensauflösung vornimmt und in der Lage ist, DNS-Antworten zu cachen. Er unterstützt kein DNSSEC. Unix-Betriebssysteme wie Linux und Mac OS können von Haus aus noch weniger. Sie befragen grundsätzlich bei jeder Namensauflösung einfach die konfigurierten DNS-Server in der Datei /etc/resolv.conf. Wer lokales Caching haben möchte, muss ein Programm wie nscd installieren, das bei vielen Linux-Distributionen mitgeliefert wird.
Um DNSSEC auf dem eigenen Rechner zu installieren, kommt man bei allen Betriebssystem nicht umhin, einen DNSSEC-fähigen DNS-Server aufzusetzen, der zunächst als Caching-Only-Server konfiguriert wird. Eine Anleitung gibt der ZDNet-Artikel Sperre von freien DNS-Servern: So umgeht man die Blockade.
Bevor man sich diese Mühe macht, sollte man jedoch wissen, dass eine lokale Installation von DNSSEC erst sinnvoll ist, wenn DNSSEC durchgängig in allen Domainhierarchien verfügbar ist. Generell wird für jede DNS-Zone ein öffentlicher Schlüssel benötigt. Diesen darf man sich jedoch nicht per DNS holen, weil eine gefälschte DNS-Antwort auch einen gefälschten Schlüssel beinhalten kann. Der Schlüssel muss daher auf einem anderen Übertragungsweg kommen, etwa über eine HTTPS-Verbindung.
Das bedeutet, dass man sich für jede Domain einen Schlüssel beschaffen und in seine DNS-Serverkonfiguration eintragen muss. Das ist praktisch nicht durchführbar. Daher lassen sich die sogenannten Zone Signing Keys (ZSKs) mittels Key Signing Keys (KSK) verketten. Im Idealfall reicht es aus, als „Trust Anchor“ nur den KSK der Root-Zone zu konfigurieren.
Derzeit gibt es jedoch nur „DNSSEC-Inseln“. Das bedeutet, dass man die KSKs jeder Inselhierarchie in seiner DNS-Konfiguration pflegen muss. Dazu ist es auch erforderlich, gelegentliche Schlüsselwechsel zu berücksichtigen und seine Konfiguration upzudaten.
Endanwender können von DNSSEC derzeit nur profitieren, wenn die DNS-Server des Providers DNSSEC unterstützen. Wer nicht die Server seines Providers einsetzt, ist DNS-Cache-Angriffen genauso ausgesetzt wie DNS-Server-Betreiber. Die Provider können in ihrem eigenen Netz sicherstellen, dass IP-Adressen aus dem eigenen Adressraum nicht von außen akzeptiert werden. Kommt ein gespooftes Paket, jedoch von einem fremden DNS-Server, etwa 8.8.8.8, hat der Provider keine Möglichkeit festzustellen, ob das Paket wirklich vom Google-DNS-Server kommt.
Neueste Kommentare
2 Kommentare zu Denic führt DNSSEC ein: neue Technik mit kleinen Tücken
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
DNSSEC & LANCON
„Für DNSSEC ist DNS über TCP nicht zwingend erforderlich, solange alle Beteiligten
mit UDP-Paketen umgehen können, die größer als 512 Bytes sind… Dafür gibt es
EDNS (RFC 2671) über das dem Empfänger mitgeteilt wird, wie groß Die DNS-
Anfrage wirklich ist und wie viel Puffer er zur Verfügung stellen muß.
DNSSEC-fähige Server und Resolver *müssen* EDNS unterstützen – siehe auch
http://en.wikipedia.org/wiki/DNSSEC .
Daher ist es nicht nötig eine Auflösung über TCP zu unterstützen – und schon gar
nicht als Forwarder, der einfach nur Anfragen an den DNS-Server des Providers
weiterleitet… Nun gibt es da das Problem, daß viele Forwarder in Routern nicht
mit Anfragen umgehen können, die länger als 512 Bytes sind. Ich kann dazu nur
sagen, daß das LANCOM davon nicht betroffen ist – es forwarded Anfragen bis
zur Maximalgöße von 64K.“
Denic und DNSSEC
Vielen Dank für Ihren lesenwerten und gut recherchierten Artikel!
Was Denic in dieser Sache jedoch veranstaltet, ist unterirdisch! So wird auf http://www.denic.de/denic-im-dialog/pressemitteilungen/pressemitteilungen/2464.html im dritten Absatz vom „DNSSEC-Testbed für Deutschland“ gesprochen, und Denic als die deutsche Registry sollte für alle Deutschen und Computer zuständig sein, aber in der Resolver-Konfigurationsseite http://www.denic.de/domains/dnssec/status/resolver-konfiguration.html wird Windows – und damit ca. 90 % der Computerbenutzer – ausgeschlossen!
Einem kompetenten Umternehmen in Frankfurt’s Kaiserstraße sollte bekannt sein, dass Windows seit Vista und Server 2008 natürlich auch DNSEC unterstützen.