HTTPS Resource Record
Der HTTPS Resource Record ist eine Form eines Resource Records im Domain Name System. Er dient als ein Signal an den Webbrowser, dass eine Verbindung über das Hypertext Transfer Protocol (HTTP) zu einem Webserver verschlüsselt per HTTPS zu erfolgen hat. Der HTTPS Resource Record wurde im November 2023 von der Internet Engineering Task Force im RFC 9460[1] veröffentlicht. Das Request for Comments hat den Status eines vorgeschlagenen Standards.
Überblick
[Bearbeiten | Quelltext bearbeiten]Beim HTTPS Resource Record handelt es sich um Variante des allgemeinen SVCB Resource Record (Service Binding) speziell für HTTP.[2] Ein Service Binding ermöglicht die Bereitstellung eines Netzwerkdiensts unter einer anderen Serveradresse als dem veröffentlichten Domainnamen. In dieser Funktion ähnelt der SVCB Resource Record dem SRV Resource Record.[3] Zusätzlich können beim SVCB Resource Record Verbindungsparameter mitgeteilt werden, beispielsweise das zu verwendende Transportprotokoll.
Der HTTPS Resource Record unterstützt die Funktionalität der Service Bindings und verfolgt zusätzlich folgende Zielsetzung:[4]
- Direkter Verbindungsaufbau per HTTP/3 über QUIC, ohne zuvor eine HTTP-Anfrage über das Transmission Control Protocol absetzen zu müssen.
- Unterstützung von nicht standardmäßigen TCP- oder UDP-Ports.
- Signalisierung, dass HTTPS verwendet werden soll, was dem Zweck von HTTP Strict Transport Security ähnelt.
- Möglichkeit zur Signalisierung eines Schlüssels zur Verwendung bei der TLS-Erweiterung Encrypted Client Hello.
Daneben unterstützt der HTTPS Resource Record auch einen Alias-Modus, was der Funktion eines CNAME Resource Record entspricht. Anders als bei CNAME ist das Aliasing aber auch für eine Basisdomain wie beispielsweise example.com möglich. Damit entfällt die Notwendigkeit für Behelfslösungen (ANAME, ALIAS), die von manchen Cloudanbietern verwendet werden.[5]
Aufbau
[Bearbeiten | Quelltext bearbeiten]Der Aufbau eines HTTPS Resource Records folgt dem folgenden Schema:[6]
- Name
- Domainname der Website
- TTL
- Time to Live: maximale Caching-Zeit
- IN
- Klasse Internet (konstanter Wert)
- HTTPS
- Typ des Resource Records
- SvcPriority
- Priorität des Eintrags (kleiner Wert = höhere Priorität), falls mehrere Einträge vorhanden sind. Der Wert 0 signalisiert die Verwendung des Alias-Modus.[7]
- TargetName
- Hostname des Webservers. Der Wert „.“ bedeutet, dass der Hostname dem Domainnamen der Website entspricht.
- SvcParams
- Liste von definierten Parametern nach dem Schema „key=value“. Der Wert kann bei einigen Parametertypen leer sein. Als Trenner zwischen zwei Parametern dient das Leerzeichen.
Beispiele
[Bearbeiten | Quelltext bearbeiten]example.com. 300 IN HTTPS 10 backup01.example.com. example.com. 300 IN HTTPS 20 backup02.example.net. example.com. 300 IN HTTPS 30 backup03.example.de.
In dem obigen Beispiel sind für die Website example.com drei verschiedene Server mit unterschiedlicher Priorität definiert. Ein Webbrowser, der den HTTPS Resource Record unterstützt, versucht zuerst den Verbindungsaufbau zu backup01.example.com. Nur falls diese Verbindung fehlschlägt, erfolgt der Verbindungsversuch zum nächsten Server.[5]
example.com. 300 IN HTTPS 1 . alpn="h3,h2"
In dem obigen Beispiel ist mit „.“ keine zum Domainnamen example.com abweichende Serveradresse definiert. Über den Parameter „alpn“ wird aber dem Webbrowser mitgeteilt, dass HTTP/3 bevorzugt zu verwenden ist. Falls der Webbrowser das nicht unterstützt, soll alternativ HTTP/2 verwendet werden. Falls der Browser auch das nicht unterstützt, ist implizit HTTP/1.1 als Rückfalloption vorgesehen. Falls der Website-Anbieter den Rückfall auf HTTP/1.1 nicht wünscht, kann er dies mit dem Parameter „no-default-alpn“ mitteilen.[5]
In jedem Fall zeigt der HTTPS Resource Record an, dass die Verbindung verschlüsselt über HTTPS erfolgen soll. Dies gilt auch dann, wenn der Webbrowser einer URL nach dem Schema „http://“ folgt.[8] Ein Rückfall auf unverschlüsseltes HTTP ist nicht vorgesehen – auch dann nicht, wenn die HTTPS-Verbindung fehlschlägt.[5]
Verbreitung
[Bearbeiten | Quelltext bearbeiten]Vor der Veröffentlichung des RFC 9460[1] im November 2023 wurde die Protokollerweiterung lange getestet. Seit 2020 ist es in iOS 14 und macOS 11 im Einsatz. Alle großen Browser haben es inzwischen ebenfalls implementiert.[5]
Weblinks
[Bearbeiten | Quelltext bearbeiten]- RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023 (englisch).
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ a b RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023 (englisch).
- ↑ RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023 (Abstract, englisch).
- ↑ RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023, Anhang C.1 (englisch).
- ↑ RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023, Abschnitt 1.1 (englisch).
- ↑ a b c d e Carsten Strotmann: Schlaue Weichenstellung. Admin-Know-how: Wie der HTTPS-Eintrag das DNS erweitert, warum er so nützlich ist. In: c’t. Nr. 8, 2024, S. 150–153 (heise.de [abgerufen am 4. April 2024] Artikel auch in heise+ enthalten über diesen Link).
- ↑ RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023, Abschnitt 9 (englisch).
- ↑ RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023, Abschnitt 2.4.1 (englisch).
- ↑ RFC: – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023, Abschnitt 9.1 (englisch).