Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › DoH-Standard: DNS über HTTPS ist…

Gut, dass der Artikel nur eine Seite beleuchtet

  1. Thema

Neues Thema Ansicht wechseln


  1. Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: Vanger 19.07.19 - 14:01

    Wäre ja schlimm wenn man sich mit den Argumenten der Gegenseite außeinander setzen müsste...

    - DNS ist dezentral organisiert - DOH ist zentralisiert.
    - DOH hat gigantische Datenschutz-Probleme, da alle Anfragen aller Nutzer bei einem Anbieter landen.
    - DNS hat in Anwendungen nichts zu suchen - DNS ist Aufgabe des OS.
    - DOH hat im Unternehmensumfeld massive Probleme, Stichwort Intranet.
    - DNS ist ein schlankes Protokoll - DOH ist ein fettes Monstrum. Das Argument, man könnte für HTTPS ja Libraries wie curl verwenden, DOH seien nur 1000 Zeilen Code ist absurd - zum Eisberg gehört auch alles was unter der Wasserlinie liegt.
    - DOH führt eine üble Propagandaschlacht.

    Zu letzterem Punkt zählt auch dieser Artikel. Die Vertreter von DOH verkürzen, ignorieren Gegenargumente, bringen vollkommen absurde und realitätsferne Argumente. Verglichen wird DOH dann immer mit "Vanilla DNS". Jeder der gegen DOH ist, sei ja gegen Verschlüsselung von DNS. Schwachsinn! Die Alternative zu DOH ist DOT. DOT *ist* schlank. DOT ist die richtige Lösung weil sie das Problem adressiert - und nicht noch drum herum bloated. DOH ist ein Irrweg von Leuten, deren Weltbild bei "HTTP ist cool, lasst uns alles über HTTP machen!" aufhört.

  2. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: aGYtAhEeQKWb 19.07.19 - 14:36

    Die Behauptung das DOH zentralisiert wäre ist totaler Unfug. Es ist im Prinzip genauso wie bei einem normalen DNS Server auch. Jeder kann theoretisch einen eigenen betreiben und nur weil Firefox aktuell als Vorschlag zum testen nur den von Cloudflare vorschlägt ändert das nichts daran.
    Außerdem stimmt es auch nicht dass es deswegen im Unternehmensumfeld massive Probleme gäbe. Jedes Unternehmen kann seinen eigenen Server betreiben oder per Richtlinie die Nutzung von DOH verbieten.
    Außerdem hat die Nutzung von HTTPS durchaus einen Sinn. Anders als DOT lässt sich DOH nicht einfach vom Internetanbieter oder vom Staat blockieren. Selbst in einem Land wie Deutschland haben wir bereits DNS Sperren und es ist nur eine Frage der Zeit bis die Politik fordern wird die Nutzung alternativer DNS Server zu verbieten.

  3. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: nikeee13 19.07.19 - 18:23

    So viel man auch gegen DoH haben kann, aber deine ersten beiden Punkte sind nicht gültig.

  4. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: Vanger 19.07.19 - 23:35

    > Die Behauptung das DOH zentralisiert wäre ist totaler Unfug. Es ist im
    > Prinzip genauso wie bei einem normalen DNS Server auch. Jeder kann
    > theoretisch einen eigenen betreiben und nur weil Firefox aktuell als
    > Vorschlag zum testen nur den von Cloudflare vorschlägt ändert das nichts
    > daran.

    Dass es *theoretisch* möglich ist auch einen anderen DOH-Server zu nutzen ist vollkommen irrelevant wenn das in der Praxis nicht passiert. E-Mail-Verschlüsselung funktioniert theoretisch auch, trotzdem nutzt sie kaum einer. Fakt ist, dass nach aktuellem Stand jeder Benutzer *selbst* aktiv werden muss um den DOH-Server zu ändern. Fakt ist auch, dass es neben Cloudflare und Google keine Alternative gibt die unter den DOH-Testern eine Rolle spielen würde. Die Pläne von Mozilla sehen aktuell vor, dass je nach Region unterschiedliche DOH-Server-Listen verteilt werden. Allen ist gemein, dass wir über einige wenige Server sprechen über die die DNS-Abfragen von Millionen Personen abgewickelt werden. Das sind tolle Angriffspunkte. Sowohl für Kriminelle als auch für die Politik.

    > Außerdem stimmt es auch nicht dass es deswegen im Unternehmensumfeld
    > massive Probleme gäbe. Jedes Unternehmen kann seinen eigenen Server
    > betreiben oder per Richtlinie die Nutzung von DOH verbieten.

    DOH ist schon ein außerordentlich genialer Ansatz wenn die Lösung für ein dermaßen alltägliches Problem ist, DOH zu deaktivieren. You played yourself.

    > Außerdem hat die Nutzung von HTTPS durchaus einen Sinn. Anders als DOT
    > lässt sich DOH nicht einfach vom Internetanbieter oder vom Staat
    > blockieren. Selbst in einem Land wie Deutschland haben wir bereits DNS
    > Sperren und es ist nur eine Frage der Zeit bis die Politik fordern wird die
    > Nutzung alternativer DNS Server zu verbieten.

    Das ist ein immer und immer wieder vorgebrachtes Argument, das schlicht und ergreifend nicht stichhaltig ist. Staaten die Internetzensur betreiben haben auch heute schon nicht wirklich ein Problem damit HTTPS aufzubrechen - ein Blick nach China genügt. Diese Staaten haben absolut kein Problem damit auch Cloudflare zu blocken. Diese Staaten wissen, dass Cloudflare als gewinnorientiertes Unternehmen einknicken wird - so wie es alle anderen Unternehmen, auch Google, vor ihnen schon getan haben. Dass Internetanbieter in Deutschland anfangen könnten DNS-Requests zu blocken ist eine vollkommen absurde Behauptung ohne auch nur die geringste Grundlage. Das DNS zu blockieren kommt einer vollständigen Blockade des Internetzugangs gleich - das ist absurd. DOH ist durch seine zentrale Infrastruktur darüber hinaus sehr, sehr viel anfälliger für Zensur als die klassische DNS-Infrastruktur, dessen Betrieb auf tausenden von unterschiedlichen Schultern verteilt ist. Die NSA freut sich.



    2 mal bearbeitet, zuletzt am 19.07.19 23:40 durch Vanger.

  5. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: Tuxgamer12 20.07.19 - 12:40

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > Die Alternative zu DOH ist DOT. DOT *ist* schlank. DOT ist die richtige
    > Lösung weil sie das Problem adressiert - und nicht noch drum herum bloated.

    Nur mal so: DoT nach rfc7858 und rfc8310 bezieht sich genauso nur auf Client <-> Recursive Resolver.
    Auch wenn expliziet nicht ausgeschlossen wurde, dass DoT zukünftig auch im "eigentlichen" dezentralen DNS-System verwendet werden könnte, ist mir nicht bekannt, dass sich etwas in dieser Richtung tut. Oder ist mir da etwas entgangen?

    Das ist deswegen interessant, weil demnach Punkt 1 und 2 deiner Kritik 1:1 für DoT im jetzigen Zustand gelten.

    Auf Punkte 3 und 4 ist der Artikel entgegen deiner Behauptungen eingegangen. Hast vielleicht nicht bis zur Seite 3 gelesen?

    > - DNS ist ein schlankes Protokoll - DOH ist ein fettes Monstrum. Das
    > Argument, man könnte für HTTPS ja Libraries wie curl verwenden, DOH seien
    > nur 1000 Zeilen Code ist absurd - zum Eisberg gehört auch alles was unter
    > der Wasserlinie liegt.

    Ah, und im Detail ist "absurd" sein vorhandenen, gut funktionierenden Code (der sowieso da ist) wiederzuverwenden - für entsprechende Vorteile, insbesonderen Performance.

    Denn ja: DoH ist einfach performanter als DoT; insbesonderen später mit HTTP/3. Denn das ist ja der hauptsächliche Grund für die Weiterentwicklung von HTTP: Jedes bisschen Performance herauszukitzeln. Und ja: DNS ist wahnsinnig performance-kritisch.

  6. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: Vanger 20.07.19 - 13:45

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Nur mal so: DoT nach rfc7858 und rfc8310 bezieht sich genauso nur auf
    > Client <-> Recursive Resolver. [...]
    >
    > Das ist deswegen interessant, weil demnach Punkt 1 und 2 deiner Kritik 1:1
    > für DoT im jetzigen Zustand gelten.

    Mit dem klitzekleinen Unterschied, dass jeder DNS-Server und -Client DOT mit tatsächlich sehr wenigen Zeilen Code nachrüsten kann - und zwar nicht indem man absurderweise behauptet, dass die Integration von curl nicht die Komplexität erhöhe, weil diese zehntausenden Zeilen Code (inzwischen vielleicht schon sechsstellig?) in der Library stecken (mit dieser aberwitzigen Argumentation kann ich aus einem Millionen-Zeilen-Projekt ein 10-Zeilen-Projekt machen - einfach alles in eine "Library" verschieben, übrig bleiben die 10 Zeilen für den Import der "Library"). TLS ist schon im Kernel integriert. HTTP nicht (Gott bewahre...).

    Im Unterschied zu DOH gibt es für DOT auch schon DNS-Clients und Server die genau das getan haben: DOT mit wenigen Zeilen Code nachrüsten. Das arbeitet dann auf Ebene des OS. Für alle Applikationen. Nicht auf Applikationsebene. Namensauflösung ist nicht Aufgabe einer einzelnen Applikation.

    > Ah, und im Detail ist "absurd" sein vorhandenen, gut funktionierenden Code
    > (der sowieso da ist) wiederzuverwenden - für entsprechende Vorteile,
    > insbesonderen Performance.

    curl ist "sowieso schon da"? Wo? Welche DNS-Clients und -Server binden curl denn heute schon ein?

    > Denn ja: DoH ist einfach performanter als DoT; insbesonderen später mit
    > HTTP/3. Denn das ist ja der hauptsächliche Grund für die Weiterentwicklung
    > von HTTP: Jedes bisschen Performance herauszukitzeln. Und ja: DNS ist
    > wahnsinnig performance-kritisch.

    HTTP ist ein verflucht langsames und ineffizientes Protokoll. Wenn du ein bisschen Goldstaub auf einen Haufen Hundekot streust ist es trotzdem noch Hundekot.

    Du bist offensichtlich der Falschannahme anheim gefallen, dass HTTP/3 irgendwie exklusiv Quic verwenden würde. Quic ist einfach nur UDP+TLS. Welche Daten darüber versendet werden ist vollkommen irrelevant. Man kann da auch direkt DNS-Payloads drüber senden. Dazu braucht man keine HTTP-Zwischensicht.

    Oder um mal die Komponenten von DOT und DOH ab OSI-Schicht 4 darzustellen:

    DOH heute = TCP + TLS + HTTP + DNS
    DOH mit Quic (HTTP/3) = UDP + TLS + HTTP + DNS

    DOT heute = TCP + TLS + DNS
    DOT mit Quic = UDP + TLS + DNS

    Solange du nicht die Quadratur des Kreises hinbekommst wird DOH immer komplexer als DOT sein, weil es mit HTTP eine vollkommen unnötige Zwischenebene einfügt. HTTP beschleunigt nichts, HTTP verlangsamt das ganze Prozedere. Sogar sehr massiv - was der unglaublichen und für DNS vollkommen unnötigen Komplexität von HTTP geschuldet ist.

  7. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: Tuxgamer12 20.07.19 - 19:27

    Vanger schrieb:
    --------------------------------------------------------------------------------
    >> Nur mal so: DoT nach rfc7858 und rfc8310 bezieht sich genauso nur auf
    >> Client <-> Recursive Resolver. [...]
    >
    > > Das ist deswegen interessant, weil demnach Punkt 1 und 2 deiner Kritik 1:1
    >> für DoT im jetzigen Zustand gelten.
    > Mit dem klitzekleinen Unterschied, dass jeder DNS-Server und -Client DOT mit
    > tatsächlich sehr wenigen Zeilen Code nachrüsten kann

    Was hast du denn an dieser Stelle zitiert? Und wie geantwortet?

    Noch einmal: Punkt ist, dass DoT zur Zeit exakt wie DoH abläuft. Du schnappst dir einen Public DNS-Server, wie den von Google oder Cloudflare. Und baust zu dem eine verschlüsselte Verbindung auf.

    Irgendetwas in Richtung "clientseitig rekursiv DNS auflösen über DoT" ist mir nichts bekannt. Lasse mich aber gerne aufklären.

    > Im Unterschied zu DOH gibt es für DOT auch schon DNS-Clients und Server die
    > genau das getan haben: DOT mit wenigen Zeilen Code nachrüsten.

    Wie z.B. der unbound.

    Schon mal verwendet? Weißt du, was die geschafft haben? Für jeden DNS-Request wird eine neue Verbindung geöffnet. Jede DNS-Abfrage ein TCP+TSL Handshake. Geil! Es ist so lahmarschig.

    Übrigens heute nicht anders. Müssen wir eben warten, bis das entsprechend implementiert ist - können ja issue hier verfolgen: https://github.com/NLnetLabs/unbound/issues/47

    Tja, anstatt sich zu freuen, dass die entsprechende HTTP-Bibliothek bereits ziemlich gutes Resourcenmanagement betreibt.

    > DOT mit Quic = UDP + TLS + DNS

    Mit dem Unterschied, dass das erst spezifizert werden muss. Und dann entsprechend implementiert werden muss. Und sich dann durchsetzen muss. Und du weißt, wie das laufen kann - völlig offen, ob das überhaupt zeitnah passieren wird.

    Wohingegen DoH - völlig egal, was HTTP-Ebene oder darunter gesprochen wird. Alles, was HTTP für Verbesserungen kommen ist automatisch im DoH.

    > Das arbeitet
    > dann auf Ebene des OS. Für alle Applikationen. Nicht auf Applikationsebene.
    > Namensauflösung ist nicht Aufgabe einer einzelnen Applikation.

    Nur mal so: Außerhalb des Windows (?) ist und war DNS schon immer userspace direkt in der Anwendung...

    Linux üblicherweise im glibc 'getaddrinfo' und 'getnameinfo' - was dann /etc/resolv.conf ließt um den Systemweiten DNS-Server herauszufinden. Also eine Form von /etc/resolv.conf für DoH wäre vielleicht eine Idee.
    Gut und häufiger findet sich /etc/resolv.conf dann 127.0.0.1 - und lokal läuft ein DNS-Server zum cached und die Anfragen weiterleitet. Wobei es da übrigens keinen Unterschied gibt, ob die Anfragen DoT, DoH oder unverschlüsselt weitergeleitet werden.

  8. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: ikhaya 20.07.19 - 19:35

    https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
    hat auch Verbesserungen dafür im Angebot:
    TCP fast open
    Connection reuse
    Pipelining of queries
    Process OOOR
    EDNS0 Keepalive
    Man muss sie halt nur einbauen.

  9. Re: Gut, dass der Artikel nur eine Seite beleuchtet

    Autor: Tuxgamer12 20.07.19 - 20:24

    ikhaya schrieb:
    --------------------------------------------------------------------------------
    > dnsprivacy.org

    Danke - sehr guter Link!

    > Man muss sie halt nur einbauen.

    Letztendlich ist es aber schon lustig, wie DoH Komplexität vorgeworfen wird - und man im nächsten Schritt doch feststellt, was alles noch implementiert werden müsste.
    Im Vergleich: Bibliothek einbinden - und mit 1000 Zeilen ist man fertig. Punkt. Mit den ganzen Optimierungen - teils sogar durchaus umfangreicher als das für DoT implementiert wird.

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Technische Universität München, München
  2. Athmer oHG, Arnsberg-Müschede
  3. IGEL Technology GmbH, Augsburg
  4. ARI Fleet Germany GmbH, Eschborn, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 199,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektromobilität: Die Rohstoffe reichen, aber ...
Elektromobilität
Die Rohstoffe reichen, aber ...

Brennstoffzellenautos und Elektroautos sollen künftig die Autos mit Verbrennungsantrieb ersetzen und so den Straßenverkehr umweltfreundlicher machen. Dafür sind andere Rohstoffe nötig. Kritiker mahnen, dass es nicht genug davon gebe. Die Verfügbarkeit ist aber nur ein Aspekt.
Eine Analyse von Werner Pluta

  1. Himo C16 Xiaomi bringt E-Mofa mit zwei Sitzplätzen für rund 330 Euro
  2. ADAC-Test Hohe Zusatzkosten bei teuren Wallboxen möglich
  3. Elektroroller E-Scooter sollen in Berlin nicht mehr auf Gehwegen parken

Hyundai Kona Elektro: Der Ausdauerläufer
Hyundai Kona Elektro
Der Ausdauerläufer

Der Hyundai Kona Elektro begeistert mit Energieeffizienz, Genauigkeit bei der Reichweitenberechnung und umfangreicher technischer Ausstattung. Nur in Sachen Emotionalität und Temperament könnte er etwas nachlegen.
Ein Praxistest von Dirk Kunde

  1. Elektroauto Neuer Chevrolet Bolt fährt 34 km weiter
  2. Elektroauto Porsches Elektroauto Taycan im 24-Stunden-Dauertest
  3. Be emobil Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt

