Domain Name System Security Extensions - Versionsgeschichte

Alex Writer WEH: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-04-06T11:23:40Z

Linkvorschlag-Funktion: 2 Links hinzugefügt.

← Nächstältere Version		Version vom 6. April 2025, 13:23 Uhr
Zeile 14:		Zeile 14:
	== Funktionsweise ==		== Funktionsweise ==

	Informationen werden bei DNS in [[Resource Record]]s (RR) bereitgestellt. DNSSEC sichert die [[Authentizität#Informatik\|Authentizität]] dieser Informationen durch eine [[digitale Signatur]] ab. Besitzer einer DNS-Information ist derjenige Master-Server, der für die [[Zone (DNS)\|Zone]], in der die Information liegt, autoritativ ist. Für jede abzusichernde Zone wird ein eigener ''Zonenschlüssel'' (engl.: ''zone signing key'') (ein Paar, bestehend aus öffentlichem und privatem Schlüssel) generiert. Der öffentliche Teil des Zonenschlüssels wird als [[DNSKEY Resource Record]] in die Zonendatei aufgenommen. Mit dem privaten Schlüssel wird jeder einzelne RR dieser Zone digital unterschrieben. Dazu wird ein neuer RR-Typ bereitgestellt, der [[RRSIG Resource Record]], der die Signatur zum zugehörenden DNS-Eintrag enthält. Beispiel eines signierten A-Records:		Informationen werden bei DNS in [[Resource Record]]s (RR) bereitgestellt. DNSSEC sichert die [[Authentizität#Informatik\|Authentizität]] dieser Informationen durch eine [[digitale Signatur]] ab. Besitzer einer DNS-Information ist derjenige Master-Server, der für die [[Zone (DNS)\|Zone]], in der die Information liegt, autoritativ ist. Für jede abzusichernde Zone wird ein eigener ''Zonenschlüssel'' (engl.: ''zone signing key'') (ein Paar, bestehend aus öffentlichem und privatem Schlüssel) generiert. Der öffentliche Teil des Zonenschlüssels wird als [[DNSKEY Resource Record]] in die [[Zonendatei]] aufgenommen. Mit dem privaten Schlüssel wird jeder einzelne RR dieser Zone digital unterschrieben. Dazu wird ein neuer RR-Typ bereitgestellt, der [[RRSIG Resource Record]], der die Signatur zum zugehörenden DNS-Eintrag enthält. Beispiel eines signierten A-Records:

	nsf.example.org. A 172.27.182.17		nsf.example.org. A 172.27.182.17
Zeile 53:		Zeile 53:
	QoBh4eGjbW49Yw== )		QoBh4eGjbW49Yw== )

	Die Verkettung aller Records einer Zone ermöglicht es, den gesamten Inhalt per [[Zone Walking]] iterativ auszulesen. Damit werden einem Angreifer unter Umständen sicherheitsrelevante oder vertrauliche Informationen offenbart, etwa eine Liste aller Kundendomains. Im März 2008 wurde mit RFC5155 der [[NSEC3 Resource Record\|NSEC3-Eintrag]] definiert, der anstelle von Klartext-Domainnamen die Hash-Werte von Domainnamen zurückliefert und so das Zone Walking erschwert. Ein Angreifer muss einen rechenaufwändigen Wörterbuchangriff durchführen, um aus den Hash-Werten die Domainnamen zu erhalten. Um dies weiter zu erschweren, ist eine wiederholte Anwendung der Hash-Funktion vorgesehen, sowie der Einsatz von [[Salt (Kryptologie)\|Salt]]. BIND unterstützt NSEC3 ab Version 9.6 und NSD ab Version 3.1.		Die Verkettung aller Records einer Zone ermöglicht es, den gesamten Inhalt per [[Zone Walking]] iterativ auszulesen. Damit werden einem Angreifer unter Umständen sicherheitsrelevante oder vertrauliche Informationen offenbart, etwa eine Liste aller Kundendomains. Im März 2008 wurde mit RFC5155 der [[NSEC3 Resource Record\|NSEC3-Eintrag]] definiert, der anstelle von Klartext-Domainnamen die Hash-Werte von Domainnamen zurückliefert und so das Zone Walking erschwert. Ein Angreifer muss einen rechenaufwändigen Wörterbuchangriff durchführen, um aus den Hash-Werten die Domainnamen zu erhalten. Um dies weiter zu erschweren, ist eine wiederholte Anwendung der Hash-Funktion vorgesehen, sowie der Einsatz von [[Salt (Kryptologie)\|Salt]]. [[BIND]] unterstützt NSEC3 ab Version 9.6 und NSD ab Version 3.1.

	== Chain of Trust ==		== Chain of Trust ==

