Outils populaires

Thème

Recherche de Sous-domaines

Trouvez les sous-domaines d'un domaine dans les journaux de certificats, dans une liste de noms courants, sur sa page d'accueil et dans ses enregistrements DNS, puis voyez lesquels se résolvent, où chacun est hébergé et quand son certificat expire.

Sources : Cert Spotter et crt.sh (recherches dans les journaux CT) · noms courants, page d'accueil, enregistrements DNS, transfert de zone · DNS en direct via Google · réseaux via Team Cymru

6 sources · DNS en direct

Un sous-domaine ou une URL fonctionne aussi : docs.python.org cherche dans tout python.org.

  • Cert Spotter · Non expirés seulement · notre serveur
  • crt.sh · Depuis 2013 · votre navigateur
  • Noms courants · 1 000 labels · notre serveur
  • Page d'accueil · Liens, en-têtes · notre serveur
  • Enregistrements DNS · NS, MX, SPF… · notre serveur
  • Transfert de zone · Chaque serveur de noms · notre serveur
Vérification DNSGoogle Public DNSA, AAAA et CNAME pour chaque nom
Essayez

Comment fonctionne une recherche de sous-domaines ?

Elle rassemble des noms tirés de sources publiques et du DNS du domaine lui-même, puis interroge le DNS sur chacun.

Chaque certificat HTTPS émis par une autorité de confiance est inscrit dans les journaux Certificate Transparency avec chaque nom qu'il couvre. Cet outil lit deux services de recherche dans ces journaux : Cert Spotter pour les certificats actuels et crt.sh pour tous les certificats depuis 2013. En parallèle, il interroge le DNS sur 1 000 noms courants, lit les liens de la page d'accueil et les enregistrements du domaine, et tente un transfert de zone.

Le DNS transforme ensuite la liste en carte. Un nom qui se résout obtient ses adresses et le réseau qui les annonce, ce qui désigne l'hébergeur ou le CDN. Un nom tiré d'un certificat ou d'un enregistrement DNS qui ne se résout pas aujourd'hui a bien existé : c'est un nom retiré du service. Un lien de la page d'accueil peut, lui, pointer vers un nom qui n'a jamais existé.

  • Cert Spotter511,1 s
  • crt.sh7421,6 s
  • Noms courants242,6 s
  • Page d'accueil141,9 s
  • Enregistrements DNS10,4 s
  • Transfert de zoneRefusé ×42,3 s
Fusionnés
Doublons et wildcards retirés, sans compter le domaine lui-même
81sous-domaines
DNS : A, AAAA, CNAME
61 se résolvent20 non
Hébergeurs et CDN
10réseaux
  • Journaux de certificats : chaque nom figurant sur un certificat public ; Cert Spotter est à jour, crt.sh remonte à 2013.
  • Noms courants, page d'accueil, enregistrements : des noms actifs qu'aucun certificat ne liste.
  • DNS : une requête par nom et par type à Google Public DNS.
python.org, recherché le 22 octobre 2026 : ce que chaque étape a trouvé et combien de temps elle a pris.
Recherche de sous-domaines sur python.org : 81 trouvés, ceux qui se résolvent, la carte des hébergeurs et les certificatsRecherche de sous-domaines sur python.org : 81 trouvés, ceux qui se résolvent, la carte des hébergeurs et les certificatsLa réponse d'abordCombien de noms ont été trouvés, combien se résolvent aujourd'hui, et sur combien de réseaux.Des faits DNS, pas des verdictsDNS wildcard, certificats wildcard, noms qui ne se résolvent pas, noms qu'aucun journal de certificats ne liste et transfert de zone, chacun avec sa preuve.Où chaque nom est hébergéUne bande par hébergeur ou CDN, aussi large que son nombre de noms, avec les plateformes que révèlent ses CNAME.Chaque nom à un clicChaque étiquette est un lien vers sa ligne : statut, adresses, chaîne CNAME, hébergeur et dates du certificat.
Une recherche pour python.org : les totaux, les notes DNS et la carte de l'hébergement de chaque sous-domaine. Sélectionnez un numéro pour voir ce que montre chaque partie.