Zephyrus G GA502 im Test: Das Gaming-Notebook, das auch zum Arbeiten taugt
Zephyrus G GA502 im Test
Das Gaming-Notebook, das auch zum Arbeiten taugt

Mit AMDs Ryzen 7 und Nvidia-GPU ist das Zephyrus G GA502 ein klares Gaming-Gerät. Überraschenderweise eignet es sich aber auch als mobiles Office-Notebook. Das liegt an der beeindruckenden Akkulaufzeit.
Ein Test von Oliver Nickel

  1. Vivobook (X403) Asus packt 72-Wh-Akku in günstigen 14-Zöller
  2. ROG Swift PG35VQ Asus' 35-Zoll-Display nutzt 200 Hz, HDR und G-Sync
  3. ROG Gaming Phone II Asus plant neue Version seines Gaming-Smartphones

  1. UMTS: 3G-Abschaltung kein Thema für die Bundesregierung
    UMTS
    3G-Abschaltung kein Thema für die Bundesregierung

    Nutzer, die kein LTE in ihren Verträgen festgeschrieben haben, sollten wechseln, da 3G zunehmend abgeschaltet werde. Das erklärte das Bundesverkehrsministerium und sieht keinen Grund zum Eingreifen.

  2. P3 Group: Wo die Mobilfunkqualität in Deutschland am niedrigsten ist
    P3 Group
    Wo die Mobilfunkqualität in Deutschland am niedrigsten ist

    Die Qualität des Mobilfunks in Deutschland ist in den einzelnen Bundesländern sehr unterschiedlich. Dort, wo Funklöcher gerade ein wichtiges Thema sind, ist die Versorgung gar nicht so schlecht.

  3. Mecklenburg-Vorpommern: Funkmastenprogramm verzögert sich
    Mecklenburg-Vorpommern
    Funkmastenprogramm verzögert sich

    Wegen fehlender Zustimmung der EU ist das Geld für ein Mobilfunkprogramm in Mecklenburg-Vorpommern noch nicht verfügbar. Dabei hat das Bundesland laut einer P3-Messung große Probleme.


  1. 18:00

  2. 18:00

  3. 17:41

  4. 16:34

  5. 15:44

  6. 14:42

  7. 14:10

  8. 12:59