6.1. Discovery (Entdeckung)

6.1. Discovery (Entdeckung)

Der erste Schritt beim Einrichten eines DNS Push Notification-Abonnements besteht darin, einen geeigneten DNS-Server zu finden, der DNS Push Notifications für die gewünschte Zone unterstützt.

Der Client beginnt damit, eine DSO-Sitzung zu seinem normal konfigurierten rekursiven DNS-Resolver zu öffnen und ein Push Notification-Abonnement anzufordern. Diese Verbindung wird zu TCP-Port 853 hergestellt, dem Standardport für DNS over TLS [RFC7858]. Wenn die Anfrage für ein Push Notification-Abonnement erfolgreich ist und der rekursive Resolver noch kein aktives Abonnement für diesen Namen, Typ und diese Klasse hat, erstellt der rekursive Resolver im Namen des Clients ein entsprechendes Push Notification-Abonnement. Empfangene Ergebnisse werden an den Client weitergeleitet. Dies ist eng analog dazu, wie ein Client eine normale DNS-Abfrage an seinen konfigurierten rekursiven DNS-Resolver sendet, der, wenn er noch keine geeigneten Antworten in seinem Cache hat, eine Upstream-Abfrage ausgibt, um die Anfrage zu erfüllen.

In vielen Kontexten wird der rekursive Resolver in der Lage sein, Push Notifications für alle Namen zu verarbeiten, die der Client möglicherweise verfolgen muss. Die Verwendung von VPN-Tunneln und privatem DNS [RFC8499] kann hier einige zusätzliche Komplexität in der Client-Software erzeugen; die Techniken zum Umgang mit VPN-Tunneln und privatem DNS für DNS Push Notifications sind die gleichen wie diejenigen, die bereits verwendet werden, um dies für normale DNS-Abfragen zu handhaben.

Wenn der rekursive Resolver DNS over TLS nicht unterstützt, oder DNS over TLS unterstützt, aber nicht auf TCP-Port 853 lauscht, oder DNS over TLS auf TCP-Port 853 unterstützt, aber DSO auf diesem Port nicht unterstützt, schlägt die DSO-Sitzungseinrichtung fehl [RFC8490].

Wenn der rekursive Resolver DSO auf TCP-Port 853 unterstützt, aber Push Notification-Abonnements nicht unterstützt, gibt der Server den DSO-Fehlercode DSOTYPENI (11) zurück, wenn der Client versucht, ein Abonnement zu erstellen.

In einigen Fällen kann der rekursive Resolver DSO und Push Notification-Abonnements unterstützen, aber möglicherweise nicht in der Lage sein, Push Notifications für einen bestimmten Namen zu abonnieren. In diesem Fall sollte der rekursive Resolver SERVFAIL an den Client zurückgeben. Dies beinhaltet die Unfähigkeit, eine Verbindung zum DNS Push Notification-Server der Zone herzustellen, oder das Herstellen einer Verbindung, aber den Empfang eines nicht erfolgreichen Antwortcodes. In einigen Fällen, in denen der Client eine vorher festgelegte Vertrauensbeziehung mit dem Eigentümer der Zone hat (die nicht über die üblichen Mechanismen für VPN-Software gehandhabt wird), kann der Client diese Fehler behandeln, indem er den DNS Push Notification-Server der Zone direkt kontaktiert.

In allen oben beschriebenen Fällen, in denen der Client ein DNS Push Notification-Abonnement über seinen konfigurierten rekursiven Resolver nicht einrichten kann, sollte der Client fortfahren, den geeigneten Server für die direkte Kommunikation zu entdecken. Der Client MUSS auch bestimmen, auf welchem TCP-Port der Server auf Verbindungen lauscht, was nicht TCP-Port 53 (traditionell für herkömmliches DNS verwendet) oder TCP-Port 853 (traditionell für DNS over TLS verwendet) sein muss und oft auch nicht ist.

Der hier beschriebene Entdeckungsalgorithmus ist ein iterativer Algorithmus, der mit dem vollständigen Namen des Datensatzes beginnt, den der Client abonnieren möchte. Nachfolgende SOA-Abfragen werden dann ausgegeben, wobei jedes Mal ein Label gekürzt wird, bis der nächstgelegene umschließende autoritative Server entdeckt wird. Es gibt auch eine Optimierung, die es dem Client ermöglicht, in vielen Fällen eine "Abkürzung" direkt zum SOA-Datensatz des nächstgelegenen umschließenden autoritativen Servers zu nehmen.

1. Der Client beginnt die Entdeckung, indem er eine DNS-Abfrage an seinen lokalen Resolver sendet, mit dem Datensatztyp SOA [RFC1035] für den Datensatznamen, den er abonnieren möchte. Nehmen wir als Beispiel an, der Client möchte PTR-Datensätze mit dem Namen "_ipp._tcp.headoffice.example.com" abonnieren (um Internet Printing Protocol (IPP)-Drucker [RFC8010] [RFC8011] zu entdecken, die in der Zentrale von Example Company beworben werden). Der Client beginnt damit, eine SOA-Abfrage für "_ipp._tcp.headoffice.example.com" an den lokalen rekursiven Resolver zu senden. Das Ziel ist es, den Server zu bestimmen, der für den Namen "_ipp._tcp.headoffice.example.com" autoritativ ist. Die nächstgelegene umschließende DNS-Zone, die den Namen "_ipp._tcp.headoffice.example.com" enthält, könnte "example.com", "headoffice.example.com", "_tcp.headoffice.example.com" oder sogar "_ipp._tcp.headoffice.example.com" sein. Der Client weiß nicht im Voraus, wo der nächstgelegene umschließende Zonenschnitt auftritt, weshalb er das hier beschriebene iterative Verfahren verwendet, um diese Information zu entdecken.

2. Wenn der angeforderte SOA-Datensatz existiert, wird er in der Answer Section mit einem NOERROR-Antwortcode zurückgegeben, und der Client hat die benötigten Informationen erfolgreich entdeckt. (Diese Formulierung stellt keine neuen Anforderungen an rekursive DNS-Resolver. Dieser Text beschreibt lediglich die bestehende Funktionsweise des DNS-Protokolls [RFC1034] [RFC1035].)

3. Wenn der angeforderte SOA-Datensatz nicht existiert, erhält der Client eine NOERROR/NODATA-Antwort oder eine NXDOMAIN/Name Error-Antwort zurück. In beiden Fällen würde der lokale Resolver normalerweise den SOA-Datensatz für die nächstgelegene umschließende Zone des angeforderten Namens in der Authority Section einschließen. Wenn der SOA-Datensatz in der Authority Section empfangen wird, hat der Client die benötigten Informationen erfolgreich entdeckt. (Diese Formulierung stellt keine neuen Anforderungen an rekursive DNS-Resolver. Dieser Text beschreibt lediglich die bestehende Funktionsweise des DNS-Protokolls bezüglich negativer Antworten [RFC2308].)

4. Wenn der Client eine Antwort erhält, die keinen SOA-Datensatz enthält, fährt er mit dem iterativen Ansatz fort. Der Client entfernt das führende Label vom aktuellen Abfragenamen, und wenn der resultierende Name mindestens zwei Labels enthält, sendet der Client eine SOA-Abfrage für diesen neuen Namen und die Verarbeitung wird bei Schritt 2 oben fortgesetzt, wobei die iterative Suche wiederholt wird, bis entweder ein SOA empfangen wird oder der Abfragename aus einem einzigen Label besteht, d.h. einer Top-Level-Domain (TLD). Im Fall eines Namens mit einem einzigen Label (TLD) handelt es sich um einen Netzwerkkonfigurationsfehler, der nicht auftreten sollte, und der Client gibt auf. Der Client kann den Vorgang zu einem späteren Zeitpunkt seiner Wahl wiederholen, z.B. nach einer Änderung der Netzwerkverbindung.

5. Sobald das SOA bekannt ist (indem es entweder in der Answer Section oder in der Authority Section gesehen wurde), sendet der Client eine DNS-Abfrage mit dem Typ SRV [RFC2782] für den Datensatznamen "_dns-push-tls._tcp.<zone>", wobei <zone> der Besitzername des entdeckten SOA-Datensatzes ist.

6. Wenn die betreffende Zone so eingerichtet ist, dass sie DNS Push Notifications anbietet, MUSS dieser SRV-Datensatz existieren. (Wenn dieser SRV-Datensatz nicht existiert, ist die Zone nicht korrekt für DNS Push Notifications konfiguriert, wie in diesem Dokument spezifiziert.) Das SRV "target" enthält den Namen des Servers, der DNS Push Notifications für die Zone bereitstellt. Die Portnummer, unter der der Server kontaktiert werden soll, befindet sich im "port"-Feld des SRV-Datensatzes. Die Adresse(n) des Ziel-Hosts KÖNNEN in der Additional Section enthalten sein, jedoch SOLLTEN die Adressdatensätze vor der Verwendung authentifiziert werden, wie in Abschnitt 7.2 und in der Spezifikation für die Verwendung von DNS-Based Authentication of Named Entities (DANE) TLSA Records mit SRV Records [RFC7673] beschrieben, falls zutreffend.

7. Es können mehr als ein SRV-Datensatz zurückgegeben werden. In diesem Fall werden die Werte "priority" und "weight" in den zurückgegebenen SRV-Datensätzen verwendet, um die Reihenfolge zu bestimmen, in der die Server für Abonnementanfragen kontaktiert werden. Wie in der SRV-Spezifikation [RFC2782] beschrieben, wird der Server mit der niedrigsten "priority" zuerst kontaktiert. Wenn mehr als ein Server die gleiche "priority" hat, gibt "weight" die gewichtete Wahrscheinlichkeit an, dass der Client diesen Server kontaktieren sollte. Höhere Gewichte haben höhere Auswahlwahrscheinlichkeiten. Wenn ein Server nicht bereit ist, eine Abonnementanfrage zu akzeptieren, oder nicht innerhalb einer angemessenen Zeit erreichbar ist, wie vom Client bestimmt, ist ein nachfolgender Server zu kontaktieren.

Jedes Mal, wenn ein Client ein neues DNS Push Notification-Abonnement erstellt, SOLLTE er den Entdeckungsprozess wiederholen, um den bevorzugten DNS-Server für dieses Abonnement zu diesem Zeitpunkt zu bestimmen. Wenn ein Client bereits eine DSO-Sitzung mit diesem DNS-Server hat, SOLLTE der Client diese bestehende DSO-Sitzung für das neue Abonnement wiederverwenden; andernfalls wird eine neue DSO-Sitzung eingerichtet. Der Client MUSS die DNS-TTL-Werte auf Datensätzen respektieren, die er während der Durchführung des Entdeckungsprozesses erhält, und sie mit dieser Lebensdauer in seinem lokalen Cache speichern (wie er es generell ohnehin für alle DNS-Abfragen tut, die er durchführt). Dies bedeutet, dass, solange die DNS-TTL-Werte auf den autoritativen Datensätzen auf vernünftige Werte gesetzt sind, die wiederholte Anwendung des Entdeckungsprozesses praktisch augenblicklich vom Client abgeschlossen werden kann, indem nur lokal gespeicherte zwischengespeicherte Daten verwendet werden.