Bonjour, Dsl pour le gros lag, merci pour cette réponse et celle de Guillaume.
Le 17/03/17 à 14:05, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit : SB> On Fri, Mar 17, 2017 at 01:42:55PM +0100, SB> Daniel Caillibaud <m...@lairdutemps.org> wrote SB> a message of 56 lines which said: SB> SB> > J'ai des services qui utilisent le reverse pour autoriser ou pas SB> > l'usage de token permettant de shunter une authentification, SB> SB> Juste un mot au passage : cette vérification ne vaut pas grand'chose SB> (surtout sans DNSSEC). Est-ce qu'au moins vous vérifiez l'aller-retour SB> (juste un aller-simple, la requête PTR, ça ne vaut rien) ? Non, mais c'est juste un premier filtre pour éviter d'étudier la requête, ensuite il y a la vérification du token (et si l'intrus a mis la main sur le token c'est qu'il n'a même plus besoin de spoofer l'ip ou son reverse). SB> > Je me demandais s'il y avait un inconvénient majeur à y ajouter les ptr de mes ip SB> > publiques avec du SB> > SB> > local-data-ptr: "a.b.c.d host1.domaine.tld" SB> > local-data-ptr: "e.f.g.h host2.domaine.tld" SB> ... SB> > Voyez-vous un inconvénient majeur qui m'échappe à utiliser cette solution ? SB> SB> Non MAIS attention à bien documenter ça pour que, dans deux ans, quand SB> vous changerez les adresses publiques, votre successeur ne passe pas SB> des heures à s'arracher les cheveux parce qu'il aura oublié ce hack. Si c'est une nouvelle ip pas de pb car unbound ne connaîtra pas le ptr et va faire suivre la résolution vers le bon serveur autoritaire. Le pb se poserait si on changeait le nom du host pour la même ip publique (peu probable), mais dans ce cas ça se passe dans la conf dns et y'a bien la remarque sur ce reverse "en dur" à la ligne du dessus. -- Daniel La page blanche, c'est la minute de silence de l'écrivain. Philippe Geluck, Le chat --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
