2.3. SVCB Query Names (SVCB-Abfragenamen)
2.3. SVCB Query Names (SVCB-Abfragenamen)
Bei der Abfrage des SVCB RR wird ein Dienst in einen QNAME übersetzt, indem dem Dienstnamen eine Bezeichnung vorangestellt wird, die das Schema angibt und mit einem Unterstrich versehen ist, was zu einem Domänennamen wie "_examplescheme.api.example.com." führt. Dies folgt dem Attrleaf-Benennungsmuster [Attrleaf], daher MUSS das Schema entsprechend bei der IANA registriert werden (siehe Abschnitt 11).
Protokoll-Mapping-Dokumente KÖNNEN zusätzliche Labels mit Unterstrich-Präfix angeben, die vorangestellt werden sollen. Für Schemata, die einen Port angeben (Abschnitt 3.2.3 von [URI]), ist eine vernünftige Möglichkeit, die angegebene Portnummer voranzustellen, wenn eine nicht standardmäßige Portnummer angegeben ist. Dieses Dokument bezeichnet dieses Verhalten als "Port Prefix Naming (Port-Präfix-Benennung)" und verwendet es in den Beispielen durchgehend.
Siehe Abschnitt 9.1 für Informationen zum Verhalten von HTTPS RR.
Wenn ein vorheriger CNAME- oder SVCB-Eintrag auf einen SVCB-Eintrag aliasiert wurde, SOLL jeder RR unter seinem eigenen Besitzernamen zurückgegeben werden, wie bei der gewöhnlichen CNAME-Verarbeitung ([RFC1034], Abschnitt 3.6.2). Einzelheiten finden Sie in den Empfehlungen zu Aliassen für Clients (Abschnitt 3), Server (Abschnitt 4) und Zonen (Abschnitt 10).
Beachten Sie, dass keine dieser Formen die Herkunft oder Autorität für Validierungszwecke ändert. Zum Beispiel MÜSSEN TLS-Clients weiterhin TLS-Zertifikate für den ursprünglichen Dienstnamen validieren.
Als Beispiel könnte der Besitzer von "example.com" diesen Eintrag veröffentlichen:
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
Dieser Eintrag würde anzeigen, dass "foo://api.example.com:8443" auf "svc4.example.net" aliasiert ist. Der Besitzer von "example.net" wiederum könnte diesen Eintrag veröffentlichen:
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (
alpn="bar" port="8004" )
Dieser Eintrag würde anzeigen, dass diese Dienste auf Portnummer 8004 bereitgestellt werden, die das Protokoll "bar" und den damit verbundenen Transport zusätzlich zum Standard-Transportprotokoll für "foo://" unterstützt.
(Klammern werden verwendet, um einen Zeilenumbruch im DNS-Zonendatei-Darstellungsformat zu ignorieren, gemäß Abschnitt 5.1 von [RFC1035].)