Re: IP reversing
Mario victor-oscar a écrit :
> Salut la liste,
>
> En lisant votre poste, je me suis posé la question concernant les
> interrogations sur les recherche inversées ARPA, pourquoi ne pourrait
> ils pas réaliser une recherche des PTRs pour une IP.
>
parce que tous les domaines n'y sont pas.
prenons un premier exemple: n'importe qui peut avoir un compte gratuit
chez free, avec un site toto.free.fr. Imaginons que free mette alors
tous ces noms dans les PTRs de ses serveurs web.
prenons un autre: j'achète un domaine et je veux l'utiliser pour un
serveur web, disons www.joe.example. je ne vois aucune raison de
m'emmerder à aller embêter les gestionnaires du reverse pour y mettre ce
nom? et si j'ajoute une IP, faut que je recommence? et si j'en enlève
une, encore, ... etc. et tout ça pourquoi?
> En parallele, j'aimerais bien avoir des éclaircissements concernant la
> manière dont ces PTRs sont créés une fois la demande d'enregistrement du
> nom de domaine réalisée.
> qui le réalise, est-ce automatique, défini dans un protocole ?
>
En général, c'est l'ISP, l'hebergeur, ... qui le fait pour les blocs
qu'il gère. Parfois, on peut avoir une délégation pour gérer son
reverse. chez certains (free.fr, ovh, ...), on peut choisir son reverse
via une interface d'admin, chez d'autres, on peut le demander. (en
général, il faut d'abord que le "forward" soit configuré et propagé).
> Si on a plusieurs noms de domaines pour une IP, pourquoi le PTR n'aurait
> pas plusieurs réponses ? même si une seule serait exploitée. Si c'est le
> cas, rien n'empecherait d'utilisé un client qui récupérait
> alternativement ou en une fois les PTRs associés à l'adresse IP.
>
> qu'en pensez vous ?
>
ça ne sert à rien de mettre plusieurs PTRs. Le PTR "identifie" l'IP, et
non l'organisation ou le service (qui eux sont "identifiés" par des noms).
Il ne faut pas confondre avec les pratiques suivantes:
- mettre une même IP comme A de plusieurs noms différents, qui sert pour
le multi-homing.
- mettre plusieurs IPs comme A pour un seul nom, qui sert pour la
redondance.
pour les IPs, aucun client ne vas résoudre le PTR pour se connecter à un
nom, car si on a l'IP, on s'y connecte!
le PTR est généralement utilisé lorsque la machine agit en client et se
connecte à un serveur qui veut vérifier son nom. Mais dans ce cas, voici
ce qui "peut se passer":
Dans certains protocoles, principalement pour SMTP, quand un serveur
reçoit une connexion, il fait l'opération suivante:
1- résoudre l'IP.ça donne un PTR. en général, on garde le premier PTR
retourné.
2- on résoud ce PTR, et ça donne plusieurs IPs
3- on compare ces IPs à l'IP originale.
Il "faut" qu'une de ces IPs soit égale à l'IP originale. Si oui, on
utilise ce PTR comme "hostname" et on dir qu'il est "confirmé" (on
entend parfois FcrDNS, "forward confirmed reverse dns", mais c'est un
très gros mot, n'est-ce pas?). Sinon, on ne fait pas confiance au nom
(postfix dira que c'est "unknown").
La raison de cette double résolution est qu'une entité qui gère le
reverse pourrait décider de dire que ses IPs sont joe.microsoft.com,
titi.google.com, ... etc. en faisant une double résolution, on évite un
peu ce problème (en admettant qu'on peut faire confiance au DNS, mais
c'est un autre sujet).
Imaginons donc ce qui se passerait si à l'étape 1 je garde tous les
PTRs. j'ai une IP qui donne: joe.domain1.example, ji.domain2.example,
... tata.domain23.example. à l'étape 2, je vais donc me taper 23
requêtes? du coup, la solution retenue est de ne garder que le premier
résultat. Mais dans le cas d'un Round Robin, le premier est aléatoire.
du coup, pour que le nom soit "vérifié" à coup sûr, il faut qu'il le
soit pour tous les PTRs, ce qui fait 23 occasions de se planter au lieu
d'une! Et tout ça pourquoi? rien.
Ue principe général: plus il y a des données, plus il y a des chances de
faire des erreurs, et plus c'est dur de maintenir la cohérence.
Mais tout ça, c'est pour IPv4. si on voulait faire ça pour IPv6, on va
rigoler encore plus (et seulement le weekend. en semaine, on risque de
pleurer ;-p). du coup, plusieurs voix se sont élevés contre le reverse...
Reply to: