Innovation

Domain Name System Security Extension (DNSSEC)

End-to-End-Authentizifierung des Internets

Häufige Fragen zu DNSSEC

Welchen Zweck hat DNSSEC?

DNSSEC schützt die Internet-Community unter Anwendung öffentlicher Schlüsselkryptografie zum digitalen Signieren autoritativer Zonendaten vor gefälschten DNS-Daten. DNSSEC-Validierung garantiert Benutzern, dass die Daten von der angegebenen Quelle stammen und während der Übertragung nicht modifiziert wurden. DNSSEC kann auch nachweisen, dass ein Domainname nicht existiert.

DNSSEC erhöht zwar die DNS-Sicherheit, ist aber keine umfassende Lösung. Es schützt nicht vor Distributed Denial of Service (DDoS)-Angriffen, gewährleistet keine Vertraulichkeit beim Austausch von Daten, verschlüsselt Website-Daten nicht und verhindert auch nicht Spoofing oder Phishing. Andere Schutzmechanismen wie die Vermeidung von DDoS-Angriffen, Sicherheitsaufklärung, Vermeidung von Betrug, Verschlüsselung und Seitenvalidierung über Secure Sockets Layer (SSL) sowie Zwei-Faktor-Authentifizierung sind ebenfalls entscheidend für die Sicherheit im Internet. Diese Mechanismen sollten gemeinsam mit DNSSEC verwendet werden.

Wer profitiert von DNSSEC?

DNSSEC betrifft alle Komponenten innerhalb des Ökosystems der Internet-Infrastruktur. Die effektive Anwendung erfordert die Beteiligung vieler Mitglieder der Internet-Community. Registrys, Registrare, Registranten von Domainnamen, Hardware- und Software-Anbieter, ISPs, Regierungsbehörden und „gewöhnliche“ Internetnutzer sind wichtig für den Erfolg des Systems und die Umsetzung entscheidender Verbesserungen der Internetsicherheit. Vorteile von DNSSEC:

  • Die Internet-Community profitiert von mehr Sicherheit in signierten Zonen.
  • Registrare können ihren Kunden Dienste zum Signieren von Domains anbieten.
  • ISPs können die Sicherheit der an ihre Kunden zurückgegebenen Daten erhöhen.
  • Benutzer sind vor DNS-Schwachstellen wie Cache Poisoning und Man-in-the-middle-Angriffen geschützt.

Wie funktioniert DNSSEC?

Bei DNSSEC hat jede Zone ein öffentliches/privates Schlüsselpaar. Der öffentliche Schlüssel der Zone wird über DNS veröffentlicht, während der private Schlüssel sicher aufbewahrt und idealerweise offline gespeichert wird. Der private Schlüssel einer Zone signiert individuelle DNS-Daten in dieser Zone und erstellt so digitale Signaturen, die auch über DNS veröffentlicht werden. DNSSEC verwendet ein strenges Vertrauensmodell und diese Kette des Vertrauens verläuft von den übergeordneten bis zu den untergeordneten Zonen. Die Zonen der höheren Ebenen (übergeordnete Zonen) signieren – oder bürgen für – die öffentlichen Schlüssel der Zonen der unteren Ebenen (untergeordnete Zonen). Die autoritativen Namensserver für diese Zonen können von Registraren, ISPs, Webhosting-Unternehmen oder Websitebetreibern (Registranten) selbst verwaltet werden.

Wenn ein Endbenutzer auf eine Website zugreifen will, fordert ein Stub-Resolver innerhalb des Betriebssystems des Benutzers den Domainnamen-Eintrag von einem rekursiven Namensserver eines ISPs an. Nachdem der Server diesen Eintrag anfordert, fordert er auch den mit der Zone verknüpften DNSSEC-Schlüssel an. Anhand dieses Schlüssels kann der Server verifizieren, dass die Informationen, die er empfängt, mit dem Eintrag des autoritativen Namensservers identisch sind.

Wenn der rekursive Namensserver bestimmt, dass der Adresseintrag vom autoritativen Namensserver gesendet und bei der Übertragung nicht geändert wurde, löst er den Domainnamen auf und der Benutzer kann auf die Website zugreifen. Dieser Vorgang wird als Validierung bezeichnet. Wenn der Adresseintrag geändert wurde oder nicht von der angegebenen Quelle stammt, verweigert der rekursive Namensserver dem Benutzer den Zugriff auf die betrügerische Adresse. DNSSEC kann auch nachweisen, dass ein Domainname nicht existiert.

