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

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

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. Die Liste aller für SvcParams definierten Schlüssel und zugehörige Standards wird bei der IANA im "dns-svcb"-Register^[8] gepflegt. Die wichtigsten Einträge sind:

1. mandatory (Parameter-ID: 0):^[9] Gibt eine liste an SvcParams an, die ein Client zwingend unterstützen muss, um diesen Eintrag verwenden zu können. Unterstützt ein client eine der genannten Optionen NICHT, wird der gesamte Eintrag ignoriert.
2. alpn (Parameter-ID: 1):^[10] Spezifizieren die ALPN des jeweiligen Eintrags. Kann verwendet werden um z. B. unterschiedliche Endpunkte für QUIC via UDP und TLS via TCP anzugeben. Clients filtern die liste der erhaltenen HTTPS-RRs nach den von ihnen unterstützten ALPNs.
3. no-default-alpn (Parameter-ID: 2):^[10] Kann zusätzlich zu alpn angegeben werden. Wird auf die Angabe von no-default-alpn verzichtet, fügt ein Client die jeweiligen Standardwerte an die in alpn spezifizierten Werte an. In manchen Fällen ist die Standardliste jedoch leer.
4. port (Parameter-ID: 3):^[11] Gibt den Transportschicht-Endpunkt an. In der Regel bezieht sich diese Angabe gleichzeitig sowohl auf TCP als auch UDP.
5. ipv4hint (Parameter-ID: 4)^[12]
6. ech (Parameter-ID: 5):^[13] Wird aktuell nicht verwendet, wurde aber für die zukünftige Nutzung für Verschlüsseltes ClientHello reserviert.
7. ipv6hint (Parameter-ID: 6)^[12]
8. dohpath (Parameter-ID: 7):^[14] Wird aus "Konsistenzgründen" zusätzlich zum SVCB-RR auch im HTTPS-RR für DNS via HTTPS angegeben und verweist auf den Suchpfad. e.g. dohpath=/dns-query{?dns}. Der Standard hierzu empfiehlt das Clients den HTTPS-RR nicht abfragen sollen, wenn sie bereits den SVCB-RR abgefragt haben. Der SVCB-RR soll ebenfalls dem HTTPS-RR vorgezogen werden. Dennoch wird aber die Eintragung im HTTPS-RR empfohlen, "falls Clients von der Existenz des DoH-Servers auf andere weise erfahren sollten".
9. ohttp (Parameter-ID: 8):^[15] Stellt eine Möglichkeit dar ein Oblivious HTTP gateway/relay anzugeben. Quasi eine Art "HTTP-Connect"-Proxy, welche die Verschlüsselte Verbindung zum eigentlichen Server weiterleitet. Aktuell wird dies primär für DoH sowie von Google (via Fastly, für seine "experimentelle anonymisierte Werbetechnik")^[16], Cloudflare^[17], und Apple (für "Enhanced Visual Search")^[18] verwendet und stellt eine Form des Onion-Routing dar um die Endpunkte einer Verbindung zu verschleiern.
10. tls-supported-groups (Parameter-ID: 9):^[19] Gibt die TLS Cipher Gruppen an um den TLS-Verbindungsaufbau durch die Vermeidung von HelloRetryRequest zu beschleunigen. Obwohl es immer noch in aktiver Entwicklung ist, hat für die Version 1 des Entwurfs bereits eine Eintragung im IANA Register stattgefunden.
11. N/A (Parameter-ID: 65280–65534): Für nicht öffentliche interne/private Verwendung reserviert.
12. N/A (Parameter-ID: 65535): Reserviert für Software um einen Ungültige Schlüssel ("Invalid key") auszuweisen.

Beispiele

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. port=8443

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] Für den letzten Server erfolgt der Verbindungsversuch nicht auf dem für HTTPS standardmäßigen Ports TCP-443 und UDP-443, sondern auf TCP-8443 und UDP-8443.

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.^[20] Ein Rückfall auf unverschlüsseltes HTTP ist nicht vorgesehen – auch dann nicht, wenn die HTTPS-Verbindung fehlschlägt.^[5]

Verbreitung

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

• RFC: 9460 – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023 (englisch).