3. Overview (Aperçu général)
3. Overview (Aperçu général)
Un client DNS Push Notification s'abonne aux Push Notifications pour un RRset particulier en se connectant au serveur Push Notification approprié pour ce RRset et en envoyant des messages DSO indiquant le ou les RRsets d'intérêt. Lorsque le client perd son intérêt à recevoir d'autres mises à jour de ces enregistrements, il se désabonne.
Le serveur DNS Push Notification pour une zone DNS est tout serveur capable de générer les notifications de changement correctes pour un nom. Il peut s'agir d'un serveur de noms primaire, secondaire ou furtif [RFC8499].
L'enregistrement SRV "_dns-push-tls._tcp.<zone>" pour une zone PEUT référencer le même hôte cible et le même port que l'enregistrement SRV "_dns-update-tls._tcp.<zone>" de cette zone. Lorsque le même hôte cible et le même port sont offerts pour les DNS Updates et les DNS Push Notifications, un client PEUT utiliser une seule session DSO vers ce serveur pour les DNS Updates et les abonnements DNS Push Notification. Les DNS Updates et les DNS Push Notifications peuvent être gérés sur différents ports du même hôte cible, auquel cas ils ne sont pas considérés comme le "même serveur" aux fins de cette spécification, et les communications avec ces deux ports sont gérées indépendamment. Le support des DNS Updates et des DNS Push Notifications sur le même serveur est OPTIONNEL. Un serveur DNS Push Notification n'est pas tenu de supporter DNS Update.
Les requêtes DNS standard PEUVENT être envoyées sur une session DNS Push Notification (c'est-à-dire DSO). Pour toute zone pour laquelle le serveur fait autorité, il DOIT répondre de manière autoritaire aux requêtes pour les noms appartenant à cette zone (par exemple, l'enregistrement SRV "_dns-push-tls._tcp.<zone>") à la fois pour les requêtes DNS normales et pour les abonnements DNS Push Notification. Pour les noms pour lesquels le serveur agit en tant que résolveur récursif (par exemple, lorsque le serveur est le résolveur récursif local), pour toute requête pour laquelle il prend en charge les abonnements DNS Push Notification, il DOIT également prendre en charge les requêtes standard.
Les DNS Push Notifications imposent moins de charge au serveur répondant que ne le ferait un sondage rapide, mais les Push Notifications ont toujours un coût. Par conséquent, les clients DNS Push Notification NE DOIVENT PAS créer de manière imprudente un nombre excessif d'abonnements Push Notification. Spécifiquement:
(a) Un abonnement ne devrait être actif que lorsqu'il existe une raison valable d'avoir besoin de données en direct (par exemple, un affichage à l'écran montre actuellement les résultats à l'utilisateur), et l'abonnement DEVRAIT être annulé dès que le besoin de ces données prend fin (par exemple, lorsque l'utilisateur ferme cet affichage). Dans le cas d'un appareil comme un smartphone qui, après une certaine période d'inactivité, se met en veille ou assombrit son écran, il devrait annuler ses abonnements lors de l'assombrissement de l'écran (puisque l'utilisateur ne peut de toute façon voir aucun changement sur l'affichage) et rétablir ses abonnements lors du réveil du sommeil d'affichage.
(b) Un client DNS Push Notification NE DEVRAIT PAS maintenir systématiquement un abonnement DNS Push Notification actif 24 heures sur 24, 7 jours sur 7, juste pour garder une liste en mémoire à jour afin que si l'utilisateur choisit d'afficher ces données à l'écran, elles puissent être affichées très rapidement. Les DNS Push Notifications sont conçus pour être suffisamment rapides pour qu'il n'y ait pas besoin de précharger une liste "préchauffée" en mémoire au cas où elle pourrait être nécessaire plus tard.
Généralement, comme décrit dans la spécification des DNS Stateful Operations [RFC8490], un client ne doit pas maintenir une session DSO vers un serveur ouverte indéfiniment s'il n'a pas d'abonnements (ou d'autres opérations) actifs sur cette session. Un client devrait commencer à fermer une session DSO immédiatement après qu'elle devienne inactive, puis, si nécessaire à l'avenir, ouvrir une nouvelle session lorsque requis. Alternativement, un client peut spéculativement garder une session DSO inactive ouverte pendant un certain temps, sous réserve de la contrainte qu'il ne doit pas garder une session ouverte qui est restée inactive pendant plus que le délai d'expiration d'inactivité de la session (15 secondes par défaut) [RFC8490].
Notez qu'une session DSO qui a un abonnement DNS Push Notification actif n'est pas considérée comme inactive, même s'il n'y a pas de trafic circulant pendant une période prolongée. Dans ce cas, le délai d'expiration d'inactivité DSO ne s'applique pas, car la session n'est pas inactive, mais l'intervalle de keepalive s'applique toujours, pour assurer la génération de suffisamment de messages pour maintenir l'état dans les middleboxes (comme les passerelles NAT ou les pare-feu) et pour que le client et le serveur vérifient périodiquement qu'ils ont toujours une connectivité l'un avec l'autre. Ceci est décrit dans la section 6.2 de la spécification DSO [RFC8490].