Kann DNSSEC umfassende Internetsicherheit bieten?

Umfassende Internetsicherheit setzt sich aus vielen einzelnen Puzzleteilen zusammen. DNSSEC kann die durch Man-in-the-middle-Angriffe und Cache Poisoning verursachten Sicherheitsprobleme mindern, ist aber keine Komplettlösung. DNSSEC bietet keinen Schutz vor einigen der häufigsten Internetbedrohungen wie Spoofing oder Phishing. Daher sind andere Schutzmaßnahmen wie SSL-Zertifikate und Zwei-Faktor-Authentifizierung erforderlich, um eine umfassende Internetsicherheit zu gewährleisten.

Wie wird ein Benutzer über einen Angriff informiert?

Die Internet-Community hat noch kein standardisiertes System entwickelt, um Benutzer über Angriffe zu informieren. Eine mögliche Lösung ist die Entwicklung „DNSSEC-fähiger“ Browser, die Benutzer darüber informieren, dass sie zu einem authentifizierten Ziel geleitet wurden.

Welche Schritte unternimmt Verisign zur Implementierung von DNSSEC?

Im Juli 2010 hat Verisign – zusammen mit der Internet Assigned Numbers Authority (IANA) und dem US-Handelsministerium (DoC) – die Umsetzung von DNSSEC in der Root-Zone abgeschlossen (der Startpunkt in der DNS-Hierarchie). Ebenfalls im Juli hat Verisign in Zusammenarbeit mit EDUCAUSE und dem US-Handelsministerium .edu aktiviert und arbeitet gerade daran, DNSSEC für .net und .com zu aktivieren.

Wie sieht Verisigns Strategie bei der Anwendung von DNSSEC aus?

Unsere Strategie bei der Implementierung von DNSSEC besteht darin, mit den kleineren Zonen zu beginnen und jede Implementierung zu bewerten, bevor wir mit der nächsten Zone fortfahren. Die .com-Zone ist die größte Zone und wird daher als Letztes signiert. Wir möchten so viel Erfahrung wie möglich sammeln, bevor wir uns der Domain zuwenden, über die ein so großer Teil des internetbasierten internationalen Handels und der weltweiten Online-Kommunikation stattfindet.

Was ist nötig, um DNSSEC erfolgreich einzusetzen?

Die erfolgreiche Implementierung von DNSSEC hat zahlreiche Vorteile für die globale Internet-Community, da sie die Sicherheit diverser Aktivitäten im Internet erhöht, wie zum Beispiel E-Commerce, Online-Banking, E-Mail-Kommunikation, VoIP sowie Online-Vertrieb von Software. Es liegt jedoch in der Verantwortung der gesamten Internet-Community, DNSSEC erfolgreich einzusetzen. Der Erfolg erfordert die aktive, koordinierte Teilnahme von Registrys, Registraren, Registranten, Hosting-Unternehmen, Softwareentwicklern, Hardware-Anbietern, Regierung sowie Internettechnologen und Koalitionen.

Wer hat DNSSEC eingeführt oder eingerichtet?

Die Internet-Root-Zone, Top-Level-Domains (TLDs) wie .gov, .org und .museum und eine Reihe von TLDs mit Länderkennzeichen (Country Code Top-Level Domains, ccTLDs) haben die von ihnen verwalteten Zonen signiert. Andere TLDs wie .edu, .net und .com haben DNSSEC im Jahr 2010 implementiert bzw. werden es 2011 implementieren. Diese TLDs akzeptieren demnächst Second-Level-Domainnamen mit DNSSEC-Signierung. Große ISPs wie Comcast haben angekündigt, die Validierung auf den rekursiven Namensservern zu aktivieren, die Benutzeranfragen beantworten, und einige Registrare haben die DNSSEC-Implementierung in ihre Roadmaps integriert. Außerdem hat die Internet Corporation for Assigned Names and Numbers (ICANN) Anwendungen für neue TLDs geöffnet und es ist wahrscheinlich, dass Pläne für die DNSSEC-Implementierung eine Voraussetzung für die Genehmigung einer neuen TLD-Anfrage sein werden.