Comment trouver tous les sous-domaines d'un domaine ?

Combinez des sources passives et quelques requêtes DNS : aucune méthode ne trouve à elle seule tous les noms.

Les journaux de certificats listent chaque nom qui a eu un certificat public, mais rien sous un wildcard, ni rien qui n'a jamais servi en HTTPS. Interroger le DNS sur des noms courants trouve des hôtes actifs que les journaux n'ont jamais vus. La page d'accueil et les enregistrements du domaine en nomment quelques autres, et un transfert de zone, quand un serveur l'autorise, liste toute la zone.

Cet outil les lance tous en même temps. Les méthodes qui exigent un jeu de données payant (DNS passif) ou qui copient les données d'autres sites contre leurs conditions (scraping des moteurs de recherche, certaines API publiques) ne sont pas utilisées.

MéthodeTrouveManqueIci
Journaux de certificatsChaque nom sur un certificat public depuis 2013Noms sous un wildcard ; noms jamais servis en HTTPSLes deux recherches
Noms courantsHôtes actifs aux labels faciles à devinerLabels inhabituels1 000 + 4 000
Page d'accueilHôtes que le site lie ou chargeNoms sans lienOui
Enregistrements DNSHôtes de messagerie, de serveurs de noms et SPFTout le resteOui
Transfert de zoneToute la zone, là où c'est autoriséRefusé presque partoutChaque serveur de noms
Parcours NSECChaque nom d'une zone en NSEC simpleZones en NSEC3 et zones non signéesPas encore
DNS passifNoms vus dans le trafic des résolveursExige un jeu de données payantNon
Moteurs de rechercheHôtes des pages indexéesNoms non indexés ; le scraping enfreint leurs conditionsNon
Méthodes de recherche de sous-domaines : ce que chacune trouve, ce qu'elle manque, et celles que cet outil utilise.

Comment trouver les sous-domaines qui n'ont pas de certificat ?

Interrogez le DNS sur des noms probables : chaque domaine que nous avons mesuré avait des noms actifs qu'aucun journal de certificats n'a jamais listés.

Nous avons interrogé 1 000 labels courants (www, mail, vpn, dev…) sous 13 domaines connus et comparé les résultats à l'historique complet de crt.sh. Chaque domaine avait de 3 à 71 noms actifs qu'aucun journal n'avait jamais montrés ; uber.com (71), kompas.com (37) et github.com (32) en ont gagné le plus. Les liens de la page d'accueil en ont ajouté jusqu'à 65 de plus (kompas.com) ; les 160 sites linguistiques liés par wordpress.org ne peuvent pas être confirmés dans le DNS, car son wildcard répond à tous les noms.

L'outil interroge par défaut les 1 000 premiers labels de la liste SecLists, et 4 000 de plus à la demande, ce qui, au total, a trouvé environ 60 % de résultats en plus pour cinq fois plus de requêtes. Le DNS wildcard est testé en premier : un nom deviné ne compte que s'il a son propre enregistrement.

Noms actifs qu'aucun journal de certificats n'a listés1 000 labels courants, réponses wildcard retirées
  • uber.com71
  • kompas.com37
  • github.com32
  • stripe.com28
  • tesla.com22
  • tokopedia.com20
  • wordpress.org14
  • nasa.gov13
  • isc.org7
  • ycombinator.com6
  • python.org5
  • mozilla.org5
  • dnsrobot.net3
  • jamais dans CT
  • dans les journaux CT
  • wordpress.org: DNS wildcard : se résoudre ne prouve rien
Mesuré par DNS Robot le 22 octobre 2026 : 13 domaines, comparés à l'historique complet de crt.sh.

Qu'est-ce que la Certificate Transparency, et comment révèle-t-elle les sous-domaines ?

La Certificate Transparency (CT) est un ensemble de journaux publics, en ajout seul (append-only), de chaque certificat émis par les autorités de confiance.

Les navigateurs l'imposent : Chrome rejette un certificat émis après le 30 avril 2018 s'il ne porte pas d'horodatages signés par des journaux CT. Chaque journal est un arbre de Merkle que tout le monde peut lire et que personne ne peut modifier : une fois un certificat journalisé, chacun de ses noms est public, souvent avant même que le site commence à l'utiliser.

C'est pourquoi un nouveau sous-domaine apparaît ici dès qu'il passe en HTTPS, et qu'un ancien reste trouvable une fois éteint. Une recherche certificate transparency comme crt.sh ou Cert Spotter lit ces journaux pour vous ; cet outil interroge les deux.

Google Argon 2026h2l'un des journaux reconnus par Chrome3,45 Md entrées
plus ancienne entréeajout seul : les entrées ne sont jamais modifiées ni suppriméesplus récente
Le certificat journalisé
Émetteur
Let's Encrypt
Émis le
20 oct. 2026
Expire le
18 janv. 2027
Noms dans le certificatblurb-it.python.org
Dans cet outil
blurb-it.python.orgSe résout
↳ …elb.amazonaws.comAWS
Qui a émis les certificats journalisés dans les 28 jours précédant le 22 octobre 2026
  • Let's Encrypt 52,35%
  • Google Trust Services 22,21%
  • Toutes les autres autorités 25,44%
Sources : le signed tree head d'Argon 2026h2 et les données CT de Cloudflare Radar, 22 octobre 2026 ; le certificat, de Cert Spotter.

Pourquoi un sous-domaine ne se résout-il pas ?

Parce que le DNS n'a plus d'adresse pour lui : le nom a été supprimé, n'a jamais eu d'adresse, ou pointe vers quelque chose qui a disparu.

NXDOMAIN signifie que le nom n'existe plus. Sans adresse (NOERROR sans enregistrement A ni AAAA) signifie qu'il existe, mais seulement pour d'autres enregistrements, comme la messagerie. Orphelin signifie que son CNAME pointe vers une cible qui n'existe pas.

Les anciens noms sont la norme : sur 2 036 noms tirés des journaux de certificats de 11 domaines que nous avons vérifiés, la moitié n'existait plus. Un nom qui ne se résout pas n'est pas une erreur de cette page : c'est un nom retiré que vous voudrez peut-être nettoyer.

2 036 noms tirés des journaux de certificats de 11 domaines
  • 922 se résolvent (45%)
  • 1 008 NXDOMAIN (50%)
  • 106 sans adresse (5%)
  • blog-stage.python.org
    $ dig blog-stage.python.org
status: NXDOMAIN
    Ne se résout pasLe nom n'existe pas.
  • mg.python.org
    $ dig mg.python.org A
status: NOERROR, ANSWER: 0
$ dig +short mg.python.org MX
10 mxa.mailgun.org.
    Sans adresseIl existe, mais seulement pour d'autres enregistrements, comme la messagerie.
  • shop.example.com
    $ dig shop.example.com
shop.example.com. CNAME old-shop.example.net.
old-shop.example.net: NXDOMAIN
    OrphelinIl pointe vers un nom qui a disparu.
Mesuré par DNS Robot le 22 octobre 2026. Les exemples sont des noms fictifs sous example.com, sauf blog-stage et mg, issus de la recherche sur python.org.

Qu'est-ce qu'un CNAME orphelin (dangling) ?

Un CNAME orphelin (dangling CNAME) est un enregistrement DNS qui pointe encore vers un nom qui n'existe plus, comme un répartiteur de charge supprimé ou un service hébergé résilié.

C'est d'abord un point de nettoyage : le sous-domaine affiche une erreur et l'enregistrement ne sert à rien. Sur 2 036 noms de certificats de 11 domaines, nous avons trouvé 25 CNAME orphelins, sur 8 des 11 domaines, surtout des répartiteurs de charge cloud supprimés.

Cela peut aussi être un risque. Si la cible est un service où n'importe qui peut revendiquer le nom libéré, comme un bucket de stockage ou un site sur certaines plateformes, un inconnu pourrait servir des pages sur votre sous-domaine : c'est la prise de contrôle de sous-domaine (subdomain takeover). Cet outil affiche le fait DNS pour chaque nom, et n'indique « prise de contrôle possible » que si le CNAME et la page correspondent tous deux à la signature publiée de ressource non revendiquée d'un service.

L'enregistrementshop.example.comCNAME
La cibleold-shop.example.netNXDOMAIN : supprimé
25

25 CNAME orphelins sur 2 036 noms (1,2 %), sur 8 des 11 domaines

  • Répartiteurs de charge cloud supprimés
  • Points de terminaison Skype for Business Online retirés
  • Un forum hébergé résilié
  1. OrphelinLa cible du CNAME n'existe pasUn fait DNS, affiché pour chaque nom : supprimez l'enregistrement s'il ne sert plus.
  2. Prise de contrôle possibleLe CNAME et la page correspondent à la signature de ressource non revendiquée d'un serviceAffiché avec la preuve. Des indices, pas une preuve.
  3. Pas exposé à la prise de contrôleLe service vérifie à qui appartient un domaineFastly, CloudFront, Zendesk, Statuspage et d'autres : jamais signalés.
Mesuré par DNS Robot le 22 octobre 2026 ; les niveaux suivent can-i-take-over-xyz. L'enregistrement montré est fictif.

Le transfert de zone de votre DNS est-il ouvert ?

Presque certainement pas : tous les serveurs de noms des 12 domaines réels que nous avons testés ont refusé un transfert de zone DNS.

Un transfert de zone (AXFR) sert à copier une zone vers ses serveurs secondaires. Demandé par n'importe qui d'autre, un serveur ouvert envoie chaque nom de la zone. Le RFC 5936 dit que les serveurs devraient le restreindre et ne pas être ouverts à tous par défaut.

L'outil envoie une requête AXFR à chacun des serveurs de noms du domaine et indique chaque réponse. Seul le domaine de test zonetransfer.me, créé pour illustrer le problème, a répondu, avec ses 52 enregistrements.

Requête AXFR à chaque serveur de nomsAXFR python.org
  • ns-1134.awsdns-13.org205.251.196.110REFUSED
  • ns-2046.awsdns-63.co.uk205.251.199.254REFUSED
  • ns-981.awsdns-58.net205.251.195.213REFUSED
  • ns-484.awsdns-60.com205.251.193.228REFUSED
zonetransfer.me · le domaine de test public
  • nsztm1.digi.ninjaAXFR zonetransfer.me52 enregistrements envoyés

12 domaines réels sur 12 ont refusé sur tous leurs serveurs de noms

Mesuré par DNS Robot le 22 octobre 2026 : les quatre serveurs de noms de python.org, et zonetransfer.me.

Pourquoi tous les sous-domaines ne peuvent-ils pas être trouvés ?

Parce que certains noms ne sont jamais publics : aucun certificat ne les nomme, aucun lien n'y mène et aucun label courant ne correspond.

Trois sortes de noms n'atteignent que rarement, voire jamais, les journaux, et le DNS ne les trouve que si leur label est facile à deviner. Environ 36 % des entrées de certificats journalisées dans les 28 jours précédant le 22 octobre 2026 portaient un nom wildcard, et chacune cache les noms qu'elle sert.

  • *.python.org?.python.org?.python.orga.b.python.orgcouvertcouvertdeux niveaux :non couvertservis, mais absents des journaux

    Les noms sous un wildcard

    Un certificat *.python.org couvre chaque nom situé un niveau en dessous sans en lister aucun. Le journal enregistre le wildcard, pas les noms qu'il sert.

    Dans les journauxSeulement *.python.org
  • Réseau interne, DNS privéintranet.corp.exampleprinter.corp.examplenas.corp.example
    Journaux CT publics
    aucun certificat public

    Les noms d'un réseau privé

    Les noms qui n'existent que dans le DNS interne d'une entreprise obtiennent rarement un certificat public. Sans certificat, ils n'atteignent jamais un journal.

    Dans les journauxRien
  • ssh.example.com:22relay.example.com:25ftp.example.com:21
    pas de HTTPS, pas de certificat

    Les noms sans HTTPS

    Un hôte SSH, un relais de messagerie ou un vieux serveur FTP n'a pas besoin de certificat public : son nom n'atteint donc souvent jamais un journal.

    Dans les journauxRien
36%des entrées de certificats journalisées dans les 28 jours précédant le 22 octobre 2026 portaient un nom wildcard (Cloudflare Radar). Chacune cache les noms qu'elle sert.

Où chaque sous-domaine est-il hébergé ?

Les adresses de chaque nom appartiennent à un réseau, et ce réseau désigne l'hébergeur ou le CDN qui le fait tourner.

L'outil demande à Team Cymru quel réseau annonce chaque adresse, puis compare le réseau et la chaîne CNAME aux plus de 200 fournisseurs du Vérificateur d'hébergement. Un CNAME révèle souvent la plateforme derrière un CDN : Read the Docs derrière Cloudflare, ou Heroku et Netlify sur le réseau d'Amazon.

Derrière un CDN, les adresses sont celles de l'edge du CDN, les mêmes pour de nombreux sites ; le serveur qui se trouve derrière reste privé. L'outil ne devine jamais une adresse d'origine.

Où sont hébergés les sous-domaines de python.org61 se résolvent
  • DigitalOceanAS1406114
  • FastlyAS5411311
  • GitHub PagesAS5411311
  • Amazon Web ServicesAS16509· via9
  • HetznerAS249406
  • CloudflareAS13335· via5
  • Google CloudAS396982· via2
  • OVHcloudAS162761
  • Advanced Software Production Line, S.L.AS2061021
  • Civilized Discourse Construction Kit, Inc.AS394230· via1
  • University of OregonAS37011
  • Edge du CDN : adresses partagées, l'origine reste privée
  • le propre réseau de l'hébergeur
python.org, 22 octobre 2026 : les noms qui se résolvent, par hébergeur, d'après les réseaux de Team Cymru et les chaînes CNAME.

Qu'est-ce que l'énumération de sous-domaines ?

L'énumération de sous-domaines consiste à lister les sous-domaines d'un domaine, passivement à partir de sources publiques ou activement en interrogeant le DNS et en envoyant des requêtes.

Les sources passives lisent ce qui est déjà public, comme les journaux de certificats, et n'envoient rien aux serveurs du domaine. Les vérifications actives posent au DNS une question par nom, ici via Google Public DNS, récupèrent la page d'accueil ou demandent un transfert de zone aux serveurs de noms du domaine. Les équipes de sécurité énumèrent les sous-domaines pour trouver les hôtes oubliés avant quelqu'un d'autre, souvent avec un subdomain scanner ; ici, un scan de sous-domaines ne lance que les vérifications légères et standard : noms courants, enregistrements, page d'accueil et transfert de zone.

Passive

Lit des sources publiques ; n'envoie rien au domaine

  • Cert Spotter51 noms
  • crt.sh74 noms

Active

Interroge Google Public DNS sur chaque nom, récupère la page d'accueil et demande la zone à chaque serveur de noms

  • Noms courants24 noms
  • La page d'accueil14 noms
  • Enregistrements DNS1 nom
  • Transfert de zoneRefusé ×4
La recherche sur python.org : ce que chaque type de source a trouvé.

Comment NSEC et NSEC3 cachent-ils ou révèlent-ils les noms d'une zone ?

Dans une zone signée avec DNSSEC, les enregistrements NSEC enchaînent chaque nom au suivant, si bien que n'importe qui peut parcourir la chaîne ; NSEC3 hache les noms pour l'empêcher.

Demander un nom absent dans une zone en NSEC simple renvoie les deux vrais noms qui l'entourent ; en répétant l'opération, on parcourt toute la zone. NSEC3 renvoie plutôt des empreintes, qu'un dictionnaire peut encore casser. Une méthode plus récente, le déni compact (RFC 9824), ne révèle aucun voisin.

La plupart des domaines que nous avons vérifiés utilisent NSEC3 ou pas de DNSSEC ; quelques-uns, comme isc.org, utilisent encore le NSEC simple.

NSECle vrai nom suivant, dans l'ordre

?blog.example.comapi.example.com→docs.example.com
isc.orgnlnetlabs.nlsidn.nlripe.net

NSEC3l'empreinte du nom suivant

?blog.example.com2vptu5timamqttgl…→b4um86eghhds6nea…
iana.orgicann.orgverisign.comnic.czdenic.deafnic.frpaypal.combund.degov.uk

Déni compactun nom suivant inventé : rien à parcourir

?blog.example.comblog.example.com→\000.blog.example.com
cloudflare.com

Sans DNSSECNXDOMAIN

?blog.example.com→NXDOMAIN
google.comdnsrobot.net
Réponses de déni d'existence pour un nom aléatoire, mesurées par DNS Robot le 22 octobre 2026. La chaîne montrée est fictive.

Que faire de la liste ?

Tenir un inventaire, nettoyer les anciens enregistrements et vérifier ce que sert chaque sous-domaine.

Exportez la liste en CSV, supprimez les enregistrements des noms qui ne se résolvent plus, et vérifiez le certificat, l'hébergeur et les enregistrements DNS de ceux qui se résolvent.

Données et crédits

  • Données de certificats de Cert Spotter (SSLMate) et de crt.sh (Sectigo).
  • Noms courants : les 1 000 (et 5 000) premiers labels de subdomains-top1million-5000.txt de SecLists, © Daniel Miessler, licence MIT.
  • Signatures de prise de contrôle adaptées de can-i-take-over-xyz par EdOverflow et ses contributeurs, CC BY 4.0, modifiées par DNS Robot.
  • Réseaux issus du service IP to ASN de Team Cymru ; réponses DNS de Google Public DNS.

FAQ de la recherche de sous-domaines

Qu'est-ce qu'un outil de recherche de sous-domaines ?

Un outil de recherche de sous-domaines, qu'on appelle aussi subdomain finder ou subdomain lookup, liste les noms situés sous un domaine, comme blog.example.com. Celui-ci lance deux recherches dans les journaux Certificate Transparency, interroge le DNS sur 1 000 noms courants, lit la page d'accueil et les enregistrements DNS du domaine, et tente un transfert de zone. Il vérifie ensuite chaque nom dans le DNS en direct : s'il se résout, ses adresses et son hébergeur.

Cette recherche de sous-domaines est-elle gratuite, et quelles sont ses limites ?

Oui, gratuite et sans inscription. Chaque recherche liste tous les noms que renvoient les sources et en vérifie jusqu'à 2 000 dans le DNS ; les autres sont listés comme non vérifiés, avec un bouton pour les 500 suivants. Vous pouvez interroger 4 000 noms courants de plus et vérifier jusqu'à 100 serveurs web par clic. Les réponses sont conservées par domaine pendant quelques heures, jamais par visiteur.

Combien de sous-domaines un domaine peut-il avoir ?

Il n'y a pas de limite fixe. Le DNS limite chaque label à 63 caractères et un nom complet à 253 sous forme écrite (255 octets sur le réseau), mais aucune norme ne limite le nombre de noms d'une zone. La plupart des domaines en ont quelques dizaines ; les grandes organisations, des milliers. Lors de nos tests, nasa.gov comptait plus de 21 000 noms dans les journaux de certificats, et python.org 81 sous-domaines toutes sources confondues.

Pourquoi certains sous-domaines manquent-ils ?

Un nom n'apparaît que si une source le connaît. Les noms sous un certificat wildcard, les noms des réseaux privés et les noms qui n'ont jamais servi en HTTPS n'atteignent que rarement, voire jamais, les journaux de certificats, et le DNS ne les trouve que si leur label est courant. Environ 36 % des entrées de certificats journalisées dans les 28 jours précédant le 22 octobre 2026 portaient un nom wildcard. Un transfert de zone listerait tout, mais presque tous les serveurs le refusent.

Qu'est-ce que crt.sh ?

crt.sh est une recherche certificate transparency gratuite gérée par Sectigo. Il lit tous les journaux reconnus par Chrome et conserve chaque certificat depuis 2013 : il liste donc aussi les noms dont les certificats ont expiré. Il peut être lent et accuser des semaines de retard sur les journaux les plus actifs ; c'est pourquoi cet outil l'interroge depuis votre navigateur et ajoute Cert Spotter pour les certificats actuels.

Est-il légal de rechercher les sous-domaines d'un domaine ?

Lire les journaux de certificats, c'est lire des informations publiques : journaliser chaque nom est la raison d'être de la Certificate Transparency. Les requêtes DNS de cet outil sont les mêmes que celles de n'importe quel navigateur ou serveur de messagerie, une par nom. Des tests plus poussés sur des systèmes qui ne vous appartiennent pas, comme des scans de ports ou des tentatives de connexion, exigent l'autorisation du propriétaire ; cet outil ne fait rien de tout cela.

Comment vérifier si un sous-domaine est actif ?

Recherchez son domaine ici et regardez sa ligne : Se résout signifie que le DNS lui donne une adresse aujourd'hui, avec les adresses et l'hébergeur à côté. Ne se résout pas signifie NXDOMAIN ou aucune adresse. Pour savoir si un serveur web répond, sélectionnez Vérifier les serveurs web : le code de statut, le titre de la page et le serveur s'affichent sous chaque nom. L'outil sert ainsi aussi de vérificateur de sous-domaines.

Qu'est-ce qu'un certificat wildcard ?

Un certificat wildcard couvre chaque nom situé un niveau en dessous, comme *.example.com pour blog.example.com et shop.example.com, sans les lister. Les journaux de certificats ne montrent alors que le wildcard : les noms qu'il sert restent cachés pour tout outil qui lit les journaux. Un wildcard ne couvre jamais deux niveaux : a.b.example.com doit figurer en propre sur un certificat, ou être couvert par un wildcard *.b.example.com.

Qu'est-ce qu'un transfert de zone DNS ?

Un transfert de zone DNS (AXFR) copie une zone entière, chaque nom et chaque enregistrement, d'un serveur de noms à un autre. Il existe pour que les serveurs secondaires restent synchronisés. Si un serveur l'autorise à n'importe qui, la zone peut être téléchargée : les serveurs devraient donc le réserver à leurs secondaires. Cet outil teste chaque serveur de noms et affiche ouvert, refusé ou non testable.

Qu'est-ce qu'une prise de contrôle de sous-domaine (subdomain takeover) ?

Une prise de contrôle de sous-domaine se produit quand un enregistrement DNS, le plus souvent un CNAME, pointe encore vers une ressource cloud ou hébergée qui a été supprimée, et que quelqu'un d'autre revendique le nom de cette ressource. Il peut alors servir du contenu sur le sous-domaine. Cet outil affiche les CNAME orphelins comme un fait DNS, et n'indique prise de contrôle possible que si le CNAME et la page correspondent à une signature connue de ressource non revendiquée.

Puis-je cacher mes sous-domaines ?

En partie. Utilisez un certificat wildcard pour que les noms n'apparaissent pas un par un dans les journaux, gardez les noms internes dans un DNS interne, refusez les transferts de zone à quiconque n'est pas l'un de vos secondaires, et évitez les labels faciles à deviner pour les services privés. Les noms DNS sont toutefois rarement secrets : considérez tout nom public comme trouvable et protégez le service qui se trouve derrière.

Existe-t-il une API ?

Oui. GET https://dnsrobot.net/api/subdomain-finder?domain=example.com diffuse chaque étape sous forme d'une ligne JSON aux scripts et aux serveurs ; les pages d'autres sites ne peuvent pas l'appeler depuis un navigateur (elles reçoivent une erreur 403). Le POST avec {"domain": …} répond toujours au format de la version précédente. L'API est gratuite, avec une limite de 10 recherches par minute par adresse, et l'étape crt.sh est laissée à l'appelant.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Plus d'outils de domaine et DNS