6.1. Discovery (Découverte)

6.1. Discovery (Découverte)

La première étape de l'établissement d'un abonnement DNS Push Notification consiste à découvrir un serveur DNS approprié qui prend en charge les DNS Push Notifications pour la zone souhaitée.

Le client commence par ouvrir une session DSO vers son résolveur récursif DNS normalement configuré et en demandant un abonnement Push Notification. Cette connexion est établie sur le port TCP 853, le port par défaut pour DNS over TLS [RFC7858]. Si la demande d'abonnement Push Notification réussit et que le résolveur récursif n'a pas déjà d'abonnement actif pour ce nom, ce type et cette classe, alors le résolveur récursif créera un abonnement Push Notification correspondant au nom du client. Les résultats reçus sont relayés au client. Ceci est étroitement analogue à la manière dont un client envoie une requête DNS normale à son résolveur récursif DNS configuré, qui, s'il n'a pas déjà de réponse(s) appropriée(s) dans son cache, émet une requête en amont pour satisfaire la demande.

Dans de nombreux contextes, le résolveur récursif sera capable de gérer les Push Notifications pour tous les noms que le client pourrait avoir besoin de suivre. L'utilisation de tunnels VPN et de DNS privé [RFC8499] peut créer une certaine complexité supplémentaire dans le logiciel client ici; les techniques pour gérer les tunnels VPN et le DNS privé pour les DNS Push Notifications sont les mêmes que celles déjà utilisées pour gérer cela pour les requêtes DNS normales.

Si le résolveur récursif ne prend pas en charge DNS over TLS, ou prend en charge DNS over TLS mais n'écoute pas sur le port TCP 853, ou prend en charge DNS over TLS sur le port TCP 853 mais ne prend pas en charge DSO sur ce port, alors l'établissement de la session DSO échouera [RFC8490].

Si le résolveur récursif prend en charge DSO sur le port TCP 853 mais ne prend pas en charge les abonnements Push Notification, alors lorsque le client tente de créer un abonnement, le serveur renverra le code d'erreur DSO DSOTYPENI (11).

Dans certains cas, le résolveur récursif peut prendre en charge DSO et les abonnements Push Notification mais peut ne pas être en mesure de s'abonner aux Push Notifications pour un nom particulier. Dans ce cas, le résolveur récursif devrait renvoyer SERVFAIL au client. Cela inclut l'impossibilité d'établir une connexion au serveur DNS Push Notification de la zone ou l'établissement d'une connexion mais la réception d'un code de réponse non réussi. Dans certains cas, où le client a une relation de confiance préétablie avec le propriétaire de la zone (qui n'est pas gérée via les mécanismes habituels pour les logiciels VPN), le client peut gérer ces échecs en contactant directement le serveur DNS Push Notification de la zone.

Dans l'un des cas décrits ci-dessus où le client ne parvient pas à établir un abonnement DNS Push Notification via son résolveur récursif configuré, le client devrait procéder à la découverte du serveur approprié pour la communication directe. Le client DOIT également déterminer sur quel port TCP le serveur écoute les connexions, qui n'a pas besoin d'être, et souvent n'est pas, le port TCP 53 (traditionnellement utilisé pour le DNS conventionnel) ou le port TCP 853 (traditionnellement utilisé pour DNS over TLS).

L'algorithme de découverte décrit ici est un algorithme itératif, qui commence par le nom complet de l'enregistrement auquel le client souhaite s'abonner. Des requêtes SOA successives sont ensuite émises, en coupant une étiquette à chaque fois, jusqu'à ce que le serveur autoritaire le plus proche soit découvert. Il existe également une optimisation pour permettre au client de prendre un "raccourci" directement vers l'enregistrement SOA du serveur autoritaire le plus proche dans de nombreux cas.

1. Le client commence la découverte en envoyant une requête DNS à son résolveur local, avec le type d'enregistrement SOA [RFC1035] pour le nom d'enregistrement auquel il souhaite s'abonner. À titre d'exemple, supposons que le client souhaite s'abonner aux enregistrements PTR avec le nom "_ipp._tcp.headoffice.example.com" (pour découvrir les imprimantes Internet Printing Protocol (IPP) [RFC8010] [RFC8011] annoncées dans le siège social de Example Company). Le client commence par envoyer une requête SOA pour "_ipp._tcp.headoffice.example.com" au résolveur récursif local. L'objectif est de déterminer le serveur qui fait autorité pour le nom "_ipp._tcp.headoffice.example.com". La zone DNS englobante la plus proche contenant le nom "_ipp._tcp.headoffice.example.com" pourrait être "example.com", ou "headoffice.example.com", ou "_tcp.headoffice.example.com", ou même "_ipp._tcp.headoffice.example.com". Le client ne sait pas à l'avance où se produit la coupure de zone englobante la plus proche, c'est pourquoi il utilise la procédure itérative décrite ici pour découvrir cette information.

2. Si l'enregistrement SOA demandé existe, il sera renvoyé dans la section Answer avec un code de réponse NOERROR, et le client a réussi à découvrir les informations dont il a besoin. (Ce langage n'impose aucune nouvelle exigence aux résolveurs récursifs DNS. Ce texte décrit simplement le fonctionnement existant du protocole DNS [RFC1034] [RFC1035].)

