Diskussion:DNSCurve
Zur Navigation springen
Zur Suche springen
Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „DNSCurve“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.Aus der QS[Quelltext bearbeiten]
Relevanz Prüfen, Das Wort Protokoll-Vorschlag lässt mich etwas stutzen. --HAL 9000 12:03, 13. Okt. 2008 (CEST)
- Bitte erstmal informieren, wer Daniel J. Bernstein ist (Tip: Wikipedia hilft), bevor Irrelevanz unterstellt wird. Das ist nicht irgendwer. Wenn der Artikel wegen Irrelevanz gelöscht werden soll (ohje), dann müsste DNSSEC mit dem gleichen Argument gelöscht werden. Beide Techniken adressieren die gleichen Designschwächen von DNS, beide sind nur Protokoll-Vorschläge, die noch nicht in den (breiten) Einsatz gekommen sind. Es ist nur dank der vor kurzer Zeit bekannt gewordenen Designschwäche vieler schlechter Caching DNS-Resolver (ausgenommen djbdns von Daniel J. Bernstein) mehr in den Mittelpunkt des Interesses gerückt, die DNS-Schwächen endlich anzugehen. DNSCurve ist jetzt die technisch überlegene Alternative zum historisch gewachsenen DNSSEC. Beide Verfahren sind momentan nur Vorschläge, aber eben in reger Diskussion, insbesondere seit der DNS-Cache-Poisoning Welle vor 3 Monaten. Dieser Entwicklung trägt der DNSCurve-Artikel Rechnung, zusammen mit dem bekannten DNSSEC-Artikel, der genau so relevant oder irrelevant ist. Endorphine 23:43, 13. Okt. 2008 (CEST)
- Eben es ist ein Vorschlag, Wenn irgendwann einer der Vorschläge umgesetzt wird ist er sicher Lemma würdig. So passt er wohl eher als Unterpunkt in DNS. --HAL 9000 16:26, 14. Okt. 2008 (CEST)
- RFC <- das sind alles nur Vorschläge. Im Gegensatz zu vielen anderen Protokollen habe ich das nur explizit und auf Deutsch hingeschrieben, das ist sonst im Entwicklungsstadium eine implizite Annahme. Unter den RFCs sind große Massen von Protokollen, die auch in der WP beschrieben sind. Die Entwicklung läuft eben so. Sicherungsmittel für DNS sind vor dem Cache-Poisoning-Problem ein aktuell heiß diskutiertes Thema in der Öffentlichkeit, ein Artikel zu DNSCurve ist zur Klärung des Begriffs genau richtig in der WP, um einen schellen Überblick über das Thema zu bekommen, ohne erst in die fachlichen Interna herabsteigen zu müssen. Wenn du DNSCurve die Relevanz absprechen willst, dann muss DNSSEC mit dem selben Argument fallen. Und auch eine Menge weiterer WP-Artikel zu RFC-Protokollen. Endorphine 22:29, 14. Okt. 2008 (CEST)
- Klar, SMTP, IMAP, MIME, ... alles nur Vorschläge. Ein Thema eines RFCs wird nicht dadurch relevant, dass es im RFC steht, sondern dadurch, dass es implementiert und verbreitet verwendet wird. --Eike 23:19, 14. Okt. 2008 (CEST)
- Hatte auch schon wegen des C's im wortlaut RFC meine Diskussionen :) hier ist zu beachten das manches nur als Memo (mit ablaufdatum) auftaucht, die "Standards" aber als "echte: Request for Comments:XYZ" geführt werden. ansonsten kann man ja auf die ietf verweisen :))
Protokoll-Vorschlag wäre dann eigentlich ein eigenständiges Memo bei der IETF. Wenn es ein "Kommentar" bei einer Konferenz war ist es vom Wortlaut her nur eine Erwähnung aber noch nicht als Protokoll vorgeschlagen worden … --Majx 00:49, 29. Jul. 2011 (CEST)
- Hatte auch schon wegen des C's im wortlaut RFC meine Diskussionen :) hier ist zu beachten das manches nur als Memo (mit ablaufdatum) auftaucht, die "Standards" aber als "echte: Request for Comments:XYZ" geführt werden. ansonsten kann man ja auf die ietf verweisen :))
- Klar, SMTP, IMAP, MIME, ... alles nur Vorschläge. Ein Thema eines RFCs wird nicht dadurch relevant, dass es im RFC steht, sondern dadurch, dass es implementiert und verbreitet verwendet wird. --Eike 23:19, 14. Okt. 2008 (CEST)
- RFC <- das sind alles nur Vorschläge. Im Gegensatz zu vielen anderen Protokollen habe ich das nur explizit und auf Deutsch hingeschrieben, das ist sonst im Entwicklungsstadium eine implizite Annahme. Unter den RFCs sind große Massen von Protokollen, die auch in der WP beschrieben sind. Die Entwicklung läuft eben so. Sicherungsmittel für DNS sind vor dem Cache-Poisoning-Problem ein aktuell heiß diskutiertes Thema in der Öffentlichkeit, ein Artikel zu DNSCurve ist zur Klärung des Begriffs genau richtig in der WP, um einen schellen Überblick über das Thema zu bekommen, ohne erst in die fachlichen Interna herabsteigen zu müssen. Wenn du DNSCurve die Relevanz absprechen willst, dann muss DNSSEC mit dem selben Argument fallen. Und auch eine Menge weiterer WP-Artikel zu RFC-Protokollen. Endorphine 22:29, 14. Okt. 2008 (CEST)
- Eben es ist ein Vorschlag, Wenn irgendwann einer der Vorschläge umgesetzt wird ist er sicher Lemma würdig. So passt er wohl eher als Unterpunkt in DNS. --HAL 9000 16:26, 14. Okt. 2008 (CEST)
- Bitte erstmal informieren, wer Daniel J. Bernstein ist (Tip: Wikipedia hilft), bevor Irrelevanz unterstellt wird. Das ist nicht irgendwer. Wenn der Artikel wegen Irrelevanz gelöscht werden soll (ohje), dann müsste DNSSEC mit dem gleichen Argument gelöscht werden. Beide Techniken adressieren die gleichen Designschwächen von DNS, beide sind nur Protokoll-Vorschläge, die noch nicht in den (breiten) Einsatz gekommen sind. Es ist nur dank der vor kurzer Zeit bekannt gewordenen Designschwäche vieler schlechter Caching DNS-Resolver (ausgenommen djbdns von Daniel J. Bernstein) mehr in den Mittelpunkt des Interesses gerückt, die DNS-Schwächen endlich anzugehen. DNSCurve ist jetzt die technisch überlegene Alternative zum historisch gewachsenen DNSSEC. Beide Verfahren sind momentan nur Vorschläge, aber eben in reger Diskussion, insbesondere seit der DNS-Cache-Poisoning Welle vor 3 Monaten. Dieser Entwicklung trägt der DNSCurve-Artikel Rechnung, zusammen mit dem bekannten DNSSEC-Artikel, der genau so relevant oder irrelevant ist. Endorphine 23:43, 13. Okt. 2008 (CEST)
DNSCurve vs DNSSEC[Quelltext bearbeiten]
Aus dem Artikel sollte hervorgehen das DNSCurve als Ergänzung zu DNSSEC gesehen wird und nicht als Konkurrenz oder Alternative. Zitat: [1] "DNSCurve and DNSSEC have complementary security goals." Neuhaus 15:52, 9. Dez. 2008 (CET)
- Das ist (zumindest zum jetzigen Zeitpunkt) nicht ganz richtig. Die Ziele der beiden Verfahren sind nicht deckungsgleich, aber es gibt doch eine erhebliche Überschneidung. Bernstein beschreibt DNSCurve als Alternative zu DNSSEC. Der Inhalt der verlinkten Seite wurde mittlerweile auch ersetzt. --Matthäus Wander 17:58, 6. Mär. 2011 (CET)
Vertraulichkeit[Quelltext bearbeiten]
„Zum Beispiel bietet DNSSEC keine Absicherung der Vertraulichkeit von DNS-Abfragen, DNSCurve verschlüsselt dagegen Anfrage und Antwort.“
- Die obige Aussage suggeriert, DNSCurve würde Vertraulichkeit bieten. DNSCurve verschlüsselt zwar, aber der angefragte Domainname lässt sich bei vielen Domains schon aus dem angefragten Nameserver ablesen, z. B.
a.ns.facebook.com. Verschlüsselung kann einen Sicherheitsgewinn darstellen, wenn dieselben Nameserver für mehrere Domains zuständig sind, weil der Angreifer dann einen aufwendigeren Fingerprinting-Angriff (zum Beispiel durch Länge der Anfrage und Antwort) durchführen muss, um den angefragten Domainnamen zu ermitteln. Das muss dann aber auch im Artikel entsprechend ausgeführt werden, da der Sicherheitsgewinn an Bedingungen geknüpft ist, die über die Verschlüsselung hinausgehen. Die obige Aussage ist so nicht richtig. --Matthäus Wander 01:01, 1. Aug. 2015 (CEST)
- Ich hab die Formulierung so geändert, dass Vertraulichkeit als Ziel genannt ist, aber ohne Bewertung der Wirksamkeit und ohne Vergleich mit DNSSEC. Für Sicherheitsbewertungen und -vergleiche würde ich auf belastbare Quellen zurückgreifen. --Matthäus Wander 23:13, 7. Aug. 2015 (CEST)