Matthäus Wander: /* Siehe auch */ im Abschnitt #Grenzen von DNSSEC und verwandte Protokolle eingearbeitet

2024-12-28T14:50:29Z

Siehe auch: im Abschnitt #Grenzen von DNSSEC und verwandte Protokolle eingearbeitet

← Nächstältere Version		Version vom 28. Dezember 2024, 16:50 Uhr
Zeile 121:		Zeile 121:
	== Verwaltung des Rootzonenschlüssels ==		== Verwaltung des Rootzonenschlüssels ==
	Momentan findet die Verwaltung des DNSSEC-Schlüssels für die [[Root-Nameserver\|Root-Zone]] ausschließlich an zwei US-Standorten statt. Nach Ansicht vieler [[Réseaux IP Européens\|RIPE]]-Experten ist ein Standort außerhalb der USA unabdingbar.<ref>[https://www.heise.de/newsticker/meldung/DNSSEC-auf-allen-Rootservern-994626.html ''DNSSEC auf allen Rootservern''.] Heise News, 6. Mai 2010</ref> Kritiker werfen der [[Internet Corporation for Assigned Names and Numbers\|ICANN]] vor, durch die DNSSEC-Schlüsselverwaltung in den USA die Unabhängigkeit des Internets zu gefährden.<ref name="ct-machtfrage">[https://www.heise.de/ct/artikel/Machtfrage-926625.html ''Machtfrage – Wer kontrolliert das Internet?''] In: ''[[c’t]]'', 5/2010.</ref> Als Signierungspartner hatte die ICANN ausschließlich die amerikanische Firma Verisign vorgesehen.<ref>[https://www.heise.de/netze/meldung/IGF-Politische-und-technische-Probleme-bei-DNSSEC-195755.html ''IGF: Politische und technische Probleme bei DNSSEC''.] Heise News, 14. November 2007</ref> Das US-amerikanische [[Ministerium für Innere Sicherheit der Vereinigten Staaten\|Department of Homeland Security]] forderte im Jahr 2007, die Schlüsselverwaltung vollständig in die Hände der US-Regierung zu legen.<ref>[https://www.heise.de/netze/meldung/Department-of-Homeland-Security-will-den-Masterschluessel-fuers-DNS-163379.html ''Department of Homeland Security will den Masterschlüssel fürs DNS''.] Heise News, 29. März 2007</ref> Diskutiert wurde auch, alternativ die ICANN-Untergruppe [[Internet Assigned Numbers Authority]] (IANA) mit der Verwaltung des Root-Schlüssels zu beauftragen. Die US-Regierung untersagte zunächst die Veröffentlichung eines entsprechenden ICANN-Vorschlags.<ref>[https://www.heise.de/security/meldung/VeriSign-will-DNSSEC-Schluessel-ein-bisschen-teilen-209481.html ''VeriSign will DNSSEC-Schlüssel (ein bisschen) teilen''.] Heise News, 3. Oktober 2008</ref> Die ICANN ist formal unabhängig, die US-Regierung behielt sich jedoch bis September 2016<ref>{{Internetquelle \|autor=Monika Ermert \|url=http://www.ip-watch.org/2016/10/01/last-formal-tie-to-historic-us-internet-control-is-cut/ \|titel=Last Formal Tie To Historic US Internet Control Is Cut \|werk=Intellectual Property Watch \|hrsg= \|datum=2016-10-01 \|abruf=2016-11-28}}</ref> die Aufsicht vor.		Momentan findet die Verwaltung des DNSSEC-Schlüssels für die [[Root-Nameserver\|Root-Zone]] ausschließlich an zwei US-Standorten statt. Nach Ansicht vieler [[Réseaux IP Européens\|RIPE]]-Experten ist ein Standort außerhalb der USA unabdingbar.<ref>[https://www.heise.de/newsticker/meldung/DNSSEC-auf-allen-Rootservern-994626.html ''DNSSEC auf allen Rootservern''.] Heise News, 6. Mai 2010</ref> Kritiker werfen der [[Internet Corporation for Assigned Names and Numbers\|ICANN]] vor, durch die DNSSEC-Schlüsselverwaltung in den USA die Unabhängigkeit des Internets zu gefährden.<ref name="ct-machtfrage">[https://www.heise.de/ct/artikel/Machtfrage-926625.html ''Machtfrage – Wer kontrolliert das Internet?''] In: ''[[c’t]]'', 5/2010.</ref> Als Signierungspartner hatte die ICANN ausschließlich die amerikanische Firma Verisign vorgesehen.<ref>[https://www.heise.de/netze/meldung/IGF-Politische-und-technische-Probleme-bei-DNSSEC-195755.html ''IGF: Politische und technische Probleme bei DNSSEC''.] Heise News, 14. November 2007</ref> Das US-amerikanische [[Ministerium für Innere Sicherheit der Vereinigten Staaten\|Department of Homeland Security]] forderte im Jahr 2007, die Schlüsselverwaltung vollständig in die Hände der US-Regierung zu legen.<ref>[https://www.heise.de/netze/meldung/Department-of-Homeland-Security-will-den-Masterschluessel-fuers-DNS-163379.html ''Department of Homeland Security will den Masterschlüssel fürs DNS''.] Heise News, 29. März 2007</ref> Diskutiert wurde auch, alternativ die ICANN-Untergruppe [[Internet Assigned Numbers Authority]] (IANA) mit der Verwaltung des Root-Schlüssels zu beauftragen. Die US-Regierung untersagte zunächst die Veröffentlichung eines entsprechenden ICANN-Vorschlags.<ref>[https://www.heise.de/security/meldung/VeriSign-will-DNSSEC-Schluessel-ein-bisschen-teilen-209481.html ''VeriSign will DNSSEC-Schlüssel (ein bisschen) teilen''.] Heise News, 3. Oktober 2008</ref> Die ICANN ist formal unabhängig, die US-Regierung behielt sich jedoch bis September 2016<ref>{{Internetquelle \|autor=Monika Ermert \|url=http://www.ip-watch.org/2016/10/01/last-formal-tie-to-historic-us-internet-control-is-cut/ \|titel=Last Formal Tie To Historic US Internet Control Is Cut \|werk=Intellectual Property Watch \|hrsg= \|datum=2016-10-01 \|abruf=2016-11-28}}</ref> die Aufsicht vor.

	== Siehe auch ==
	* [[DNS over TLS]]
	* [[DNS over HTTPS]]
	* [[DNSCurve]]
	* [[DNS-based Authentication of Named Entities]] (DANE)

	== Literatur ==		== Literatur ==

Matthäus Wander: /* Grenzen von DNSSEC */ Ergänzungen

2024-12-28T14:50:07Z

Grenzen von DNSSEC: Ergänzungen

← Nächstältere Version		Version vom 28. Dezember 2024, 16:50 Uhr
Zeile 102:		Zeile 102:
	* Um eine deutsche Domain per DNSSEC abzusichern, wird in der de.-Zone neben dem üblichen Delegations-Record (NS) wiederum ein DS-Record mit dem hash des ''key signing key'' der Domain erstellt. Ein Resolver kann nun wiederum die Echtheit des Zonenschlüssels der Domain erkennen, da der DNSKEY-Record, der den Zonenschlüssel enthält, von einem Schlüssel signiert wurde (RRSIG!), dessen Hash bei der [[DENIC]] liegt.		* Um eine deutsche Domain per DNSSEC abzusichern, wird in der de.-Zone neben dem üblichen Delegations-Record (NS) wiederum ein DS-Record mit dem hash des ''key signing key'' der Domain erstellt. Ein Resolver kann nun wiederum die Echtheit des Zonenschlüssels der Domain erkennen, da der DNSKEY-Record, der den Zonenschlüssel enthält, von einem Schlüssel signiert wurde (RRSIG!), dessen Hash bei der [[DENIC]] liegt.

	== Grenzen von DNSSEC ==		== Grenzen von DNSSEC und verwandte Protokolle ==

			Durch DNSSEC wird lediglich die Namensauflösung gesichert, nicht jedoch die darauf meist folgende Datenübertragung mit einem Anwendungsprotokoll wie beispielsweise dem [[Hypertext Transfer Protocol]] (HTTP) oder [[Simple Mail Transfer Protocol]] (SMTP). Zur Absicherung der eigentlichen Datenübertragung ist der Einsatz von verschlüsselnden Übertragungsprotokollen wie [[Transport Layer Security]] (TLS) oder [[Secure Shell]] (SSH) notwendig.
⚫	~~Durch DNSSEC werden lediglich die Nameserverabfragen gesichert. Dies ist hauptsächlich in Verbindung mit verschlüsselnden Übertragungsprotokollen wie [[Transport Layer Security\|TLS]] sinnvoll.~~ Die Kombination aus DNSSEC mit TLS hat aber noch Schwachstellen. Korruptes Routing könnte beispielsweise Pakete, die an eine mit DNSSEC korrekt ermittelte Ziel-IP-Adresse gesendet werden, an einen falschen Rechner zustellen. Kann sich dieser Rechner durch ein kompromittiertes oder versehentlich ausgestelltes Zertifikat ausweisen, fällt dies nicht auf. An dieser Stelle setzt ~~zum Beispiel~~ [[DNS-based Authentication of Named Entities~~\|DANE~~]] an, um das Zusammenspiel zwischen DNSSEC und TLS zu sichern.

		⚫	Die Kombination aus DNSSEC mit TLS hat aber noch Schwachstellen. Korruptes [[Routing]] könnte beispielsweise Pakete, die an eine mit DNSSEC korrekt ermittelte Ziel-IP-Adresse gesendet werden, an einen falschen Rechner zustellen. Kann sich dieser Rechner durch ein kompromittiertes oder versehentlich ausgestelltes [[digitales Zertifikat]] ausweisen, fällt dies nicht auf. Eine andere Angriffsform wäre beispielsweise durch einen [[Downgrade-Angriff]] die Verwendung von TLS komplett zu umgehen. An dieser Stelle setzt [[DNS-based Authentication of Named Entities]] (DANE) an, um das Zusammenspiel zwischen DNSSEC und TLS zu sichern. Mit einem [[TLSA Resource Record]] kann eine Domain signalisieren, dass für eine bestimmte Anwendung TLS verwendet werden muss. Zusätzlich ist eine Bindung an ein bestimmtes Zertifikat oder eine bestimmte [[Zertifizierungsstelle (Digitale Zertifikate)\|Zertifizierungsstelle]] möglich.

			DNSSEC schützt die Integrität der Namensauflösung Ende-zu-Ende zwischen Domain und validierendem Resolver. Eine [[Transportverschlüsselung]] findet bei DNSSEC nicht statt. Die Protokolle [[DNS over TLS]] und [[DNS over HTTPS]] bieten eine Transportverschlüsselung, die zusätzlich zu DNSSEC verwendet werden kann. Der primäre Einsatzzweck ist die sichere Kommunikation von (Stub-)Resolver bzw. Anwendung zu einem rekursiven Nameserver. Beide bieten [[Vertraulichkeit]] vor einem lauschenden Angreifer im Netz, was DNSSEC alleine nicht bietet. DNS over HTTPS hat den Vorteil, dass sich die Kommunikation wie eine gewöhnliche [[Hypertext Transfer Protocol Secure\|HTTPS]]-Verbindung bei [[World Wide Web\|Webverkehr]] darstellt und somit auch in Netzen mit eingeschränkter Kommunikationsfähigkeit funktioniert.

			[[DNSCurve]] ist eine Alternative zu DNSSEC, die sich allerdings nicht durchgesetzt hat. DNSCurve verwendet ein eigenes Verschlüsselungsprotokoll, welches sich sowohl von DNSSEC als auch TLS unterscheidet.

	== Sicherheitsrelevante Schwachstellen von DNSSEC ==		== Sicherheitsrelevante Schwachstellen von DNSSEC ==

Matthäus Wander: /* Sicherheitsrelevante Schwachstellen von DNSSEC */ erg.

2024-12-28T11:13:22Z

Sicherheitsrelevante Schwachstellen von DNSSEC: erg.

← Nächstältere Version		Version vom 28. Dezember 2024, 13:13 Uhr
Zeile 110:		Zeile 110:
	* [[DNS Amplification Attack]]s unter Ausnutzung der öffentlichen DNS-Infrastruktur werden effektiver, da DNS-Antworten mit DNSSEC deutlich länger sind.		* [[DNS Amplification Attack]]s unter Ausnutzung der öffentlichen DNS-Infrastruktur werden effektiver, da DNS-Antworten mit DNSSEC deutlich länger sind.
	* Die öffentlichen Schlüssel zur Verifizierung werden ebenfalls über das DNS-System verteilt. Damit ergeben sich Angriffsmöglichkeiten auf die Vertrauensketten. Dies kann verhindert werden, wenn der öffentliche Schlüssel des [[Vertrauensanker\|Vertrauensursprungs]] ({{enS\|Trust Anchor}}) auf anderem Wege als der DNS-Infrastruktur (zum Beispiel mit dem Betriebssystem oder der Server- bzw. Clientsoftware) verteilt wird.		* Die öffentlichen Schlüssel zur Verifizierung werden ebenfalls über das DNS-System verteilt. Damit ergeben sich Angriffsmöglichkeiten auf die Vertrauensketten. Dies kann verhindert werden, wenn der öffentliche Schlüssel des [[Vertrauensanker\|Vertrauensursprungs]] ({{enS\|Trust Anchor}}) auf anderem Wege als der DNS-Infrastruktur (zum Beispiel mit dem Betriebssystem oder der Server- bzw. Clientsoftware) verteilt wird.
	* Mittels [[Zone Walking]] kann der Inhalt von Zonen vollständig ausgelesen werden (erschwert durch [[NSEC3]]).		* Mittels [[Zone Walking]] kann der Inhalt von Zonen vollständig ausgelesen werden. Dies wird erschwert durch [[NSEC3]], was den Inhalt der Zone durch [[Hashing]] verschleiert. Zone Walking kann durch [[Zone_Walking#Minimale_Abdeckung_mit_Online-Signierung\|Online-Signierung]] vollständig verhindert werden, was jedoch das Vorhalten des privaten Schlüssels auf dem Server und höhere Rechenlast erfordert.
	* Da Stubresolver oft nicht selbst die DNS-Antworten validieren, kann ein Angriff auf der Kommunikationsstrecke zu ihrem rekursiven Nameserver erfolgen. Auch kann der rekursive Nameserver selbst kompromittiert sein.		* Da Stubresolver oft nicht selbst die DNS-Antworten validieren, kann ein Angriff auf der Kommunikationsstrecke zu ihrem rekursiven Nameserver erfolgen. Auch kann der rekursive Nameserver selbst kompromittiert sein.

Mary Joanna: Änderung 244912527 von Smarti rückgängig gemacht; auf archive.org vorhanden

2024-09-30T08:34:37Z

Änderung 244912527 von Smarti rückgängig gemacht; auf archive.org vorhanden

← Nächstältere Version		Version vom 30. September 2024, 10:34 Uhr
Zeile 134:		Zeile 134:
	== Weblinks ==		== Weblinks ==
	* [http://www.dnssec.net/ dnssec.net] – Portal zu DNSSEC (englisch).		* [http://www.dnssec.net/ dnssec.net] – Portal zu DNSSEC (englisch).
	* {{~~Toter Link~~ \|~~date~~=~~2024-05-13~~ \|url=http://cdn-storage.br.de/iLCpbHJGNL9zu6i6NL97bmWH_-bG/_-0S/5-gc524P/140724_1805_IQ---Wissenschaft-und-Forschung_Die-14-Schluessel-zum-Internet---Die-Web-Ve.mp3 \|text=Die 14 Schlüssel zum Internet – Die Web-Verwaltung „ICANN“}}(MP3; 22 MB) Podcast zur Sendung [[IQ – Wissenschaft und Forschung]], 24. Juli 2014.		* {{Webarchiv\|wayback=20160304074535\|url=http://cdn-storage.br.de/iLCpbHJGNL9zu6i6NL97bmWH_-bG/_-0S/5-gc524P/140724_1805_IQ---Wissenschaft-und-Forschung_Die-14-Schluessel-zum-Internet---Die-Web-Ve.mp3\|text=Die 14 Schlüssel zum Internet – Die Web-Verwaltung „ICANN“.}} (MP3; 22 MB) Podcast zur Sendung [[IQ – Wissenschaft und Forschung]], 24. Juli 2014.
	* [http://www.hznet.de/dns/dnssec-denic040929.pdf Einführung in Secure DNS.] (PDF; 122 kB) hznet.de		* [http://www.hznet.de/dns/dnssec-denic040929.pdf Einführung in Secure DNS.] (PDF; 122 kB) hznet.de
	* [http://www.hznet.de/dns/dnssec-denic060404.pdf DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing.] (PDF; 68 kB) hznet.de		* [http://www.hznet.de/dns/dnssec-denic060404.pdf DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing.] (PDF; 68 kB) hznet.de

Smarti: /* Weblinks */Defekter Weblink

2024-05-12T22:39:20Z

Weblinks: Defekter Weblink

← Nächstältere Version		Version vom 13. Mai 2024, 00:39 Uhr
Zeile 134:		Zeile 134:
	== Weblinks ==		== Weblinks ==
	* [http://www.dnssec.net/ dnssec.net] – Portal zu DNSSEC (englisch).		* [http://www.dnssec.net/ dnssec.net] – Portal zu DNSSEC (englisch).
	* [http://cdn-storage.br.de/iLCpbHJGNL9zu6i6NL97bmWH_-bG/_-0S/5-gc524P/140724_1805_IQ---Wissenschaft-und-Forschung_Die-14-Schluessel-zum-Internet---Die-Web-Ve.mp3 Die 14 Schlüssel zum Internet – Die Web-Verwaltung „ICANN“.] (MP3; 22 MB) Podcast zur Sendung [[IQ – Wissenschaft und Forschung]], 24. Juli 2014.		* {{Toter Link \|date=2024-05-13 \|url=http://cdn-storage.br.de/iLCpbHJGNL9zu6i6NL97bmWH_-bG/_-0S/5-gc524P/140724_1805_IQ---Wissenschaft-und-Forschung_Die-14-Schluessel-zum-Internet---Die-Web-Ve.mp3 \|text=Die 14 Schlüssel zum Internet – Die Web-Verwaltung „ICANN“}}(MP3; 22 MB) Podcast zur Sendung [[IQ – Wissenschaft und Forschung]], 24. Juli 2014.
	* [http://www.hznet.de/dns/dnssec-denic040929.pdf Einführung in Secure DNS.] (PDF; 122 kB) hznet.de		* [http://www.hznet.de/dns/dnssec-denic040929.pdf Einführung in Secure DNS.] (PDF; 122 kB) hznet.de
	* [http://www.hznet.de/dns/dnssec-denic060404.pdf DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing.] (PDF; 68 kB) hznet.de		* [http://www.hznet.de/dns/dnssec-denic060404.pdf DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing.] (PDF; 68 kB) hznet.de

Smarti: Die Abkürzung "EDNS" wurde im weiteren Verlauf verwendet, ohne vorher definiert worden zu sein.

2024-05-12T22:22:57Z

Die Abkürzung "EDNS" wurde im weiteren Verlauf verwendet, ohne vorher definiert worden zu sein.

← Nächstältere Version		Version vom 13. Mai 2024, 00:22 Uhr
Zeile 6:		Zeile 6:
	== Überblick ==		== Überblick ==

	DNSSEC verwendet ein [[asymmetrisches Kryptosystem]]. Der „Besitzer“ einer Information – in der Regel der Master-Server, auf dem die abzusichernde [[Zone (DNS)\|Zone]] liegt – unterzeichnet jeden einzelnen Record mittels seines [[Geheimer Schlüssel\|geheimen Schlüssels]] ({{enS\|private key}}). DNS-Clients können diese Unterschrift mit dem [[Öffentlicher Schlüssel\|öffentlichen Schlüssel]] ({{enS\|public key}}) des Besitzers validieren und damit Authentizität und Integrität überprüfen. DNSSEC setzt die Erweiterung [[Extended DNS]] voraus, mit der in DNS-Nachrichten zusätzliche Parameter übertragen werden können. Des Weiteren hebt EDNS die Größenbeschränkung von DNS-Nachrichten über [[User Datagram Protocol\|UDP]] von 512 Bytes auf. Zur Übertragung von Schlüsseln und Signaturen sind erheblich längere DNS-Nachrichten erforderlich.		DNSSEC verwendet ein [[asymmetrisches Kryptosystem]]. Der „Besitzer“ einer Information – in der Regel der Master-Server, auf dem die abzusichernde [[Zone (DNS)\|Zone]] liegt – unterzeichnet jeden einzelnen Record mittels seines [[Geheimer Schlüssel\|geheimen Schlüssels]] ({{enS\|private key}}). DNS-Clients können diese Unterschrift mit dem [[Öffentlicher Schlüssel\|öffentlichen Schlüssel]] ({{enS\|public key}}) des Besitzers validieren und damit Authentizität und Integrität überprüfen. DNSSEC setzt die Erweiterung [[Extended DNS]] (EDNS) voraus, mit der in DNS-Nachrichten zusätzliche Parameter übertragen werden können. Des Weiteren hebt EDNS die Größenbeschränkung von DNS-Nachrichten über [[User Datagram Protocol\|UDP]] von 512 Bytes auf. Zur Übertragung von Schlüsseln und Signaturen sind erheblich längere DNS-Nachrichten erforderlich.

	Die ursprüngliche DNSSEC-Version – im März 1999 im <nowiki>RFC 2535</nowiki><ref>{{RFC-Internet \|RFC=2535 \|Titel=Domain Name System Security Extensions \|Datum=1999-03}}</ref> – definiert erwies sich in der Praxis aufgrund einer zu aufwändigen Schlüsselverwaltung als untauglich. Die Verbreitung von DNSSEC verzögerte sich dadurch um mehrere Jahre, bis 2005 eine komplette Neufassung veröffentlicht wurde. Um Inkompatibilitäten mit bestehender Software auszuschließen, wurden neue [[Resource Record\|Resource-Record]]-Typen eingeführt ([[RRSIG Resource Record\|RRSIG]] ersetzt [[SIG Resource Record\|SIG]], [[DNSKEY Resource Record\|DNSKEY]] ersetzt [[KEY Resource Record\|KEY]], [[NSEC Resource Record\|NSEC]] ersetzt NXT). Im Oktober 2005 wurde mit der schwedischen [[.se]]-Domain erstmals eine [[Top-Level-Domain]] digital unterschrieben. Seit Mai 2011 ist DNSSEC auch für [[.de]]-Domains prinzipiell verfügbar,<ref name="denic">{{Internetquelle \|url=https://www.denic.de/en/know-how/dnssec/ \|titel=DNSSEC \|hrsg=[[DENIC]] \|datum=2014-05-12 \|sprache=en \|abruf=2014-05-12}}</ref> nachdem das [[Zone Walking]] durch die Einführung des [[NSEC3 Resource Record]]s im März 2008 hinreichend erschwert wurde.		Die ursprüngliche DNSSEC-Version – im März 1999 im <nowiki>RFC 2535</nowiki><ref>{{RFC-Internet \|RFC=2535 \|Titel=Domain Name System Security Extensions \|Datum=1999-03}}</ref> – definiert erwies sich in der Praxis aufgrund einer zu aufwändigen Schlüsselverwaltung als untauglich. Die Verbreitung von DNSSEC verzögerte sich dadurch um mehrere Jahre, bis 2005 eine komplette Neufassung veröffentlicht wurde. Um Inkompatibilitäten mit bestehender Software auszuschließen, wurden neue [[Resource Record\|Resource-Record]]-Typen eingeführt ([[RRSIG Resource Record\|RRSIG]] ersetzt [[SIG Resource Record\|SIG]], [[DNSKEY Resource Record\|DNSKEY]] ersetzt [[KEY Resource Record\|KEY]], [[NSEC Resource Record\|NSEC]] ersetzt NXT). Im Oktober 2005 wurde mit der schwedischen [[.se]]-Domain erstmals eine [[Top-Level-Domain]] digital unterschrieben. Seit Mai 2011 ist DNSSEC auch für [[.de]]-Domains prinzipiell verfügbar,<ref name="denic">{{Internetquelle \|url=https://www.denic.de/en/know-how/dnssec/ \|titel=DNSSEC \|hrsg=[[DENIC]] \|datum=2014-05-12 \|sprache=en \|abruf=2014-05-12}}</ref> nachdem das [[Zone Walking]] durch die Einführung des [[NSEC3 Resource Record]]s im März 2008 hinreichend erschwert wurde.

Matthäus Wander: /* Sicherheitsrelevante Schwachstellen von DNSSEC */ Zone Walking verlinkt

2024-02-25T12:42:49Z

Sicherheitsrelevante Schwachstellen von DNSSEC: Zone Walking verlinkt

← Nächstältere Version		Version vom 25. Februar 2024, 14:42 Uhr
Zeile 110:		Zeile 110:
	* [[DNS Amplification Attack]]s unter Ausnutzung der öffentlichen DNS-Infrastruktur werden effektiver, da DNS-Antworten mit DNSSEC deutlich länger sind.		* [[DNS Amplification Attack]]s unter Ausnutzung der öffentlichen DNS-Infrastruktur werden effektiver, da DNS-Antworten mit DNSSEC deutlich länger sind.
	* Die öffentlichen Schlüssel zur Verifizierung werden ebenfalls über das DNS-System verteilt. Damit ergeben sich Angriffsmöglichkeiten auf die Vertrauensketten. Dies kann verhindert werden, wenn der öffentliche Schlüssel des [[Vertrauensanker\|Vertrauensursprungs]] ({{enS\|Trust Anchor}}) auf anderem Wege als der DNS-Infrastruktur (zum Beispiel mit dem Betriebssystem oder der Server- bzw. Clientsoftware) verteilt wird.		* Die öffentlichen Schlüssel zur Verifizierung werden ebenfalls über das DNS-System verteilt. Damit ergeben sich Angriffsmöglichkeiten auf die Vertrauensketten. Dies kann verhindert werden, wenn der öffentliche Schlüssel des [[Vertrauensanker\|Vertrauensursprungs]] ({{enS\|Trust Anchor}}) auf anderem Wege als der DNS-Infrastruktur (zum Beispiel mit dem Betriebssystem oder der Server- bzw. Clientsoftware) verteilt wird.
	* Mittels ~~DNSSEC~~ Walking kann der Inhalt von Zonen vollständig ausgelesen werden (erschwert durch [[NSEC3]]).		* Mittels [[Zone Walking]] kann der Inhalt von Zonen vollständig ausgelesen werden (erschwert durch [[NSEC3]]).
	* Da Stubresolver oft nicht selbst die DNS-Antworten validieren, kann ein Angriff auf der Kommunikationsstrecke zu ihrem rekursiven Nameserver erfolgen. Auch kann der rekursive Nameserver selbst kompromittiert sein.		* Da Stubresolver oft nicht selbst die DNS-Antworten validieren, kann ein Angriff auf der Kommunikationsstrecke zu ihrem rekursiven Nameserver erfolgen. Auch kann der rekursive Nameserver selbst kompromittiert sein.

Matthäus Wander: unpassender Link; DANE ist nicht dasselbe wie DNS

2024-01-16T20:03:19Z

unpassender Link; DANE ist nicht dasselbe wie DNS

← Nächstältere Version		Version vom 16. Januar 2024, 22:03 Uhr
Zeile 1:		Zeile 1:
	{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}		{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}
	Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein [[DNS~~-based Authentication of Named Entities\|'''DNS''']]~~-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.		Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein DNS-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.

	[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].		[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].

Bambelbie: link

2024-01-16T14:45:00Z

link

← Nächstältere Version		Version vom 16. Januar 2024, 16:45 Uhr
Zeile 1:		Zeile 1:
	{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}		{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}
	Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein DNS-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.		Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein [[DNS-based Authentication of Named Entities\|'''DNS''']]-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.

	[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].		[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].

← Nächstältere Version		Version vom 16. Januar 2024, 22:03 Uhr
Zeile 1:		Zeile 1:
	{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}		{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}
	Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein [[DNS~~-based Authentication of Named Entities\|'''DNS''']]~~-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.		Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein DNS-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.

	[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].		[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].

← Nächstältere Version		Version vom 16. Januar 2024, 16:45 Uhr
Zeile 1:		Zeile 1:
	{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}		{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll\|DNSSEC}}
	Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein DNS-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.		Die '''Domain Name System Security Extensions''' ('''DNSSEC''') sind eine Reihe von [[Internetstandard]]s, die das [[Domain Name System]] (DNS) um Sicherheitsmechanismen zur Gewährleistung der [[Authentizität]] und [[Integrität (Informationssicherheit)\|Integrität]] der Daten erweitern. Ein [[DNS-based Authentication of Named Entities\|'''DNS''']]-Teilnehmer kann damit verifizieren, dass die erhaltenen [[Zone (DNS)\|DNS-Zonendaten]] auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen [[Cache Poisoning]] entwickelt. Es sichert die Übertragung von [[Resource Record]]s durch [[digitale Signatur]]en ab. Eine [[Authentifizierung]] von Servern oder Clients findet nicht statt.

	[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].		[[Vertraulichkeit]] ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht [[Verschlüsselung\|verschlüsselt]].