Salut la liste, >> Michel Py a écrit: >> un géoloc potable ce n'est pas compliqué à interroger, ou ça l'est ?
> Patrick Maigron a écrit: > Le problème est l'aspect "potable" justement. Ces softs ont des > taux d'erreur non négligeables, entre ceux qui travaillent par /24 > et ceux qui se basent sur les réponses des internautes... Si un > registrar français met deux serveurs de sa plage d'adresses dans > un data center US pour répondre aux critères, est-ce que les > logiciels de géoloc les verront au bon endroit ? Depuis des lustres, il existe un moyen de préciser la position d'un domaine, subnet ou host: RFC 1876 (ftp://ftp.rfc-editor.org/in-notes/rfc1876.txt). C'est resté au stade expérimental, possiblement à cause d'un petit coté usine à gaz sur les bords. Ca n'a pas l'air d'être répandu. Je propose un nouveau système basé sur rDNS: Créer un RR de type TXT qui contient l'info. 1 IN PTR cisco.arneill-py.sacramento.ca.us 1 IN TXT blah: blah 1 IN TXT geoloc: <lat> 38.559219 </lat> <long> -121.481927 </long> <city> Sacramento </city> <country> USA </country>" 2 IN PTR server.arneill-py.sacramento.ca.us Ca marche dans les faits (testé avec Windows Server 2003 DNS): de la même manière qu'on demande le reverse lookup classique: > nslookup > > set type=ptr > 1.222.168.192.in-addr.arpa > > 1.222.168.192.in-addr.arpa name = cisco.arneill-py.sacramento.ca.us On peut demander le RR TXT > set type=txt > 1.222.168.192.in-addr.arpa > > 1.222.168.192.in-addr.arpa text = "blah: blah" > 1.222.168.192.in-addr.arpa text = "geoloc: <lat> 38.559219 </lat> <long> > -121.481927 > </long> <city> Sacramento </city> <country> USA </country>" Aucune modification du système de DNS actuel. En ce qui concerne le logiciel de géoloc, il suffit qu'il extrait tous les RR de type TXT, ne retienne que celui qui commence par "geoloc:" (pour autoriser d'autres types d'utilisation), et analyse la chaine de caractères renvoyée. Commentaires ? Michel. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
