Dans l’exemple illustré par la , le champ OPTION-DATA comprend un paramètre « partial-offload » et un paramètre « AID » (pour « AD ASTRA relay IDentifier » en anglais), ainsi qu’un emplacement réservé ou « reserved » en anglais, permettant au dispositif client 2 de communiquer des capacités dont il dispose en lien avec le mécanisme AD ASTRA ainsi que d’autres informations pouvant être utiles au serveur DNS 3 sollicité. Plus particulièrement : le paramètre « partial-offload » est utilisé par le dispositif client 2 dans une requête pour indiquer au serveur DNS 3-1 s’il supporte (paramètre valorisé à 1 par exemple) ou non (paramètre valorisé à 0 par exemple) l’envoi d’une première requête de résolution de nom vers le serveur DNS 3-1 (requête REQ-DNS) puis l’envoi de requêtes de résolution de nom ultérieures (deuxièmes requêtes au sens de l’invention, notées REQ’-DNS, REQ’’-DNS, etc.), corrélées à la première requête de résolution de nom REQ-DNS, vers un autre serveur de résolution de nom que le serveur DNS 3.1 dont l’information de joignabilité (par exemple son adresse IP) lui est communiquée par le serveur DNS 3-1. Cet autre serveur de résolution de nom peut typiquement être un nœud relais sélectionné par le serveur DNS 3-1 conformément à l’invention. Par « requêtes corrélées », on entend ici qu’il existe un lien entre les deux questions posées dans les deux requêtes, par exemple la première requête porte sur la résolution d’un nom de domaine « parent » (par exemple « service-s.com ») tandis que la deuxième requête porte sur la résolution d’un nom d’un sous-domaine du domaine parent (c’est-à-dire « *.service-s.com » dans l’exemple envisagé ci-avant où * désigne une chaîne de caractères). Un autre exemple de corrélation est la découverte par le dispositif client 2 de noms (ou de « références » ou encore « referrals » en anglais) nécessitant une résolution lors du traitement de données envoyées par le serveur destinataire résultant de la résolution de la première requête ; la ou les deuxièmes requêtes envoyées pour résoudre ces noms sont corrélées au sens de l’invention à la première requête. La corrélation est établie par le dispositif client 2 dès lors qu’il associe le serveur destinataire comme source des noms. Le paramètre « partial-offload » peut être valorisé à 0 par défaut. Dans la suite de la description, si le paramètre « partial-offload » est valorisé à 1 par le dispositif client 2, on dit que celui-ci supporte la fonction « partial-offload » (fonction de « décharge » de requêtes DNS sur un autre serveur que le serveur DNS 3-1 chargé de traiter la première requête REQ-DNS) ; et le paramètre « AID » est utilisé par le dispositif client 2 pour indiquer s’il utilise déjà, pour des connexions actives, un nœud relais conformément à l’invention, dans le cadre d’une mise en œuvre du mécanisme AD ASTRA pour le service S associé au nom de domaine « service-S.com » hébergé par le serveur 5 (autrement dit pour envoyer des messages contenant des données destinées au serveur 5), et le cas échéant un identifiant de ce nœud relais. Aucune limitation n’est imposée quant à la forme de l’identifiant en question : il peut s’agir d’un alias, d’un nombre, d’un nom de domaine, d’un condensé (ou « hash » en anglais), etc. Le dispositif client 2 peut éventuellement associer cet identifiant à une préférence destinée au serveur DNS 3-1, par exemple « match » s’il souhaite que le serveur DNS 3-1 sélectionne le même nœud relais lors de son traitement de la requête REQ-DNS, ou « not match » pour demander l’utilisation d’un autre nœud relais. Dans le mode de réalisation décrit ici, cette préférence n’est pas nécessairement contraignante pour le serveur DNS 3-1 et peut ne pas être prise en compte par celui-ci. Bien entendu, ceci n’est qu’un choix d’implémentation et on peut en variante envisager que cette préférence du dispositif client 2 soit contraignante pour le serveur DNS 3-1.