3. Si l'enregistrement SOA demandé n'existe pas, le client recevra une réponse NOERROR/NODATA ou une réponse NXDOMAIN/Name Error. Dans les deux cas, le résolveur local inclurait normalement l'enregistrement SOA pour la zone englobante la plus proche du nom demandé dans la section Authority. Si l'enregistrement SOA est reçu dans la section Authority, alors le client a réussi à découvrir les informations dont il a besoin. (Ce langage n'impose aucune nouvelle exigence aux résolveurs récursifs DNS. Ce texte décrit simplement le fonctionnement existant du protocole DNS concernant les réponses négatives [RFC2308].)

4. Si le client reçoit une réponse ne contenant aucun enregistrement SOA, il procède alors avec l'approche itérative. Le client supprime l'étiquette principale du nom de requête actuel, et si le nom résultant a au moins deux étiquettes, alors le client envoie une requête SOA pour ce nouveau nom et le traitement continue à l'étape 2 ci-dessus, en répétant la recherche itérative jusqu'à ce qu'un SOA soit reçu ou que le nom de requête soit constitué d'une seule étiquette, c'est-à-dire un domaine de premier niveau (TLD). Dans le cas d'un nom à une seule étiquette (TLD), il s'agit d'une erreur de configuration réseau, qui ne devrait pas se produire, et le client abandonne. Le client peut réessayer l'opération ultérieurement à un moment choisi par le client, par exemple après un changement de connexion réseau.

5. Une fois que le SOA est connu (en vertu d'être vu soit dans la section Answer soit dans la section Authority), le client envoie une requête DNS avec le type SRV [RFC2782] pour le nom d'enregistrement "_dns-push-tls._tcp.<zone>", où <zone> est le nom du propriétaire de l'enregistrement SOA découvert.

6. Si la zone en question est configurée pour offrir des DNS Push Notifications, alors cet enregistrement SRV DOIT exister. (Si cet enregistrement SRV n'existe pas, alors la zone n'est pas correctement configurée pour les DNS Push Notifications comme spécifié dans ce document.) Le "target" SRV contient le nom du serveur fournissant les DNS Push Notifications pour la zone. Le numéro de port sur lequel contacter le serveur se trouve dans le champ "port" de l'enregistrement SRV. Les adresses de l'hôte cible PEUVENT être incluses dans la section Additional, cependant, les enregistrements d'adresse DEVRAIENT être authentifiés avant utilisation comme décrit dans la section 7.2 et dans la spécification pour l'utilisation des enregistrements TLSA DNS-Based Authentication of Named Entities (DANE) avec les enregistrements SRV [RFC7673], le cas échéant.

7. Plus d'un enregistrement SRV peut être renvoyé. Dans ce cas, les valeurs "priority" et "weight" dans les enregistrements SRV renvoyés sont utilisées pour déterminer l'ordre dans lequel contacter les serveurs pour les demandes d'abonnement. Comme décrit dans la spécification SRV [RFC2782], le serveur avec la "priority" la plus basse est contacté en premier. Si plus d'un serveur a la même "priority", le "weight" indique la probabilité pondérée que le client devrait contacter ce serveur. Des poids plus élevés ont des probabilités de sélection plus élevées. Si un serveur n'est pas disposé à accepter une demande d'abonnement, ou n'est pas accessible dans un délai raisonnable, tel que déterminé par le client, alors un serveur ultérieur doit être contacté.

Chaque fois qu'un client crée un nouvel abonnement DNS Push Notification, il DEVRAIT répéter le processus de découverte afin de déterminer le serveur DNS préféré pour cet abonnement à ce moment-là. Si un client a déjà une session DSO avec ce serveur DNS, le client DEVRAIT réutiliser cette session DSO existante pour le nouvel abonnement; sinon, une nouvelle session DSO est établie. Le client DOIT respecter les valeurs TTL DNS sur les enregistrements qu'il reçoit lors de l'exécution du processus de découverte et les stocker dans son cache local avec cette durée de vie (comme il le fera généralement de toute façon pour toutes les requêtes DNS qu'il effectue). Cela signifie que, tant que les valeurs TTL DNS sur les enregistrements autoritaires sont définies à des valeurs raisonnables, l'application répétée du processus de découverte peut être complétée pratiquement instantanément par le client, en utilisant uniquement des données mises en cache stockées localement.