Denic führt DNSSEC ein: neue Technik mit kleinen Tücken

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.

Themenseiten: Hacker, Kommunikation, Security-Analysen

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

2 Kommentare zu Denic führt DNSSEC ein: neue Technik mit kleinen Tücken

Kommentar hinzufügen
  • Am 31. Januar 2010 um 18:34 von Martin

    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.

  • Am 23. Mai 2011 um 18:41 von Sydney

    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.“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *