1.1. Ziele (Goals)

Das Ziel des SVCB RR besteht darin, Clients zu ermöglichen, einen einzelnen zusätzlichen DNS RR auf eine Weise aufzulösen, die:

Alternative Endpunkte bereitstellt, die für den Dienst autoritativ sind, zusammen mit den mit jedem dieser Endpunkte verbundenen Parametern.
Nicht davon ausgeht, dass alle alternativen Endpunkte dieselben Parameter oder Fähigkeiten haben oder sogar von derselben Entität betrieben werden. Dies ist wichtig, da DNS keine Möglichkeit bietet, mehrere RRsets für denselben Namen miteinander zu verbinden. Wenn beispielsweise www.example.com ein CNAME-Alias ist, der zwischen einem von drei Content Delivery Networks (CDNs) oder Hosting-Umgebungen wechselt, können aufeinanderfolgende Abfragen für diesen Namen Einträge zurückgeben, die verschiedenen Umgebungen entsprechen.
CNAME-ähnliche Funktionalität an einem Zonen-Apex (wie example.com) für teilnehmende Protokolle ermöglicht und allgemein die Erweiterung der betrieblichen Autorität für einen durch einen Domainnamen identifizierten Dienst auf andere Instanzen mit alternativen Namen ermöglicht.

Zusätzliche Ziele, die spezifisch für HTTPS RRs und HTTP-Anwendungsfälle sind, umfassen:

Direktes Verbinden zu HTTP/3 (QUIC-Transport) alternativen Endpunkten [HTTP/3].
Unterstützung nicht standardmäßiger TCP- und UDP-Ports.
Aktivierung SRV-ähnlicher Vorteile (z.B. Apex-Aliasing, wie oben erwähnt) für HTTP, wo SRV [SRV] nicht weit verbreitet ist.
Bereitstellung einer Anzeige, die signalisiert, dass das "https"-Schema anstelle von "http" für alle HTTP-Anfragen an diesen Host und Port verwendet werden sollte, ähnlich wie HTTP Strict Transport Security [HSTS] (siehe Abschnitt 9.5).
Ermöglichung der Übermittlung von Encrypted ClientHello-Schlüsseln [ECH], die mit einem alternativen Endpunkt verbunden sind.