Aller au contenu principal
Obtenir

Whois sur Mac, iPhone et iPad : à qui appartient un domaine, et jusqu'à quand

SSHive ouvre lui-même la connexion TCP sur le port 43 du serveur whois : aucune API web intermédiaire, aucun tiers qui journalise vos recherches.

Par Lucas Russo, développeur de SSHive · Mis à jour le

Télécharger SSHive gratuitementTous les outils réseau
Aussi sur iPhone et iPad
Un domaine cesse de résoudre, un renouvellement de certificat échoue, ou une plainte pour abus tombe en désignant une IP que vous ne connaissez pas. La question est toujours la même : qui est derrière, et quand est-ce que ça expire ? Sur Mac, on ouvrait l'Utilitaire de réseau, onglet Whois, et on tapait le domaine. Cet onglet n'existe plus : Apple a déprécié l'Utilitaire de réseau à partir de Big Sur et l'application a disparu des versions actuelles de macOS. Sur iPhone, il n'y a jamais eu de terminal, donc whois example.com n'a jamais été une option. Le réflexe, c'est d'ouvrir un site de whois. Ça marche, mais le domaine sur lequel vous enquêtez, et l'IP de la machine depuis laquelle vous enquêtez, transitent par le serveur de quelqu'un d'autre, subissent ses quotas, et la réponse revient reformatée ou mise en cache d'une manière qui masque ce que le registre a réellement renvoyé. C'est aussi ce que font, en coulisses, les outils whois qui s'appuient sur une API REST tierce plutôt que sur le protocole lui-même. SSHive, non. L'application parle le protocole WHOIS elle-même : RFC 3912, une simple connexion TCP sur le port 43, une ligne de requête terminée par CRLF, et le serveur répond en texte libre jusqu'à ce qu'il ferme la socket. C'est tout le protocole. Comme il n'y a ni appel à /usr/bin/whois ni socket brute, le whois n'a besoin que d'une connexion TCP sortante : il fonctionne donc sur la version Mac App Store comme sur iPhone et iPad, sans aucune exception liée au bac à sable. Les deux parlent le protocole en direct ; ils diffèrent par le point de départ de la chaîne de renvois, comme expliqué plus bas. L'outil est gratuit sur toutes les plateformes. Aucun des outils réseau de SSHive n'est réservé à Pro, sur aucun appareil.

Ce que fait SSHive

TCP direct sur le port 43, sans intermédiaire

SSHive ouvre lui-même la connexion WHOIS : une socket Node sur le port 43 dans l'app Mac, une NWConnection sur iPhone et iPad. La requête part vers le serveur du registre ou du registrar et la réponse revient sur votre appareil. Aucun proxy maison sur le trajet, aucune API REST tierce ne voit quels domaines vous consultez.

Une table de registres qui évite un aller-retour

Sur le Mac, SSHive embarque une table des serveurs de registre courants : .com et .net chez Verisign, .org chez PIR, .fr chez l'AFNIC, .de chez DENIC, .uk chez Nominet, plus .io, .ca, .jp, .eu, .it et d'autres. Les TLD connus partent directement au bon registre au lieu d'interroger l'IANA d'abord. Le reste retombe sur whois.iana.org.

Suivi des renvois jusqu'au registrar

Les registres dits fins, comme Verisign, ne détiennent que le registrar, les dates et les serveurs de noms. SSHive lit le renvoi dans la réponse et relance la requête : jusqu'à trois sauts sur le Mac, en reconnaissant les lignes refer:, Registrar WHOIS Server: et ReferralServer: rwhois:// de l'ARIN. Chaque saut est annoncé dans la sortie. L'iPhone et l'iPad partent de l'IANA et suivent les renvois à partir de là.

Résumé structuré et texte brut

La version bureau extrait le domaine, le registrar et son site, les dates de création, de mise à jour et d'expiration, l'organisation, le contact, le pays, l'e-mail, DNSSEC, l'e-mail d'abus, les serveurs de noms et les codes de statut, en n'affichant que les champs réellement renvoyés. Une expiration à moins de soixante jours passe en ambre. « Afficher les détails bruts » révèle la réponse intacte, et « Copier » la met dans le presse-papiers.

Whois d'IP via l'ARIN

Saisissez une IPv4 en notation pointée sur le Mac : SSHive la détecte, attaque l'ARIN avec la syntaxe n <ip>, puis suit la ligne ReferralServer vers le RIPE, l'APNIC, LACNIC ou AFRINIC si le bloc est alloué hors zone ARIN. Vous obtenez le netblock, la plage CIDR et l'organisation détentrice. Pas de sélecteur de RIR manuel : la chaîne de renvois décide.

La même recherche sur iPhone et iPad

Sur iPhone et iPad, Whois se trouve dans l'onglet Outils, section Diagnostic. Le résultat s'ouvre sur le domaine en monospace avec le registrar en dessous, puis une section Dates avec création et expiration, puis chaque serveur de noms en minuscules, chacun avec un bouton de copie en un geste (les lignes de Dates confirment la copie d'une coche). La réponse brute complète est repliée en dessous.

Comment faire, étape par étape

  1. 1

    Ouvrir les outils réseau de SSHive

    Sur le Mac, cliquez sur l'icône réseau dans la barre latérale, ou sur la pastille Outils réseau de l'écran d'accueil. L'un comme l'autre ouvre un onglet Outils. Sur iPhone, touchez Outils dans la barre d'onglets du bas ; sur iPad, choisissez Outils réseau dans la barre latérale.

  2. 2

    Trouver la carte Whois

    Sur Mac, Whois est la dernière carte de la section Résolution et réputation, après Recherche DNS, Vérification DNSBL et Recherche MX. Sur iPhone et iPad, Whois est la quatrième ligne de la section Diagnostic, sous-titrée « Informations sur un domaine ».

  3. 3

    Saisir un domaine ou une IPv4

    Tapez la cible dans le champ (le texte d'exemple affiche « ex: google.com »). Un domaine nu fonctionne ; sur Mac, une IPv4 en notation pointée aussi, ce qui envoie la requête à l'ARIN plutôt qu'à un registre de TLD. Cliquez sur Lancer. Annuler interrompt une requête en cours.

  4. 4

    Suivre la chaîne de renvois

    La version bureau imprime une ligne à chaque interrogation de serveur et à chaque renvoi suivi : vous voyez si la réponse vient de l'IANA, du registre ou du registrar. Chaque saut dispose d'un délai de dix secondes, et seul le corps de la dernière réponse est affiché.

  5. 5

    Lire le résumé, puis le brut

    Regardez d'abord le registrar, la date d'expiration (en ambre sous soixante jours) et les codes de statut. Ouvrez ensuite Afficher les détails bruts sur Mac, ou Réponse brute sur iPhone et iPad, pour voir exactement ce que le serveur a envoyé, y compris les champs que SSHive n'analyse pas. Le lien Copier de l'en-tête copie la réponse entière.

Lire une réponse whois : statuts, dates, serveurs de noms et anonymisation

Les codes de statut sont la partie que tout le monde saute, et c'est presque toujours là que se trouve la réponse. Tout code préfixé client a été posé par le registrar ; tout code préfixé server vient du registre, et seul le registre peut le lever. clientTransferProhibited est normal et sain : c'est le verrou de transfert que la plupart des registrars activent par défaut, pas un avertissement. Ceux qui comptent sont clientHold et serverHold : un domaine en hold est retiré de la zone du TLD, il cesse donc de résoudre alors que l'enregistrement reste parfaitement valide. Si un site est tombé et que l'apex renvoie NXDOMAIN, cherchez un hold avant de toucher au DNS. redemptionPeriod signifie qu'il a déjà expiré et été supprimé ; pendingDelete qu'il sera libéré dans environ cinq jours. Un simple ok, sans aucun verrou, est sans doute plus inquiétant sur un domaine de production que clientTransferProhibited. Creation Date est la date d'enregistrement d'origine, pas celle du dernier renouvellement : une création en 2003 sur un domaine revendu l'an dernier ne dit rien de son exploitant actuel. Registry Expiry Date est la date qui fait foi, parce qu'elle vient du registre lui-même ; la version bureau la surligne en ambre à moins de soixante jours. Le panneau de votre registrar affiche souvent une date plus tardive, car les registrars renouvellent en avance. Après expiration, un gTLD passe généralement par une trentaine de jours de grâce en auto-renew, puis trente jours de rédemption avec des frais de restauration dissuasifs, puis cinq jours de pendingDelete. Les serveurs de noms affichés sont ceux que le registre détient dans la délégation, c'est-à-dire ce que la zone du TLD renvoie réellement. Comparez cette liste aux enregistrements NS obtenus par une recherche DNS : un écart signifie soit un changement de délégation non propagé, soit une délégation boiteuse dont le parent pointe vers des serveurs qui ne font plus autorité, cause classique de résolutions intermittentes. L'anonymisation est la règle, pas un aveu. Depuis le RGPD, le whois des gTLD supprime nom, adresse, téléphone et e-mail du titulaire : REDACTED FOR PRIVACY ne dit rien de la réputation d'un domaine. Ce qui subsiste est ce que l'ICANN impose toujours : registrar, dates, serveurs de noms, codes de statut et Registrar Abuse Contact Email. C'est ce dernier champ qu'il vous faut pour un signalement. Les ccTLD varient nettement : l'AFNIC publie encore les personnes morales en .fr tout en masquant les particuliers, et DENIC ne renvoie guère plus que des champs techniques pour .de.

Questions fréquentes

Le whois fonctionne-t-il dans la version Mac App Store de SSHive ?+
Oui, sans rien en moins. Le whois ne demande rien de plus qu'une connexion TCP sortante sur le port 43, que le bac à sable d'Apple autorise : il n'y a donc aucun écart de fonctionnalité, ni pour lui, ni pour le reste de la suite : le ping et le traceroute émettent du vrai ICMP depuis la version App Store également, via un socket datagramme que le bac à sable autorise.
Pourquoi le whois de mon iPhone affiche-t-il moins de champs que celui de mon Mac ?+
Parce que les deux apps n'extraient pas les mêmes champs. Toutes deux suivent la chaîne de renvois : le Mac embarque une table de serveurs de registre, la requête part donc directement chez Verisign ou l'AFNIC, puis suit jusqu'à deux renvois (trois sauts) pour atteindre le registrar ; l'iPhone et l'iPad partent de l'IANA et suivent les renvois à partir de là. Mais le résumé mobile ne garde que le registrar, les dates et les serveurs de noms. DNSSEC, codes de statut, titulaire et contact d'abus ne s'affichent que sur Mac ; sur iPhone et iPad, ouvrez Réponse brute pour les lire.
Pourquoi le nom du propriétaire est-il remplacé par REDACTED FOR PRIVACY ?+
Le RGPD. Depuis 2018, les registres et registrars de gTLD retirent par défaut nom, adresse, téléphone et e-mail du titulaire de la sortie whois publique, et aucun client ne peut les récupérer : la donnée n'est tout simplement pas envoyée sur le port 43. Ce n'est pas un signe de domaine suspect, cela s'applique à quasiment tous les .com. Restent le registrar, les dates, les serveurs de noms, les codes de statut et le Registrar Abuse Contact Email, qui est le bon canal pour un signalement. Certains ccTLD sont moins stricts : l'AFNIC publie encore les .fr détenus par des personnes morales.
Puis-je faire un whois sur une adresse IP plutôt que sur un domaine ?+
Sur le Mac, oui. SSHive détecte une IPv4 en notation pointée, ouvre la requête chez l'ARIN avec la syntaxe n <ip>, puis suit la ligne ReferralServer vers le RIPE, l'APNIC, LACNIC ou AFRINIC si le bloc est alloué hors zone ARIN. Vous obtenez le netblock, la plage CIDR et l'organisation détentrice. Pas de sélecteur de RIR manuel : la chaîne de renvois décide. Une réserve : les renvois rwhois portant un port non standard sont malgré tout contactés sur le port 43.
SSHive fait-il transiter mes recherches par ses propres serveurs ?+
Non. La connexion part de votre Mac, iPhone ou iPad directement vers le serveur whois de l'IANA, du registre ou du registrar. Aucun backend SSHive sur le trajet, aucune API REST tierce, alors que plusieurs applications whois iOS sont construites exactement ainsi. Soyons précis sur la portée de cette affirmation : le serveur whois interrogé voit toujours votre adresse IP, c'est le fonctionnement de TCP. Ce qui change, c'est que personne entre les deux ne conserve de trace de vos requêtes.
L'outil whois est-il gratuit ou faut-il Pro ?+
Gratuit, sur Mac, iPhone et iPad. Aucun outil réseau de SSHive (whois, recherche DNS, ping, traceroute, recherche MX, vérification DNSBL) n'est soumis à une vérification de licence, sur aucune plateforme. SSHive Pro est un paiement unique d'environ 14,99 €, en achat universel pour Mac, iPhone et iPad, sans abonnement ni compte, et il débloque par exemple les sessions RDP et VNC, davantage de tunnels ou les gros envois SFTP. Les outils réseau n'en font pas partie.
Ma requête n'a rien renvoyé ou s'est bloquée. Que s'est-il passé ?+
Trois causes fréquentes. Le TLD n'est peut-être pas dans la table de registres de SSHive : la requête démarre alors à l'IANA et dépend de la présence d'un renvoi bien formé. Le registre vous limite peut-être en débit : les serveurs whois coupent les requêtes répétées venant d'une même IP, et SSHive ne détecte pas cette situation et n'applique aucun back-off, vous obtenez donc un corps tronqué ou vide. Ou le serveur reste muet : le Mac abandonne au bout de dix secondes par saut, et sur iPhone et iPad une recherche qui semble bloquée s'annule et se relance.

Le protocole derrière l'outil : RFC 3912, registres fins et sandbox Apple

WHOIS est défini par la RFC 3912, et la spécification tient sur deux pages. On ouvre une connexion TCP sur le port 43, on envoie une seule ligne terminée par CRLF, et on lit ce que le serveur renvoie jusqu'à ce qu'il ferme la connexion. Pas de schéma, pas de type de contenu, pas d'en-tête de longueur, pas d'authentification, pas de chiffrement. La réponse est du texte libre dont la mise en forme dépend entièrement de l'opérateur : c'est pourquoi tout client whois est un empilement d'heuristiques plutôt qu'un parseur. L'absence d'en-tête de longueur a une conséquence concrète côté client : le seul signal fiable de fin de message est le FIN. L'implémentation iOS de SSHive boucle donc sur des réceptions NWConnection avec une taille maximale de 65536 octets et continue d'accumuler jusqu'à la complétion du flux, au lieu de s'arrêter au premier bloc. La version bureau fait de même sur une socket Node, avec un délai de dix secondes par saut pour qu'un serveur muet ne bloque pas le panneau. Deuxième complication : la donnée recherchée est rarement sur le premier serveur interrogé. L'espace de noms est hiérarchique. L'IANA sait quel registre gère chaque TLD, le registre sait quel registrar parraine chaque domaine, et pour les registres fins seul ce registrar détient les coordonnées. Verisign est fin pour .com et .net : une requête n'y renvoie guère plus que le registrar, les dates et les serveurs de noms. PIR est épais pour .org et répond bien plus complètement en un seul appel. Suivre la chaîne suppose de reconnaître trois écritures de renvoi : refer: chez l'IANA et l'ARIN, Registrar WHOIS Server: chez les registres de gTLD, et ReferralServer: rwhois://hôte:port chez l'ARIN. La version bureau gère les trois et suit jusqu'à trois sauts, et sa table de serveurs de registre permet aux TLD courants d'éviter complètement le passage par l'IANA. La version iPhone et iPad part toujours de l'IANA et suit les renvois à partir de là, et son résumé garde moins de champs que celui du Mac. Les limites, dites franchement : seul le corps du dernier saut est affiché, les réponses intermédiaires sont écartées ; les renvois rwhois portant un port non standard sont malgré tout contactés sur le 43 ; et il n'y a aucune détection de quota, donc marteler un registre finit par renvoyer un refus plutôt que des données. L'avantage de cette conception, c'est la portabilité. Le port 43 n'est qu'une connexion TCP sortante ordinaire, couverte par l'entitlement réseau client standard, sans binaire privilégié à lancer ni socket brute à demander. C'est précisément pour cela que le whois se comporte de façon identique dans la version Mac App Store, sur iPhone et sur iPad. C'est désormais vrai aussi du ping et du traceroute, qui atteignent cette parité autrement : non pas en évitant l'ICMP, mais en utilisant le socket ICMP datagramme que Darwin accorde aux processus non privilégiés et que le bac à sable autorise.

Outils liés

Recherche DNS

Recherche MX

Vérification DNSBL