[FRnOG] [TECH] VRRP et Quagga
Bonjour FRNOG, J’essaye de comprendre et mettre en place une maquette de deux routeurs Quagga avec VRRP. Le Routeur1 (Master) est connecté à ISPA, le Routeur2 (Slave) est connecté à ISPB ; donc une session BGP par routeur. Câblage réseau des routeurs : ETH0 connecté sur ISPX ETH1 connecté entre les deux Routeurs (pour VRRP) ETH2 Interface (Active/Passive) Failover pour la Gateway connecté sur un switch (R1 :ETH2—SW—ETH2 :R2) Mon idée est que je voudrais que si Routeur1 tombe en panne, que le trafic repasse automatiquement par Routeur2. J’ai donc une IP Failover coté réseau interne (Gateway) qui passe d’un routeur à un autre. Le problème : C’est que je ne sais pas trop comment penser/organiser ma configuration BGP !!??!! -:( Faut’il activer un iBGP entre Routeur1 et Routeur2 ?? Sur le Routeur2 (Slave) je pensai laisser la session BGP active sur ISPB, est-ce que cela va poser un problème ?? Merci à vous pour les informations que vous me donnerez. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Sécurité du routage : RFC 6518: Keying and Authentication for Routing Protocols Design Guidelines
Le Thu, 2 Feb 2012 08:37:18 +0100, Stephane Bortzmeyer bortzme...@nic.fr a écrit : http://www.bortzmeyer.org/6518.html Auteur(s) du RFC: G. Lebovitz, M. Bhatia (Alcatel-Lucent) Dans l'ensemble du travail engagé pour améliorer la sécurité du routage sur l'Internet, un sous-problème important est celui de la gestion des clés. En cryptographie, c'est souvent par une faiblesse dans cette gestion que les systèmes de sécurité sont compromis. Le groupe de travail KARP http://tools.ietf.org/wg/karp de l'IETF est occupé à améliorer les protocoles de gestion de clés et son premier RFC, ce RFC 6518, expose les propriétés attendues des futurs protocoles de gestion des clés des routeurs. Prenons par exemple N routeurs OSPF qui veulent s'authentifier les uns les autres. La technique du RFC 2328 est d'avoir un secret partagé par tous les routeurs du même réseau local. Les messages OSPF sont concaténés avec ce secret, le résultat de la concaténation est ensuite condensé cryptographiquement, ce qui permettra au destinataire de s'assurer que l'émetteur connaissait bien le secret. Ce secret partagé est une clé cryptographique. Qui va la générer ? Comment la distribuer de façon sûre ? Comment la changer facilement et rapidement si le secret est compromis (ou, tout simplement, si un employé quitte l'entreprise) ? Ce genre de questions est la problématique de *gestion de clés*. Dans le cas d'OSPF, actuellement, la quasi-totalité des opérateurs de routeurs fait cela à la main (on se logue sur chaque routeur et on change le secret...) ou, à la rigueur, via un protocole général de configuration des routeurs. Peut-on faire mieux ? C'est en tout cas ce que va essayer de faire le groupe KARP. C'est que les mécanismes actuels ne sont pas satisfaisants. Comme le rappelle la section 1 du RFC, lors d'un colloque en 2006 (cf. RFC 4948), les participants avaient dénoncé la vulnérabilité des routeurs aux tentatives de prise de contrôle et appelé à durcir leur sécurité. Quatre axes d'amélioration avaient été identifiés, améliorer la gestion des routeurs (groupe de travail OPSEC http://tools.ietf.org/wg/opsec), améliorer les IRR, valider les annonces de route (groupe de travail SIDR http://tools.ietf.org/wg/sidr), et enfin sécuriser les communications entre routeurs (groupe de travail KARP http://tools.ietf.org/wg/karp), ce qui fait l'objet de ce RFC. Les informations de routage sont échangées via un protocole et la protection de ce protocole se fait par la cryptographie. Qui dit cryptographie dit clés. Lorsqu'un routeur cherche une clé pour protéger un message, où demande-t-il ? Pour l'instant, il n'y a pas de mécanisme standard et KARP va essayer d'en développer un. Le plus courant aujourd'hui est la gestion manuelle des clés (l'opérateur configure les clés, les change à la main - lorsqu'il y pense, les communique via PGP, SCP voire sans aucune sécurité) mais le RFC estime que le futur est dans des mécanismes automatisés de gestion de clés, les *KMP* (pour Key Management Protocol). Un KMP, par exemple, change automatiquement les clés au bout d'une période pré-définie. Compte-tenu de la variété des protocoles de routage, et du transport qu'ils utilisent, ce sera un mécanisme abstrait, pas un protocole précis (ce RFC 6518 n'a donc pas d'implémentation, il définit juste un cadre). Plus précisement, KARP va concevoir les interfaces abstraites entre le système de gestion de clés et le protocole de routage, puis, pour chaque protocole de routage, la correspondance entre cette interface abstraite et le protocole réel. Un projet ambitieux. Maintenant, au boulot. Qu'est-ce qui est déjà fait dans ce RFC ? La section 2 classe les protocoles de routage selon leurs propriétés. L'idée est que les protocoles de routage qui partagent les mêmes propriétés pourront, avec un peu de chance, utiliser les mêmes mécanismes de gestion de clés. Première propriété, le type de message. Certains protocoles sont de type un-vers-un : les messages d'un routeur sont envoyés à un autre routeur. Les UPDATE BGP (RFC 4271) fonctionnent ainsi. Mais c'est aussi le cas de LDP (RFC 5036), de BFD (RFC 5880) et même d'OSPF (RFC 2328 dans certaines conditions (liens point -à-point). D'autres protocoles fonctionnent en un-vers-plusieurs. Un routeur diffuse sur le réseau local l'information de routage. C'est le mode de fonctionnement le plus courant d'OSPF et c'est aussi celui de RIP (RFC 2453). Enfin, il y a les protocoles utilisés pour le multicast. Deuxième propriété pour classer les protocoles de routage, proche de la précédente mais pas identique, le fait que la clé soit par groupe ou par pair. Dans BGP ou LDP, les clés sont individuelles, on a une clé différente par pair. Dans OSPF, la clé est la même pour tous les pairs d'un groupe. La section 3 liste ensuite les points auxquels il faut penser
[FRnOG] [TECH]: Sujet different: VGT+ ORANGE
Hello, Une question un peu différente, mais entre opérateurs, si qq a la réponse ça m aiderait bcp... . Es ce que qq utilise un system pour être connecté au portail de commande Orange pour passer des commandes en VGA ou VGT+ . Merci d'avance. Bonne réception David Marciano [cid:image001.jpg@01CCE1D2.5B4C2380] 14, rue Crespin du Gast - 75011 Paris - France Tel : +33 (0)1 48 24 07 07 - Fax : +33 (0)1 48 24 07 08 Mail : dmarci...@adenis.frmailto:dmarci...@adenis.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] UN projet fou comme moi LOL : interconnexion des dsp quart grand est
Bonsoir, Je viens vous faire part du projet dont je suis le concepteur et qui je pense peut au moins faire se poser les bonnes questions aux décideurs même en cas de non reussite. Je suis pas un dieu de la technique, mais je pense pouvoir me dire expert des modèles de DSP (reseau d'initiatives publiques) et avoir mis en place depuis 5 ans un concept pouvant apporter l'élément manquant à celles-ci pour fonctionner correctement. Sachez que je suis conscient des puissances monopoles et politiques lisant cette liste et que ce mail est fait pour leur lancer un défit. Fou ? On me l'a dit souvent, aujourd'hui moins. Le Projet pilote s'appelle Francomtix (gix en franche-comté) demarrant en phase de test/pilote sur la dsp connectic39 du département du jura. Certains me connaissent et me détestes car j'ai un caractère et un franc parlé plaisant pas à un certain monde et c'est cette différence + le fait que mon moteur soit pas lié a l'aspect financier, fait de moi le garant du principe fondamental de ce concept. IL est vrai que certain on du remarquer qu'aujourd'hui, si tu as un projet et pas de fric ni de soutien politique, bien tu as du mal à lancer un business dans le réseau ou l'hébergement. De plus si tu innove plus que tes concurrents, tu déranges, donc on te fait taire. Du moins on essaye. Ca marche pas tout le temps. Le projet pilote (francomtix) est sous le modèle associatif et devrait fonctionner en total auto financement, c'est-à-dire : Pour que ca marche, il faut etre innovant, et pour pouvoir innover et être non sensible aux pressions diverses et n'avoir aucun accord politique, car ceux-ci peuvent nous faire subir des pressions. Donc bilan. Plus maitre du projet et ca part en couille avec l'argent publique. En bref, il faut rester maitre de son destin et du contrôle du concept ceci au total bénéfice de l'innovation et du développement de la concurrence. Franchement, je pense faire au moins trembler quelques uns, et déjà aujourd'hui, je peux le constater vu les saloperie qu'on me fait, et vu que mon projet et photocopier (oui oui carrément, ils se font pas chiers) par les 3 collectivités de région + ma region (Belfort, Besançon, la région) et orange lab. Pour vous dire : Dernièrement j'avais décrocher la place de chef de projet sur le déploiement d'un datacenter sur Besancon. La region a fait pression aupres des investisseurs en les menaçant de retirer leurs billes si il me gardait dans le projet. J'ai été viré. SI je les genais pas, il s'occuperai pas de moi je pense. Sachez que seul, j'ai tout de meme reunis 24 conseillés tic sur les regions de bourgone, franche-comté et alsace et que vu que ma region et ces collectivité me voulais pas dans celui ci, bien que j'ai été en bourgogne le continuer. Bilan la Presidente de region a imposé aux conseillés TIC des dites collectivités de suivre mes projets en bourgogne. Yes ... Aujourd'hui on m'avoue tout bas qu'il serait dommage que deux projets identiques se développent sur la region. Cela me fais dire qu'ils doivent me croire capable de mettre un peu le desordre ici. Sachez que si les collectivités veulent travailler avec nous, que la porte est ouverte et c'est pour cela que je parle du projet librement. Ce projet ce veut fédérateur. Voila les objectifs Faire que l'innovation gagne devant le finance et les copinage grace à une saine concurrence. D'aider les porteurs serieux a demarrer en aidant à financer les infras de demarrage D etre un portail de référence regional pour les pme afin qu'elles puissent déposer leurs demandes de services/quotations aux prestataires adherents de l'association local. Nous representerons les metiers suivant Opérateurs Fai Hebergeur Developpeur Le client aura donc diverses propositions concurrente et choisira le prestataire qui lui conviendra. Si le projet est concluant dans le jura, nous ouvrirons sur d'autres dsp et financerons les liens les reliants, ce qui fera que ces liens feront partie du package de services de l'association compris dans l'adhesion. Les petits opérateurs pourrons ainsi etre présent sur les dsp couvertes et ne subiront plus les couts insupportables a fiancer quant ils décrochent leurs premiers clients ON devrait être relier a lyonix et frix pour que les operateurs présents sur ces gix puissent profiter de ce système et travailler sur la backone associatif donc neutre. Dans le concept il y a un gix pour chaque region ou departement. Si ce projet est concluant sur une dsp, il devrait donc en toute logique se propager par contagion sur d'autres dsp/departements Des gix devrait donc naitrent un peu partout en provence Ce sera bénéfique pour tous car nous économiserons le transport jusqu'à paris puisque trafic restera regional. Des salles blanches locales ouvrirons a des tarifs parisiens, mais avec un meilleur retour sur investissement grace à une alimentation electrique plus lourde. Ce projet devrait aider à la résorption des zones blanches puisque si un petit fai trouve une
Re: Re : [FRnOG] [MISC] MegaUpload
Il y en a qui n'ont pas tout compris... ; DiG 9.7.3 +trace thepiratebay.se ;; global options: +cmd . 230692 IN NS e.root-servers.net. . 230692 IN NS j.root-servers.net. . 230692 IN NS a.root-servers.net. . 230692 IN NS h.root-servers.net. . 230692 IN NS f.root-servers.net. . 230692 IN NS l.root-servers.net. . 230692 IN NS g.root-servers.net. . 230692 IN NS m.root-servers.net. . 230692 IN NS d.root-servers.net. . 230692 IN NS c.root-servers.net. . 230692 IN NS k.root-servers.net. . 230692 IN NS i.root-servers.net. . 230692 IN NS b.root-servers.net. ;; Received 492 bytes from 132.207.144.3#53(132.207.144.3) in 12 ms se. 172800 IN NS a.ns.se. se. 172800 IN NS b.ns.se. se. 172800 IN NS c.ns.se. se. 172800 IN NS d.ns.se. se. 172800 IN NS e.ns.se. se. 172800 IN NS f.ns.se. se. 172800 IN NS g.ns.se. se. 172800 IN NS h.ns.se. se. 172800 IN NS i.ns.se. se. 172800 IN NS j.ns.se. ;; Received 468 bytes from 198.41.0.4#53(a.root-servers.net) in 256 ms thepiratebay.se.86400 IN NS ns0.thepiratebay.org. thepiratebay.se.86400 IN NS ns3.thepiratebay.org. thepiratebay.se.86400 IN NS ns1.thepiratebay.org. thepiratebay.se.86400 IN NS ns2.thepiratebay.org. ;; Received 121 bytes from 199.7.49.30#53(h.ns.se) in 267 ms Le 2012-02-02 00:31, Michel Py a écrit : Guillaume Barrot a écrit: Truc marrant, mais depuis peu, thepiratebay.org (droit US) renvoie sur thepiratebay.se (droit pas US). Comme quoi, le pirate apprend vite ! Le pirate savait déjà ça depuis des lustres. Apres, si le domaine en .org existe encore, même s'il renvoie sur un .se, il doit bien y avoir un moyen pour le FBI de toujours trouver une pirouette pour intervenir, non ? Pfff qu'est-ce que ça changerait ? Pour l'hypothèse (à laquelle je ne crois pas) admettons que le FBI arrive à bloquer le domaine sous .se, que se passerait-il ? 30 secondes après sur tweeter et fessebouc tout le monde aurait le nom du nouveau domaine. Et même sans tweeter et fessebouc ça serait pareil, le téléphone ça continuerait de marcher. Autant pisser dans un violon. Quoi que, ne pas sous-estimer la connerie incommensurable du FBI non plus, mais résultat des courses toujours le même. Faut pas faire l'amalgame entre MU et TPB, ce n'est pas du tout la même chose. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : [FRnOG] [MISC] MegaUpload
Alors je ne sais pas si le FBI a capacité a interdire un nom de domaine sous juridiction européenne si son NS est en .org. De toutes facons, il y a fort a parier que ca va vite migrer en nsX.thepiratebay.se. Reste plus qu'a trouver le TLD lie au pays a la juridiction la plus sympathique. Question a mille baffes, c'est lequel ? Le 2 février 2012 23:49, Thibaud Perret perretthib...@gmail.com a écrit : Il y en a qui n'ont pas tout compris... ; DiG 9.7.3 +trace thepiratebay.se ;; global options: +cmd . 230692 IN NS e.root-servers.net. . 230692 IN NS j.root-servers.net. . 230692 IN NS a.root-servers.net. . 230692 IN NS h.root-servers.net. . 230692 IN NS f.root-servers.net. . 230692 IN NS l.root-servers.net. . 230692 IN NS g.root-servers.net. . 230692 IN NS m.root-servers.net. . 230692 IN NS d.root-servers.net. . 230692 IN NS c.root-servers.net. . 230692 IN NS k.root-servers.net. . 230692 IN NS i.root-servers.net. . 230692 IN NS b.root-servers.net. ;; Received 492 bytes from 132.207.144.3#53(132.207.144.**3) in 12 ms se. 172800 IN NS a.ns.se. se. 172800 IN NS b.ns.se. se. 172800 IN NS c.ns.se. se. 172800 IN NS d.ns.se. se. 172800 IN NS e.ns.se. se. 172800 IN NS f.ns.se. se. 172800 IN NS g.ns.se. se. 172800 IN NS h.ns.se. se. 172800 IN NS i.ns.se. se. 172800 IN NS j.ns.se. ;; Received 468 bytes from 198.41.0.4#53(a.root-servers.**nethttp://a.root-servers.net) in 256 ms thepiratebay.se.86400 IN NS ns0.thepiratebay.org. thepiratebay.se.86400 IN NS ns3.thepiratebay.org. thepiratebay.se.86400 IN NS ns1.thepiratebay.org. thepiratebay.se.86400 IN NS ns2.thepiratebay.org. ;; Received 121 bytes from 199.7.49.30#53(h.ns.se) in 267 ms Le 2012-02-02 00:31, Michel Py a écrit : Guillaume Barrot a écrit: Truc marrant, mais depuis peu, thepiratebay.org (droit US) renvoie sur thepiratebay.se (droit pas US). Comme quoi, le pirate apprend vite ! Le pirate savait déjà ça depuis des lustres. Apres, si le domaine en .org existe encore, même s'il renvoie sur un .se, il doit bien y avoir un moyen pour le FBI de toujours trouver une pirouette pour intervenir, non ? Pfff qu'est-ce que ça changerait ? Pour l'hypothèse (à laquelle je ne crois pas) admettons que le FBI arrive à bloquer le domaine sous .se, que se passerait-il ? 30 secondes après sur tweeter et fessebouc tout le monde aurait le nom du nouveau domaine. Et même sans tweeter et fessebouc ça serait pareil, le téléphone ça continuerait de marcher. Autant pisser dans un violon. Quoi que, ne pas sous-estimer la connerie incommensurable du FBI non plus, mais résultat des courses toujours le même. Faut pas faire l'amalgame entre MU et TPB, ce n'est pas du tout la même chose. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] MegaUpload - whois
Bonjour, Le 25/01/2012 23:51, Patrick Maigron a écrit : C'était possible pour les français vivant à l'étranger depuis mars 2010 http://w6.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-operationnelles/3739/showOperational/francais-residents-a-l-etranger-sur-le-banc-de-production.html Mais effectivement la nouvelle charte ne le dit plus : Peuvent demander l'enregistrement ou le renouvellement d'un nom de domaine, dans chacun des domaines de premier niveau, toutes personnes physiques résidant et toutes personnes morales ayant leur siège ou établissement principal : sur le territoire de l’un des états membres de l’union européenne ; sur le territoire des pays suivants : Islande, Liechtenstein, Norvège, Suisse. Stéphane, un éclaircissement ? Si c'est le cas, je suppose qu'il y a des raisons juridiques derrière ? Tout cela est du au changement d'identification des .fr, avant il y avait 5 cas possibles valides pour l'afnic : - particulier (validation via commune, code postal et date de naissance, Paris, 75001, 01-01-1970) - association (validation via n° de page au jo et date de parution, 1, 01-01-1970) - association (validation par numéro de siren, 123456789) - societe (validation par numéro de siren, 123456789) - societe (validation par identifiant de marque de l'IFPI, j'en ai jamais vu aucun de valide donc je sais pas a quoi ça ressemble) Donc ces charmants gus de l'afnic faisaient (ou ne faisaient pas) tourner une moulinette qui shootait tous les ndd qui n'avaient pas un statut valide pendant la période de validité. Il eu été trop simple de forcer la régularisation au renouvellement... rien ne vaut un bon client, qui n'y connait rien, avec le je comprends pas je reçois plus mes e-mails. Bref, depuis le changement de législation au niveau de l'eu (j'ai jamais vraiment cherché d'où ça vient), l'afnic a été obligé d'ouvrir aux résidents de l'eu ses tld nationaux (comme les autres tlds nationaux sont obligés de le faire). Du coup les règles d'identification se sont relaxées et l'afnic ne peux font size=42bENFIN PLUS/b/font faire de contrôle sur des fichiers de codes postaux consolidés ou de l'insee qu'elle ne publie pas ! Donc oui c'est un peu dommage pour nos chers résidents non-français qui ne peuvent plus réserver de domaines. Bon par contre dans la pratique, comme il n'y a pas vraiment de fichier permettant les vérifications au niveau européen facilement d'après ce que j'avais compris... Il suffit d'enregistrer ton nom de domaine avec une adresse bidon : - Palais de l'Elysée 55, rue du faubourg Saint-Honoré 75008 Paris - Maison des Français de l'étranger, 48 rue de Javel, 75015 Paris - 2 rue Stephensoen, immeuble international, Montigny le Bretonneux, 78181 Saint Quentin en Yvelines CEDEX Vu l'autorisation de dépôt pour les résidents européens, il te faudrait aussi un numéro de téléphone avec un indicatif européen reconnu, si ils ont adapté aux indicatifs européens la vérification de numéro de téléphone qu'ils faisaient avant. La seule chose qui est importante lors du dépôt de domaine c'est : - nom du déposant (récupération du domaine avec un recommandé/référé au registrar/afnic en cas de problème) - courriel (pour être prévenu en cas de renouvellement) Cordialement --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] MegaUpload - whois
Bonjour Raphaël, Je crois qu'il y a un malentendu. Je ne demandais pas comment tricher pour enregistrer un nom de domaine en .fr, pour en enregistrer un, je peux toujours demander à des amis ou de la famille d'en être propriétaire ou même de me déclarer en tant qu'auto-entrepreneur, qui n'est pas assujetti à lieu de résidence, et avoir ainsi un SIRET. C'était surtout une remarque sur ce que je considérais comme une injustice et mon propos voulait tenter de faire changer les règles d'attribution en tant que grand naïf et démocrate que je suis. Apparemment c'est du ressort de l'UE donc ça n'est plus du ressort des Français pour leurs propres extensions, et je voulais donc en être sûr. Les Français de l'étranger ou de Saint-Martin et Saint-Barth se rabattront sur des extensions génériques à défaut et je trouvais ça dommage en plus de considérer une fois de plus ces Français comme des Français de seconde catégorie. Donc, oui, il est possible de tricher en faisant une fausse déclaration mais c'est contraire à la charte que tu acceptes (et Sétphane ne serait pas content, déjà que tu l'as qualifié de gus^^). Potentiellement, il est possible de trouver un moyen d'enregistrer légalement un nom de domaine en .FR/.RE/.TF/.YT/.PM en contournant comme je le mentionnais mais si on pouvait éviter ça serait mieux et c'était le but de mon propos qui est plus juridique et politique que technique. Le 2012-02-03 00:08, Raphaël Gertz a écrit : Bonjour, Le 25/01/2012 23:51, Patrick Maigron a écrit : C'était possible pour les français vivant à l'étranger depuis mars 2010 http://w6.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-operationnelles/3739/showOperational/francais-residents-a-l-etranger-sur-le-banc-de-production.html Mais effectivement la nouvelle charte ne le dit plus : Peuvent demander l'enregistrement ou le renouvellement d'un nom de domaine, dans chacun des domaines de premier niveau, toutes personnes physiques résidant et toutes personnes morales ayant leur siège ou établissement principal : sur le territoire de l’un des états membres de l’union européenne ; sur le territoire des pays suivants : Islande, Liechtenstein, Norvège, Suisse. Stéphane, un éclaircissement ? Si c'est le cas, je suppose qu'il y a des raisons juridiques derrière ? Tout cela est du au changement d'identification des .fr, avant il y avait 5 cas possibles valides pour l'afnic : - particulier (validation via commune, code postal et date de naissance, Paris, 75001, 01-01-1970) - association (validation via n° de page au jo et date de parution, 1, 01-01-1970) - association (validation par numéro de siren, 123456789) - societe (validation par numéro de siren, 123456789) - societe (validation par identifiant de marque de l'IFPI, j'en ai jamais vu aucun de valide donc je sais pas a quoi ça ressemble) Donc ces charmants gus de l'afnic faisaient (ou ne faisaient pas) tourner une moulinette qui shootait tous les ndd qui n'avaient pas un statut valide pendant la période de validité. Il eu été trop simple de forcer la régularisation au renouvellement... rien ne vaut un bon client, qui n'y connait rien, avec le je comprends pas je reçois plus mes e-mails. Bref, depuis le changement de législation au niveau de l'eu (j'ai jamais vraiment cherché d'où ça vient), l'afnic a été obligé d'ouvrir aux résidents de l'eu ses tld nationaux (comme les autres tlds nationaux sont obligés de le faire). Du coup les règles d'identification se sont relaxées et l'afnic ne peux font size=42bENFIN PLUS/b/font faire de contrôle sur des fichiers de codes postaux consolidés ou de l'insee qu'elle ne publie pas ! Donc oui c'est un peu dommage pour nos chers résidents non-français qui ne peuvent plus réserver de domaines. Bon par contre dans la pratique, comme il n'y a pas vraiment de fichier permettant les vérifications au niveau européen facilement d'après ce que j'avais compris... Il suffit d'enregistrer ton nom de domaine avec une adresse bidon : - Palais de l'Elysée 55, rue du faubourg Saint-Honoré 75008 Paris - Maison des Français de l'étranger, 48 rue de Javel, 75015 Paris - 2 rue Stephensoen, immeuble international, Montigny le Bretonneux, 78181 Saint Quentin en Yvelines CEDEX Vu l'autorisation de dépôt pour les résidents européens, il te faudrait aussi un numéro de téléphone avec un indicatif européen reconnu, si ils ont adapté aux indicatifs européens la vérification de numéro de téléphone qu'ils faisaient avant. La seule chose qui est importante lors du dépôt de domaine c'est : - nom du déposant (récupération du domaine avec un recommandé/référé au registrar/afnic en cas de problème) - courriel (pour être prévenu en cas de renouvellement) Cordialement --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] MegaUpload - whois
Bonjour, Le 03/02/2012 06:36, Thibaud Perret a écrit : Je crois qu'il y a un malentendu. Je ne demandais pas comment tricher pour enregistrer un nom de domaine en .fr, pour en enregistrer un, je peux toujours demander à des amis ou de la famille d'en être propriétaire ou même de me déclarer en tant qu'auto-entrepreneur, qui n'est pas assujetti à lieu de résidence, et avoir ainsi un SIRET. Saut que théoriquement il faudrait que tu sois en France pour être auto-entrepreneur non ? Enfin ça change pas le problème, même les sociétés doivent être basée en union européenne pour pouvoir déposer des tld européens. C'était surtout une remarque sur ce que je considérais comme une injustice et mon propos voulait tenter de faire changer les règles d'attribution en tant que grand naïf et démocrate que je suis. Oh tu sais les .fr (et autres tlds français) ça a jamais été vraiment démocratique :p On a pas pu en déposer en tant que particulier jusqu'à relativement récemment, lui sont appliquées toutes les fantaisies de nos parlementaires, pertes de l'ancienneté lors du changement de registrar, etc... Apparemment c'est du ressort de l'UE donc ça n'est plus du ressort des Français pour leurs propres extensions, et je voulais donc en être sûr. Les Français de l'étranger ou de Saint-Martin et Saint-Barth se rabattront sur des extensions génériques à défaut et je trouvais ça dommage en plus de considérer une fois de plus ces Français comme des Français de seconde catégorie. J'ai un gros doute sur le fait que nos députés qui fixent les règles pensent en tant qu'ingénieur pragmatique qui veut traiter tous les cas, les dernières lois me laissent plus penser qu'il réfléchissent en internet civilisé et dernière lubie de leur chef de parti... Donc, oui, il est possible de tricher en faisant une fausse déclaration mais c'est contraire à la charte que tu acceptes (et Sétphane ne serait pas content, déjà que tu l'as qualifié de gus^^). Oh je pense que le terme gus est mérité pour tous les domaines que j'ai du corriger à-la-main parce que leur système partait en sucette ^^ Bon, je dois leur accorder qu'il doivent faire contre mauvaise fortune bon coeur et se plier a toutes les lignes idiotes des décrets auxquels ils sont assujettis, ce qui n'est pas toujours évident... Potentiellement, il est possible de trouver un moyen d'enregistrer légalement un nom de domaine en .FR/.RE/.TF/.YT/.PM en contournant comme je le mentionnais mais si on pouvait éviter ça serait mieux et c'était le but de mon propos qui est plus juridique et politique que technique. Tu sais l'histoire des contournements des règles afnic elle a commencé quand ovh (de mémoire) a vendu des domaines a des particuliers en les déposant au nom de sa société ^^ A noter que les principaux problèmes avec les histoires d'identification c'était surtout des cas comme un client né dans le département 75 juste avant la création des 91/92/93/94/95 dont l'afnic voulait pas par exemple. C'est le mal certes, mais a système trop mou, clients filou. Cordialement --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] MegaUpload - whois
Depuis que je lis ce fil, ça me démange de dépenser (gaspiller?) 20 galaticrédits pour enregistrer un domaine sous .fr avec l'info suivante: Arsène Lupin 1, Place du Canard déchaîné 12345 Trifouilly-les-Oies France Je n'ai pas décidé de le faire (j'ai suffisamment d'ennemis pour ne pas allonger la liste) mais d'un autre coté je n'ai pas non plus décidé de ne pas le faire. D'ailleurs, s'il y a un des lecteurs qui n'a pas peur des conséquences politiques, qui opère un bureau d'enregistrement pour .fr, et qui veut mes éventuels $20, merci de me contacter en privé. Aucune promesse. J'ai 3 questions con mais néanmoins sérieuses: 1. Est-ce que ça va marcher avec une adresse bidon comme ci-dessus? D'un bureau d'enregistrement Français je m'attends vaguement à une validation du code postal, mais quid d'un registrar étranger? Si c'était pas que ça me fasse chier de donner $20 à godaddy, j'aurais essayé. 2. En admettant que ça marche avec une adresse bidon, et en admettant que toutes les parties concernées aient l'honnêteté intellectuelle d'oublier qu'ils ont lu ce billet et n'aillent pas faire de whois sur Arsène Lupin ou Trifouilly-les-Oies, quel est l'historique d'annuler des noms de domaines visiblement invalides? Des stats? 3. Bon l'adresse bidon j'admets que c'est de la provoc, mais question similaire à ci-dessus: si moi, citoyen Américain, ne résidant pas en France, enregistre un domaine sous .fr avec une adresse pas bidon, à moins que ça arrive aux oreilles de Stephane, est-ce que quelqu'un va faire quelque chose? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] MegaUpload - whois
Raphaël Gertz Il suffit d'enregistrer ton nom de domaine avec une adresse bidon : Palais de l'Elysée 55, rue du faubourg Saint-Honoré 75008 Paris Lire ma contrib précédente, mais cette adresse ce n'est pas ce que j'appelle une adresse bidon. Voici une adresse bidon: Arsène Lupin 1, Place du Canard déchaîné 12345 Trifouilly-les-Oies France Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : [FRnOG] [MISC] MegaUpload
On 01.02.2012 22:54, Guillaume Barrot wrote: Truc marrant, mais depuis peu, thepiratebay.org (droit US) renvoie sur thepiratebay.se (droit pas US). Comme quoi, le pirate apprend vite ! marrant, ici ca renvoie sur http://baiedespirates.be (j'suis a bxl la) --- Liste de diffusion du FRnOG http://www.frnog.org/
