1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Protokoll: DNSSEC ist gescheitert

Nein!

  1. Thema

Neues Thema Ansicht wechseln


  1. Nein!

    Autor: nudel 30.06.15 - 10:31

    Ja, DNSSEC ist alt, ja DNSSEC löst nicht alle Probleme.

    Aber DNSSEC, gerade DANE, ergänzt ein ganzes Set von Werkzeugen (TLS, Cert-Pinning etc.).
    Schade ist natürlich, dass die DNS-Anfrage nicht verschlüsselt wird. Aber wer meine Leitung überwacht, der kann schließlich auch einfach schauen mit welcher IP ich danach kommuniziere; die ist in den allermeisten Fällen einer Domain zuzuordnen. Ist so!

    UDP-Reflection-Angriffe sind gefährlich, doch afaik sind signierte DNS-Antworten so groß dass die meisten Server diese eh mit TCP beantworten. Ich glaube nicht, dass das ein großes Problem wird.

  2. Re: Nein!

    Autor: ikhaya 30.06.15 - 10:41

    nudel schrieb:
    --------------------------------------------------------------------------------
    > wer meine Leitung überwacht, der kann schließlich auch einfach schauen mit
    > welcher IP ich danach kommuniziere; die ist in den allermeisten Fällen
    > einer Domain zuzuordnen. Ist so!

    Wollte ich grade auch als Kritikpunkt einwerfen. Wenn nicht einer dann zumindest einer relativ geringen Anzahl an Adressen, womit man dann Wahrscheinlichkeitsrechnungen anstellen könnte welche Seite genau.

    > UDP-Reflection-Angriffe sind gefährlich, doch afaik sind signierte
    > DNS-Antworten so groß dass die meisten Server diese eh mit TCP beantworten.
    > Ich glaube nicht, dass das ein großes Problem wird.

    Wenn die Leute die genannten Möglichkeiten zum Eindämmen des Problems noch nicht getroffen haben , müssen sie das so oder so irgendwann nachholen weil es jemand ausnutzt.

  3. Re: Nein!

    Autor: tunnelblick 30.06.15 - 10:57

    wie so häufig: im kleinen süß und nett, im großen eher nicht so. schon mal überlegt, wieviel rechenaufwand das für einen hoster bedeutet? was es heisst, so eine riesige pki zu managen? nein? dachte ich mir.
    dnssec ist tot und wird auch nicht mehr im großen stil kommen. wer es nutzen möchte, kann das aber natürlich weiterhin gerne tun. aber verlangen kann man es nicht.

  4. Re: Nein!

    Autor: ikhaya 30.06.15 - 10:59

    Überlegt ja, aber mir fehlt da eindeutig die Erfahrung.
    Ich hab das Gefühl es könnte so sein wie mit TLS: Alle denken es braucht massiv Rechenleistung und neue Server . Dann kam Google und hat gezeigt dass es nicht spürbar war was TLS an Ressourcen mehr verbraucht.

  5. Re: Nein!

    Autor: tunnelblick 30.06.15 - 11:01

    wir haben das mal gepoct - es kostet rechenleistung und nicht wenig. und bei der anzahl zonen/domains, die bei uns liegen...

  6. Re: Nein!

    Autor: k8n 30.06.15 - 11:07

    tunnelblick schrieb:
    --------------------------------------------------------------------------------
    > wie so häufig: im kleinen süß und nett, im großen eher nicht so. schon mal
    > überlegt, wieviel rechenaufwand das für einen hoster bedeutet? was es
    > heisst, so eine riesige pki zu managen? nein? dachte ich mir.
    > dnssec ist tot und wird auch nicht mehr im großen stil kommen. wer es
    > nutzen möchte, kann das aber natürlich weiterhin gerne tun. aber verlangen
    > kann man es nicht.

    Blödsinn, selbst auf meinem kleinen schwachen rechner (AMD E350) habe ich

    Signatures per second: 257.255

    Ausserdem erfolgt die Signierung nur bei ÄNDERUNG der Einträge, also meistens macht man gar nix.

  7. Re: Nein!

    Autor: M.P. 30.06.15 - 11:08

    Hmm, gibt es denn Alternativen, oder muss ich damit leben, daß manchmal DNS-Anfragen zur Internet-Seite meiner Hausbank auf die IP-Adresse eines Servers in Osteuropa weisen?

  8. Re: Nein!

    Autor: tunnelblick 30.06.15 - 11:08

    hö? wer ist "man"? du privat? sicherlich.

  9. Re: Nein!

    Autor: tunnelblick 30.06.15 - 11:09

    wann ist das so? woher kommen die antworten? wer ist der eigentlich autoritative server?

  10. Re: Nein!

    Autor: felix.schwarz 30.06.15 - 11:09

    nudel schrieb:
    > Schade ist natürlich, dass die DNS-Anfrage nicht verschlüsselt wird. Aber
    > wer meine Leitung überwacht, der kann schließlich auch einfach schauen mit
    > welcher IP ich danach kommuniziere; die ist in den allermeisten Fällen
    > einer Domain zuzuordnen. Ist so!

    Insbesondere verwenden die meisten modernen Clients TLS Server Name Indication: Da wird dann der angeforderte Domain-Name ohnehin im Klartext übertragen (aus den gleichen Sicherheitserwägungen wie im Zitat genannt).

  11. Re: Nein!

    Autor: k8n 30.06.15 - 11:10

    tunnelblick schrieb:
    --------------------------------------------------------------------------------
    > wir haben das mal gepoct - es kostet rechenleistung und nicht wenig. und
    > bei der anzahl zonen/domains, die bei uns liegen...


    Habt ihr genauere Infos?
    Mein alter Rechner (1,6 GHz AMD) macht 257255 Signaturen pro Sekunde und die müssen nur bei Änderungen an den Zonen/Domains erstellt werden, nicht bei Abfragen.

    Sicher dass du das nicht mit dnscrypt verwechselst?

  12. Re: Nein!

    Autor: Schnarchnase 30.06.15 - 11:11

    Wenn du die Signierung nicht nur bei Änderung durchführst, machst du etwas falsch.

  13. Re: Nein!

    Autor: Anonymer Nutzer 30.06.15 - 11:12

    @felix.schwarz
    selbst, wenn sni nicht verwendet wird, wird der servername im klartext als teil des zertifikats übertragen (sofern kein wildcard). aber ja, bei sni auch. eine lösung wäre vielleicht in beiden fällen, hashes zu verwenden.

  14. Re: Nein!

    Autor: tunnelblick 30.06.15 - 11:13

    ein internes team hat es gepoct, ich habe es nur gehört. das ist aber einer der hauptgründe, warum wir es als firma nicht einsetzen. da ich das hier aber vom arbeitsplatz aus schreibe, erspare ich mir weiteres... sonst könnte man vermutlich auf die firma schließen und das möchte ich nicht :)
    ich könnte aber noch mal nachfragen, was genau damals so viel "gekostet" hat.

  15. Re: Nein!

    Autor: M.P. 30.06.15 - 11:17

    Mir reicht es, daß die Möglichkeit besteht.

    Es gibt natürlich noch andere Möglichkeiten, die Korrektheit des Bankservers zu verifizieren - aber ob man z. B. dem HTTPS Zertifikatssystem nach "Superfish" und der Diginotar-Affäre noch trauen kann ...



    1 mal bearbeitet, zuletzt am 30.06.15 11:23 durch M.P..

  16. Re: Nein!

    Autor: k8n 30.06.15 - 11:18

    tunnelblick schrieb:
    --------------------------------------------------------------------------------
    > ein internes team hat es gepoct, ich habe es nur gehört. das ist aber einer
    > der hauptgründe, warum wir es als firma nicht einsetzen. da ich das hier
    > aber vom arbeitsplatz aus schreibe, erspare ich mir weiteres... sonst
    > könnte man vermutlich auf die firma schließen und das möchte ich nicht :)
    > ich könnte aber noch mal nachfragen, was genau damals so viel "gekostet"
    > hat.

    Lass mich raten, die hatten keine Lust oder kein KnowHow und/oder wollten einfach neue Server und haben zu hoch gepokert.. :-D

  17. Re: Nein!

    Autor: tunnelblick 30.06.15 - 11:58

    ich habe noch nicht gefragt ;)

  18. Re: Nein!

    Autor: Bitschnipser 02.07.15 - 17:52

    tunnelblick schrieb:
    --------------------------------------------------------------------------------
    > wie so häufig: im kleinen süß und nett, im großen eher nicht so. schon mal
    > überlegt, wieviel rechenaufwand das für einen hoster bedeutet?

    Leg doch mal Zahlen vor.
    Relevante Punkte:
    1) Technischer Mehraufwand im Vergleich zur unverschlüsselten DNS-Abfrage.
    2) Anteil von DNS-Abfragen am Gesamtaufwand eines Servers. (In der Regel komplett vernachlässigbar.)
    3) Anteil der Serverbetriebskosten eines DNS-Anbieters im Vergleich zu den Gesamtkosten.

    Ohne diese Zahlen ist ohnehin keine seriöse Aussage über die Mehrkosten für DNSSEC möglich.
    Ich sehe allerdings nicht, warum das irgendwie ins Gewicht fallen kann. Am ehesten noch bei einem reinen DNS-Provider, der nichts anderes macht als Domainabfragen beantworten. Aber selbst der hat Fixkosten, und pro Domain Verwaltungskosten; das verwässert den Mehraufwand fürs Verschlüsseln und für den Transfer der Schlüsseldaten sehr deutlich.

    > was es
    > heisst, so eine riesige pki zu managen?

    Die PKI wird nicht davon größer, dass mehr Nutzdaten pro Datensatz verfügbar sind. Die Indexe werden davon nicht größer, und der Indexaufwand übersteigt den Aufwand für die Nutzdaten in der Regel deutlich (Daumenregel: doppelte Datenmenge, vervielfachte IO-Last).

    > nein? dachte ich mir.

    Falsch gedacht ;-P

    > dnssec ist tot und wird auch nicht mehr im großen stil kommen.

    Mag sein, aber nicht aus den Gründen, die du grad nennst.
    Und auch nicht aus den Gründen, die der Artikel nennt.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Mediengruppe Pressedruck, Augsburg
  2. Deloitte, Berlin, Düsseldorf, Hamburg
  3. Deloitte, Düsseldorf, Hamburg
  4. SySS GmbH, Tübingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. One Touch tragbare Festplatte 500 GB in verschiedenen Farben je 86,99€)
  2. 149,90€
  3. 649,00€ (Bestpreis!)
  4. 189,90€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mr. Robot rezensiert: Domo Arigato, Mr. Robot!
