Qgelm

Verbesserte Namensauflösung: IETF veröffentlicht RFC zum Internetprotokoll QUIC

Originalartikel

Backup

<html> <header class=„article-header“><h1 class=„articleheading“>Verbesserte Namensaufl&#246;sung: IETF ver&#246;ffentlicht RFC zum Internetprotokoll QUIC</h1><div class=„publish-info“> Benjamin Pfister</div></header><figure class=„aufmacherbild“><img src=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/5/4/5/9/3/2/shutterstock_2023520396.jpg-0ddafc5427629e0f.jpeg“ srcset=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/5/4/5/9/3/2/shutterstock_2023520396.jpg-0ddafc5427629e0f.jpeg 700w, https://heise.cloudimg.io/width/1050/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/5/4/5/9/3/2/shutterstock_2023520396.jpg-0ddafc5427629e0f.jpeg 1050w, https://heise.cloudimg.io/width/1500/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/5/4/5/9/3/2/shutterstock_2023520396.jpg-0ddafc5427629e0f.jpeg 1500w, https://heise.cloudimg.io/width/2300/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/5/4/5/9/3/2/shutterstock_2023520396.jpg-0ddafc5427629e0f.jpeg 2300w“ alt=„“ class=„img-responsive“ referrerpolicy=„no-referrer“ /><figcaption class=„akwa-caption“>(Bild:&#160;Anterovium/Shutterstock.com)</figcaption></figure><p><strong>Der neue RFC der Internet Engineering Task Force nutzt die integrierte Verschl&#252;sselung und bessere Geschwindigkeit von QUIC f&#252;r die Namensaufl&#246;sung.</strong></p><p>Die Internet Engineering Task Force (IETF) hat den RFC 9250 zu DNS over QUIC (DoQ) ver&#246;ffentlicht. Er verspricht eine bessere Namensaufl&#246;sung bei h&#246;herer Geschwindigkeit. Seit geraumer Zeit schon werden Verschl&#252;sselungsprotokolle f&#252;r die Namensaufl&#246;sung (DNS) kontrovers diskutiert, darunter DNS over TLS (DoT) und DNS over HTTPS (DoH). Mit dem noch recht jungen Protokoll <a class=„heiseplus-lnk“ href=„https://www.heise.de/hintergrund/Internet-QUIC-Standardisierung-durch-die-Internet-Engineering-Task-Force-6120835.html“><strong>QUIC [1]</strong></a> m&#246;chte die IETF nun dessen positiven protokollinh&#228;renten Eigenschaften f&#252;r die Namensaufl&#246;sung nutzen.</p><p>Dabei sollen die integrierte TLS-1.3-Verschl&#252;sselung f&#252;r verbesserten Datenschutz und die optimierte Latenz im Verbindungsaufbau (im Vergleich zu klassischem TLS &#252;ber TCP) die Namensaufl&#246;sung positiv beeinflussen. Der RFC 9250 definiert au&#223;erdem unterschiedliche Anwendungszwecke im DNS f&#252;r DoQ: „Stub to recursive Resolver“-, „recursive to authoritative“- und Zonentransferszenarien.</p><h3 class=„subheading“ id=„nav_kein0“>Kein Head-of-Time Blocking</h3><p>Das auf UDP aufbauende QUIC-Protokoll bietet einige interessante Eigenschaften f&#252;r die DNS-&#220;bertragung. So gibt es bei DoQ kein Head-of-Line Blocking wie bei DNS over TCP bei gr&#246;&#223;eren &#220;bertragungen. Jede Anfrage/Antwort-Transaktion wird einem separaten Stream zugeordnet. Somit kann eine fehlende Antwort folgende Abfragen nicht ausbremsen. Der Client w&#228;hlt daf&#252;r jeweils einen dedizierten Stream f&#252;r jede Anfrage.</p><p>Zudem sollen Client und Server es erm&#246;glichen, eine Verbindung wiederzuverwenden, indem sie multiple Anfragen und Antworten &#252;ber eine persistente QUIC Connection versenden. Es muss also im Normalfall kein zus&#228;tzlicher QUIC-Handshake stattfinden. Clients, die mehrere Anfragen an einen DNS-Server versenden, sollen nicht auf eine ausstehende Antwort warten, bevor sie eine weitere Anfrage senden.</p><p>DoQ enth&#228;lt einen dedizierten UDP-Port mit der Nummer 853. Jedoch k&#246;nnen sich Client und Server gem&#228;&#223; Spezifikation auch auf andere Ports einigen, wobei UDP-Port 53 wegen Verwechslungsgefahr mit DNS over UDP nicht zul&#228;ssig ist. Die Unterst&#252;tzung f&#252;r DoQ erfolgt auf Basis des Application-Layer Protocol Negotiation (ALPN) Token „doq“ im Crypto-Handshake. Falls die DoQ-Verbindung fehlschl&#228;gt, k&#246;nnen Clients auf DoT und in Folge auf Klartext&#252;bertragung zur&#252;ckfallen. Der Client sollte sich jedoch Server-IP-Adressen merken, die DoQ nicht umsetzen.</p><p>Obwohl QUIC-Pakete verschl&#252;sselt sind, k&#246;nnen Protokollanalysen aus der Paketl&#228;nge in Anfragen und Antworten sowie deren Timing erkennen, dass es sich um DoQ handelt. Deshalb empfiehlt es sich, Padding gem&#228;&#223; der EDNS-Padding-Option oder QUIC Padding anzuwenden.</p><h3 class=„subheading“ id=„nav_vorteil1“>Vorteil: verbesserter Datenschutz</h3><p>Die in QUIC integrierte TLS-1.3-Verschl&#252;sselung bietet einen verbesserten Datenschutz und sch&#252;tzt auch standardm&#228;&#223;ig bereits gegen Downgrade-Attacken. Bei langlebigeren Sessions hat QUIC den Vorteil, dass Quell-IPs am Client w&#228;hrend der &#220;bertragung wechseln k&#246;nnen. Dadurch entkoppelt es die &#220;bertragung der IP-Adressen und nutzt Connection-IDs und die darin enthaltenen Streams.</p><p>DoQ enth&#228;lt im Vergleich zu UDP aber auch eine effizientere Korrektur bei Paketverlusten, die sich aus dem QUIC-Protokoll und RFC 9002 (QUIC Loss Detection and Congestion Control) ergeben. Zudem gibt es zum Schutz gegen Amplification-Attacken eine bessere Quell-IP-Validierung als bei DNS over UDP.</p><p>Einen weiteren Vorteil im Vergleich zu klassischen verschl&#252;sselten DNS-Verschl&#252;sselungsmethoden stellt das 0-RTT Feature (Zero Round Trip Time) von QUIC f&#252;r die Wiederaufnahme vorheriger Sessions ohne zus&#228;tzlichen Handshake dar. Hierdurch verringert sich die Latenz bei Anfragen an den gleichen DNS-Server im Vergleich zum Aufbau neuer Sessions inklusive zugeh&#246;riger TLS-Aushandlungen, sei es f&#252;r DoT oder DoH.</p><h3 class=„subheading“ id=„nav_zus&#228;tzliche2“>Zus&#228;tzliche Geschwindigkeit</h3><p>DoQ soll den Datenschutz von DNS over TLS mit den positiven Latenzeigenschaften von klassischem DNS over UDP kombinieren. Gleichzeitig m&#246;chten die Protokolldesigner jedoch eine direktere Alternative als bei DNS over HTTPS nutzen. Zwar setzt das neue <a href=„https://www.heise.de/select/ix/2021/4/2105609294679118839“><strong>HTTP/3 [2]</strong></a> auch auf QUIC auf, jedoch w&#252;rde bei einer DoH-&#220;bertragung mit HTTP/3 ein zus&#228;tzlicher Layer f&#252;r das Hypertext Transport Protocol hinzukommen, was zus&#228;tzlichen Overhead und Komplexit&#228;t einf&#252;gt. Daher soll DoQ die direktere Alternative darstellen.</p><p>Wie bei allen RFCs bleibt nun abzuwarten, ob und wann es Praxisimplementierungen gibt. Weitere Details zu DNS over QUIC (DoQ) finden sich im <a href=„https://www.rfc-editor.org/rfc/rfc9250.html“ rel=„external noopener“ target=„_blank“><strong>RFC-Editor [3]</strong></a> des IETF.</p><p>() </p><hr /><p><strong>URL dieses Artikels:</strong><br /><small>

https://www.heise.de/-7097921

</small></p><p><strong>Links in diesem Artikel:</strong><br /><small>

<strong>[1]</strong>&#160;https://www.heise.de/hintergrund/Internet-QUIC-Standardisierung-durch-die-Internet-Engineering-Task-Force-6120835.html

</small><br /><small>

<strong>[2]</strong>&#160;https://www.heise.de/select/ix/2021/4/2105609294679118839

</small><br /><small>

<strong>[3]</strong>&#160;https://www.rfc-editor.org/rfc/rfc9250.html

</small><br /><small>

<strong>[4]</strong>&#160;https://www.heise.de/ix/

</small><br /></p><p class=„printversion__copyright“><em>Copyright &#169; 2022 Heise Medien</em></p> </html>

Cookies helfen bei der Bereitstellung von Inhalten. Diese Website verwendet Cookies. Mit der Nutzung der Website erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Computer gespeichert werden. Außerdem bestätigen Sie, dass Sie unsere Datenschutzerklärung gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information