Benötige ich nach der Einrichtung von DNSSEC noch Secure Sockets Layer (SSL)?

Auch wenn sowohl DNSSEC als auch SSL auf öffentlicher Schlüsselkryptografie angewiesen sind, führen beide sehr unterschiedliche Funktionen aus, die sich ergänzen, anstatt sich zu ersetzen.

Sehr vereinfacht dargestellt geht es bei DNSSEC um das „Wo“ und bei SSL um das „Wer“ und „Wie“.

  • Wo – DNSSEC verwendet digitale Signaturen, um die Integrität von DNS-Daten nachzuweisen und so sicherzustellen, dass Benutzer die gewünschte IP-Adresse erreichen. Der Vorgang ist abgeschlossen, sobald der Benutzer die Adresse erreicht. DNSSEC gewährleistet nicht die Identität der Organisation hinter der Adresse und verschlüsselt keine Interaktionen zwischen Benutzer und Website.
  • Wer – SSL verwendet digitale Zertifikate, um die Identität einer Website zu validieren. Wenn diese Zertifikate von namhaften Zertifizierungsstellen (Certificate Authorities, CAs) ausgestellt wurden, garantiert SSL dem Benutzer die Identität des Inhabers der Website. SSL sorgt jedoch nicht dafür, dass der Benutzer die richtige Seite erreicht, schützt also nicht vor Angriffen, die Benutzer umleiten. Mit anderen Worten: Die Validierung von Websites über SSL ist effektiv – aber nur dann, wenn der Benutzer vorher das richtige Ziel erreicht hat.
  • Wie – SSL verwendet auch digitale Zertifikate zum Verschlüsseln des Datenaustauschs zwischen einem Benutzer und einer Website und schützt so die Vertraulichkeit von Finanztransaktionen, Kommunikationen, E-Commerce und anderen vertraulichen Interaktionen.

Zusammen bieten DNSSEC und SSL mehr Sicherheit und Vertrauen im Internet: Benutzer können auf verlässliche Weise nachprüfen, welche Website sie besuchen, mit wem sie interagieren und dass ihre Transaktionen geschützt sind.

Ist DNSSEC gesetzlich oder durch Branchenstandards vorgeschrieben?

In den USA hat das Office of Management and Budget (OMB)-Memo 08-23 angeordnet, dass DNSSEC im Januar 2009 in der Top-Level-Domain .gov angewendet wird und Bundesbehörden DNSSEC im Dezember 2009 auf externen Seiten aktivieren. Die .gov-Registry wurde Anfang 2009 signiert. Die US-Behörde Defense Information Systems Agency beabsichtigt, OMB DNSSEC-Anforderungen auch bei der .mil-Domain zu erfüllen. Neue Regelungen des Federal Information Security Management Act (FISMA) legen fest, dass Behörden ihre Intranetzonen bis Mitte 2010 mit DNSSEC signieren müssen. Derzeit gibt es keine Vorgaben, nach denen Betreiber öffentlicher Websites ihre Domain über DNSSEC sichern müssen.

Wie hat sich DNSSEC entwickelt?

1994: Veröffentlichung eines ersten potenziellen Standards
1997: Veröffentlichung von RFC 2065 (DNSSEC ist ein IETF-Standard) 

1999: Veröffentlichung von RFC 2535 (DNSSEC-Standard revidiert) 

2005: Gesamte Umformulierung der veröffentlichten Standards 
RFC 4033 (Einführung und Anforderungen) 
RFC 4034 (Neue Ressourceneinträge) 
RFC 4035 (Protokolländerungen) 

Juli 2010: Root-Zone signiert 

Juli 2010: .edu signiert 

Dezember 2010: .net signiert 

Februar 2011: DNSSEC-fähige .gov-Registry auf Verisign umgestellt 

März 2011: .com signiert 

März 2011: Verisigns Managed DNS Service wird um vollen Support fürr DNSSEC-Compliance erweitert 

Januar 2012: Comcast verkündet, dass seine Kunden DNSSEC-validierende Resolver benutzen 

März 2012: Zahl der signierten TLDs steigt auf 90