Mr. Robot rezensiert
Domo Arigato, Mr. Robot!

Wie im Achtziger-Klassiker Mr. Roboto von Styx hat auch Elliot in Mr. Robot Geheimnisse. Die Dramaserie um den Hacker ist nicht nur wegen Rami Malek grandios. Sie hat einen ganz eigenen beeindruckenden visuellen Stil und zeigt Hacking, wie es wirklich ist. Wir blicken nach dem Serienfinale zurück.
Eine Rezension von Oliver Nickel und Moritz Tremmel

  1. Openideo-Wettbewerb Die fünf besten Hacker-Symbolbilder sind ausgewählt
  2. Cyberangriffe Attribution ist wie ein Indizienprozess
  3. Double Dragon APT41 soll für Staat und eigenen Geldbeutel hacken

Fitnesstracker im Test: Aldi sportlich abgeschlagen hinter Honor und Mi Band 4
Fitnesstracker im Test
Aldi sportlich abgeschlagen hinter Honor und Mi Band 4

Alle kosten um die 30 Euro, haben ähnliche Funktionen - trotzdem gibt es bei aktuellen Fitnesstrackern von Aldi, Honor und Xiaomi spürbare Unterschiede. Als größte Stärke des Geräts von Aldi empfanden wir kurioserweise eine technische Schwäche.
Von Peter Steinlechner

  1. Wearable Acer und Vatikan präsentieren smarten Rosenkranz
  2. Apple Watch Series 5 im Test Endlich richtungsweisend
  3. Suunto 5 Sportuhr mit schlauem Akku vorgestellt

