Comment fonctionne une requête DNSBL, et pourquoi l'ordre du retrait compte
Une DNSBL est une base de données publiée intégralement via DNS — et c'est précisément pour cela qu'elle est le seul diagnostic à se comporter à l'identique sur toutes les plateformes où SSHive est distribué.
Pour tester 203.0.113.25 contre zen.spamhaus.org, le client inverse les quatre octets et demande un enregistrement A à 25.113.0.203.zen.spamhaus.org. L'inversion n'a rien de cosmétique. Le DNS délègue hiérarchiquement de droite à gauche : écrire l'adresse à l'envers permet à l'opérateur de la zone de déléguer par /8, /16 ou /24, exactement comme in-addr.arpa le fait pour les résolutions inverses. NXDOMAIN signifie « non listée ». Toute réponse dans 127.0.0.0/8 signifie « listée », les octets de poids faible encodant la sous-liste concernée. Un enregistrement TXT sur le même nom, lorsque l'opérateur en publie un, porte le motif lisible et l'URL de retrait.
SSHive implémente cela deux fois. Sur macOS et Windows, le processus principal lance les huit requêtes de zone en parallèle via le résolveur c-ares de Node, chacune interceptée individuellement pour qu'une zone morte ou limitée en débit ne fasse pas échouer l'ensemble ; en cas de hit, une seconde requête TXT sur le même nom récupère le motif. Sur iPhone et iPad, l'implémentation Swift éclate les dix zones dans un groupe de tâches sur une file utilitaire, un getaddrinfo forcé en AF_INET par zone, puis trie les résultats en plaçant les listings d'abord, ensuite par ordre alphabétique. Les deux acceptent une IPv4 littérale ou un nom d'hôte, ce dernier étant résolu vers son premier enregistrement A avant toute interrogation.
Comme tout cela se ramène à une résolution d'enregistrement A via le résolveur système, aucun socket brut, aucun port privilégié et aucun binaire lancé ne sont impliqués : la vérification tourne telle quelle dans le bac à sable d'Apple. C'est important, car ce n'est pas vrai de tous les outils : le traceroute exige des sockets ICMP bruts, il fonctionne donc sur le DMG macOS en téléchargement direct et sur Windows, est volontairement désactivé dans la version Mac App Store, et n'est pas un vrai traceroute sur iPhone ni iPad. La vérification DNSBL, elle, n'a aucun astérisque. Cela signifie aussi que chaque requête part de votre appareil vers les serveurs de noms de la zone, via le résolveur assigné par votre réseau : aucun backend SSHive, aucune API web tierce sur le trajet.
Deux limites sont assumées. L'outil est IPv4 uniquement, et il n'interroge que des zones basées sur l'IP : pas de listes par domaine de type URIBL ou SURBL, pas d'horodatage des listings, pas de lien de retrait cliquable.
Reste le retrait lui-même, où l'ordre des opérations décide de tout. Corrigez la cause avant de soumettre quoi que ce soit : retirer un listing alors que la source est encore active vous fait relister, souvent avec une pénalité plus longue. Les causes habituelles, par fréquence approximative : un compte SMTP AUTH compromis (cherchez un identifiant unique s'authentifiant depuis de nombreuses IP sources), un formulaire de contact web détourné, un relais ouvert, un poste infecté partageant votre IP publique derrière du NAT, et une liste de diffusion légitime devenue assez obsolète pour toucher des pièges à spam. Vérifiez ensuite les fondamentaux : un reverse DNS confirmé dans les deux sens et cohérent avec votre nom HELO, plus SPF, DKIM et DMARC. Alors seulement, utilisez la page de retrait de chaque opérateur. Spamhaus, Barracuda et SpamCop proposent des formulaires en libre-service ; PSBL, NiX Spam et UCEPROTECT niveau 1 expirent d'eux-mêmes une fois le trafic arrêté. Évitez tout service promettant un retrait de cent listes d'un coup, et attendez-vous à ce que la remise se rétablisse plusieurs jours après la levée du listing.