Recherche DNS sur Mac, iPhone et iPad, sans terminal

Sur macOS, SSHive n'appelle pas la fonction de résolution POSIX du système. Il utilise la bibliothèque résolveur embarquée dans le runtime desktop, qui construit et analyse elle-même les messages DNS et parle directement le protocole aux serveurs déclarés dans la configuration réseau de la machine. C'est précisément ce choix qui rend accessibles les types autres que les adresses : l'API POSIX getaddrinfo ne sait répondre qu'à une seule question, « donne-moi les adresses de socket de ce nom », et n'a aucun moyen d'exprimer « donne-moi l'ensemble MX ». Six requêtes (A, AAAA, MX, CNAME, NS, TXT) partent en parallèle, chacune avec sa propre gestion d'erreur, si bien qu'un domaine sans AAAA ni CNAME renvoie quand même ses lignes A et MX au lieu de transformer toute la résolution en échec. Le nom d'hôte saisi est validé par un motif strict avant d'atteindre le résolveur. Cette implémentation traverse le bac à sable Mac App Store sans restriction. Une requête DNS est du trafic client sortant ordinaire, couvert par l'entitlement client réseau : il n'y a rien à contourner. iOS a mis plus longtemps à atteindre la parité, et la raison est instructive. Le chemin évident est getaddrinfo avec AF_UNSPEC : parcourir la chaîne addrinfo renvoyée, convertir chaque adresse avec inet_ntop, dédupliquer. Cela fonctionne, et cela renvoie des adresses et rien d'autre : c'est la nature de l'API, qui rend des adresses de socket et non des enregistrements de ressource, en écartant les TTL, les sections d'autorité et additionnelle, et tout ce qui n'est pas une adresse. L'écran DNS d'iOS s'est longtemps arrêté là : des A et des AAAA, sans moyen de demander un ensemble MX. La solution a été d'abandonner l'API de haut niveau. SSHive appelle désormais le résolveur BSD de libresolv via un petit assistant en C (res_init, puis res_query pour chaque type d'enregistrement) et analyse lui-même la section de réponse avec ns_initparse et ns_parserr, en étendant les noms compressés par dn_expand. On obtient les six types du Mac plus SOA, chacun avec la durée de vie réellement envoyée par le serveur. Aucune bibliothèque de résolution tierce, aucune API web sur le trajet : la requête part de votre appareil vers les résolveurs qu'il utilise déjà. Une conséquence de ce chemin système mérite d'être connue : il respecte ce que le réseau impose, y compris la synthèse DNS64/NAT64 sur les réseaux mobiles en IPv6 seul, où vous pouvez légitimement voir un AAAA pour un hôte qui ne publie qu'un A. Ce n'est pas un défaut de l'outil : c'est le réseau qui vous dit comment votre appareil se connectera réellement. Ce qui manque partout, dit clairement : ni SRV, ni CAA ; pas de champ serveur de noms personnalisé ; pas d'état de validation DNSSEC affiché. La conséquence pratique mérite d'être intégrée : SSHive répond à « que résout cette machine, maintenant », la question que l'on se pose réellement pendant un incident, et celle à laquelle un vérificateur web ne peut pas répondre pour l'appareil que vous tenez. « Que dit la zone faisant autorité » reste une question pour dig @ns1.exemple.fr.