Elektromobilität: Diese E-Autos kommen 2020 auf den Markt
Elektromobilität
Diese E-Autos kommen 2020 auf den Markt

Bei Käufern wird die höhere Umweltprämie, bei den Herstellern werden die strengeren CO2-Grenzwerte die Absatzzahlen von Elektroautos ankurbeln. Interessenten haben 2020 eine noch größere Auswahl, hier ein Überblick über die Neuerscheinungen.
Ein Bericht von Dirk Kunde

  1. Mercedes E-Econic Daimler elektrifiziert den Müllwagen
  2. Umweltprämie für Elektroautos Regierung verzögert Prüfung durch EU-Kommission
  3. Intransparente Preise Verbraucherschützer mahnen Ladenetzbetreiber New Motion ab

  1. Stuttgart: Vodafone bringt LTE im UMTS-Bereich in die U-Bahn
    Stuttgart
    Vodafone bringt LTE im UMTS-Bereich in die U-Bahn

    Stuttgart erhält besseres Netz in der U-Bahn durch LTE bei 2.100 MHz. Vodafone hat hier die Projektführung. Der Bereich war eigentlich für den UMTS-Betrieb vorgesehen.

  2. Gegen Huawei: Telefónica Deutschland setzt auf Open-RAN-Architektur
    Gegen Huawei
    Telefónica Deutschland setzt auf Open-RAN-Architektur

    Auch wenn Telefónica Deutschland Huawei verteidigt, will man gerne unabhängig werden. Dafür will der Konzern auch in Deutschland Open RAN einsetzen.

  3. 10-nm-Prozessor: Intel-Benchmarks zeigen Ice-Lake-Rückstand
    10-nm-Prozessor
    Intel-Benchmarks zeigen Ice-Lake-Rückstand

    Eigentlich wollte Intel demonstrieren, wie viel besser die eigenen Ultrabook-Chips verglichen mit AMDs (alten) Ryzen-Modellen abschneiden. Dabei zeigt sich aber auch, dass die 10-nm-Ice-Lake-Prozessoren zumindest CPU-seitig langsamer sind als ihre 14-nm-Comet-Lake-Pendants.


  1. 19:02

  2. 18:14

  3. 17:49

  4. 17:29

  5. 17:10

  6. 17:01

  7. 16:42

  8. 16:00