DoH – DNS over HTTPS #05

Zusammen mit Carsten Strotmann erörtere ich den Bereich der verschlüsselten DNS-Kommunikation: Wer braucht warum Verschlüsselung? Vor wem schützen wir uns? Wie funktioniert es technisch? Wie lief die Entwicklung ab und warum stehen wir heute hier und nicht woanders? Und auch: Was sind die Nachteile von verschlüsseltem DNS-Verkehr, vor allem aus Firmensicht?

Im Kern geht es um DoH – DNS over HTTPS. Aber auch DoT (DNS over TLS) und DoQ (DNS over QUIC) spielen historisch eine Rolle.

Zuletzt (und anfangs) haben wir noch weitere Themen rund um den Betrieb einer sicheren DNS-Infrastruktur besprochen.

Links:

Tooltipp von Carsten: delv, man-page, Dive into delv: DNSSEC Validation, dnssec validation / authoritative server

Musiktipp von Carsten: Album Dreamension by Fleesh

Audio-Postproduktion: Leon Dietsch, https://leon.audio/

Soli Deo Gloria!

Security-as-a-Podcast
Security-as-a-Podcast
DoH – DNS over HTTPS #05
Loading
/

Kommentare

3 Kommentare zu „DoH – DNS over HTTPS #05“

  1. Avatar von Lukas Liebig

    Hi Johannes, mit etwas Verspätung habe ich nun endlich auch diese Folge angehört. Danke für die interessanten Einblicke!

    Ein paar Anmerkungen:
    1) DNS Wasserfolter: Ja, so wie ihr das erklärt habt, implementieren NSEC und NSEC3 Records einen DDoS-Schutz für Resolver und authoritative DNS-Server. Ein findiger Angreifer könnte aber auf die Idee kommen, einen eigenen Open Source Resolver seiner Wahl aufzusetzen, der im Quellcode derart manipuliert ist, dass er die NSEC Records nicht cacht. (Bzw. kann man aggressive NSEC ja sicher auch de-konfigurieren.) Dann fragt er einfach immer über seinen (oder mehrere seiner) Resolver an und kann auf diese Weise dennoch versuchen, den authoritativen Server zu DDoS-en. Und da die Angreifer immer den für uns unbequemsten Weg gehen, würde ich soweit gehen, zu sagen, dass dieser DDoS-Schutz von DNSsec daher defacto nur für die Resolver-Infrastruktur wirkt, aber nicht für authoritative Server. Wie siehst du das?

    2) Am meisten verwirrt mich noch immer das Dilemma mit den Port-Nummern der Protokolle und wo man das jeweils konfiguriert… Wie ich hörte, geht es dir ähnlich.
    – DoT: TCP Port 853, wird konfiguriert auf OS-Ebene
    – DoH: TCP Port 443, wurde historisch pro App konfiguriert, mittlerweile aber auch auf OS-Ebene konfigurierbar
    – DoH3 (bzw. ehemals DoQ): UDP Port 443 – Wo konfiguriert man das jetzt wieder? Vermutlich auch auf App- und OS-Ebene möglich?!
    – UDP Port 853 ist laut IANA zugewiesen an „DNS query-response protocol run over DTLS or QUIC“ (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=853) – Das verwirrt mich jetzt wieder: Carsten sagte ja deutlich, dass man DNS over QUIC nicht mehr benutzt. Aber da QUIC der Vorläufer von HTTP3 ist, hätte ich DoQ doch auf UDP Port 443 einsortiert und nicht auf 853. Warum hat es die IANA dennoch so gemacht?! (Ich glaube du hattest in der Folge auch die Annahme DoQ=UDP Port 853 geäußert.) Für DNS-over-DTLS macht Port 853 natürlich wieder Sinn. Ist ja einfach das UDP-Pendant zu DoT und hier ist ja kein HTTP im Spiel. Hat dann aber auch die gleichen Blocking-Probleme wie DoT…

    Alles sehr interessant, aber man muss schauen, dass man den Überblick behält. 🙂

    Grüße,
    Lukas

  2. Avatar von Lukas Liebig

    Was ja übrigens auch Thema war: HTTP3 gibt es nur verschlüsselt. HTTP2 hingegen auch unverschlüsselt (nennt sich dann h2c – http2 cleartext). Das wollte ich mir mal ansehen, dabei ist mir aufgefallen, dass du ja gar kein HTTP2 im UltimatePCAP hast!?!

    Hier gibt es HTTP2 und h2c Captures: https://wiki.wireshark.org/http2

    1. Avatar von Johannes Weber

      Ja, das ist dir (leider) gut aufgefallen. 😉 Steht schon länger auf meiner Liste. Ich habe für den Podcast hier übrigens eine eigene Folge zu genau diesem Thema, also HTTP/2 und HTTP/3 geplant.

      Beim Ultimate PCAP hatte ich mir damals selbst auferlegt, dass ich nur Protokolle aufnehme, die ich selber schon gesehen und auch selbst mitgeschnitten habe. Daher finden sich dort keine „geklauten“ PCAPs. Das ist auch der Grund, warum mir nach wie vor VXLAN usw. fehlt. Steht ebenso auf der Liste.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert