Comment trouver tous les noms d'hôtes dans DNS attachés à une IP?


24

Si j'ai plusieurs hôtes configurés sur une machine ( VirtualHosts à la apache), comment puis-je faire une recherche sur l'IP et trouver tous les domaines configurés pour y accéder?

Par exemple, j'ai plusieurs domaines Web et de messagerie connectés à mon serveur. Comment puis-je trouver tous les domaines qui pointent vers celui-ci?

Est-ce même possible?

J'ai des entrées DNS A pour tous les domaines que je possède, et je sais que les domaines de certains amis pointent vers mon serveur. Ce que j'aimerais voir, c'est si des gens que je ne connais pas pointent là aussi. (Ou si quelqu'un a rejoint le domaine ailleurs et que je peux supprimer son «ancien» site Web de mon serveur.)

Réponses:


30

Non, pas vraiment. Il s'agit de la différence entre les recherches DNS directes et inverses.

Une recherche directe est la recherche standard de nom-> IP. Il faudrait donc connaître tous les noms à l'avance.

Ce que vous voulez, c'est faire une recherche de nom IP->, mais obtenir en quelque sorte tous les noms que vous avez appliqués dans votre configuration Apache et dans DNS en tant qu'enregistrements A (ou CNAMES ou autre).

Ce que vous trouverez probablement, c'est que faire une recherche inversée (par exemple, dig @nameserver $ ip -x) retournera le nom d'hôte donné à cette IP par les personnes qui possèdent ce netblock, qui pourrait être votre FAI. Il pourrait avoir un nom comme 45-23-45-231.big-isp.com, ce qui ne signifie pas grand-chose pour vous. Et surtout, il n'y a qu'un seul enregistrement inversé, mais potentiellement de nombreux enregistrements avant.

Je suppose que cela se résume à la question - comment la zone inverse connaît-elle l'un des enregistrements de la zone avant? Dans la plupart des configurations, la zone directe est mise à la disposition du client pour y apporter des modifications, mais la zone inverse est gérée par les propriétaires du netblock. Les deux systèmes n'ont pas besoin de se connaître pour fonctionner.


2
Cela me semble juste.
einstiien

honte - ce serait aussi très pratique
warren

12

Il n'est pas possible de le faire avec le protocole DNS lui-même, car il n'y a généralement qu'un seul PTRenregistrement pour chaque adresse IP, même s'il peut y avoir de nombreux Aenregistrements pointant vers cette adresse IP.

Cependant, certaines entreprises (par exemple, http://www.ip-adress.com/ ) ont réussi à compiler des bases de données contenant ce que vous recherchez en stockant les résultats d'une charge complète de recherches DNS, puis en proposant une requête inverse dans leur propre bases de données.

Ces bases de données ne peuvent cependant pas être définitives, elles ne peuvent pas garantir de connaître tous les domaines possibles susceptibles de pointer vers cette IP - elles ne peuvent enregistrer que les détails DNS des noms de domaine qu'ils ont réellement recherchés.


c'est ce dont j'avais peur .. sacrément: - |
warren

1
Juste un avertissement que je n'ai pas encore rencontré un tel service de recherche qui gère tous les TLD. En fait, tous ceux que j'ai essayés n'ont pas réussi à répertorier les domaines .com.au, même lorsqu'ils sont hébergés sur le même serveur que les domaines .com.
John Gardeniers

1
étrange - il n'y a aucune raison qu'un service comme celui-ci se soucie même du TLD sur lequel le site se trouve. Cela dit, comme je l'ai mentionné, les bases de données ne connaissent que les sites sur lesquels les gens posent des questions - je suppose que peu de gens se soucient des domaines .com.au ;-)
Alnitak

4

La seule façon de procéder consiste à disposer des données de contenu du nom de domaine que vous souhaitez inspecter.

Avec ce contenu, vous pouvez développer un script récursif pour rechercher le nom d'hôte par rapport à votre IP (récursif en raison de l'éventuel CNAME à vérifier).

Pour obtenir les données d'un partenaire de nom de domaine, vous pouvez demander à être secondaire et obtenir des DONNÉES avec un dig -t axfr.


3

Je pense que vous arrivez dans cette mauvaise direction. Mis à part a) interroger chaque serveur DNS existant pour chaque nom de domaine possible puis stocker le résultat ou b) obtenir des transferts de zone à partir des serveurs DNS qui vous intéressent, il n'y a aucun moyen de le faire avec DNS.

Eh bien, si vous exécutez des vhosts basés sur le nom Apache, vous disposez déjà d'une liste de domaines qui atteindront votre serveur. Mis à part le vhost par défaut, un vhost basé sur un nom ne répondra que pour son nom. Donc, si je pointe foobar.com vers ma boîte et que je n'ai pas d'hôte foobar.com, il sera soit servi par défaut, soit ne recevra pas de réponse (si vous n'avez pas de serveur par défaut).

Apache possède des fonctionnalités de journalisation très puissantes. La définition d'un format de journal personnalisé avec les lignes de demande que vous souhaitez ne devrait pas poser de problème. De plus, il y a toujours le champ référent.

Le courrier, en revanche, est un peu plus pénible. La meilleure chose à laquelle je peux penser est de choisir ce que vous pouvez dans les journaux du serveur et, si vous avez vraiment besoin de savoir , de configurer une capture de paquets pour SMTP.


avec les vhosts apache, je ne connais que les chemins que je distribue à des domaines spécifiques ... pas tous les domaines configurés: si vous pointez mynewdomain.tld vers mon serveur, car il n'y a pas d'entrée vhost, apache renverra simplement le webroot par défaut
warren

1
cependant, la collecte des journaux pouvait fonctionner - n'avait pas pensé à cela comme un moyen de le faire sur le serveur lui-même.
warren

LogFormat %{Host}i hostnamelog, puis CustomLog /path/to/log hostnamelogdans votre VHost par défaut, en vous assurant qu'il est distinct de n'importe lequel de vos "vrais" VHosts. Puis de temps en temps sort /path/to/log | uniq -c | sort -npour un aperçu de ce qui vous frappe.
BMDan

2

Vous devriez vérifier RobTex Pas la meilleure conception de sites Web, mais très utile! Vous pouvez découvrir tous les DNS associés à une IP.

Bien sûr, comme l'a expliqué Alnitak,

Il n'est pas possible de le faire avec le protocole DNS lui-même

Cela signifie que ce site Web n'est qu'une énorme base de données de la plupart des serveurs DNS / IP. C'est assez efficace mais pas à 100% exhaustif.


Le lien semble rompu ou a un très mauvais SSL
Adam Nofsinger
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.