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... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
