Re: Re: [FRnOG] [TECH] DNS Serveur

2013-01-21 Par sujet Cyril HLAKKACHE
Solarus wrote  Je ne sais pas pourquoi tu veux ouvrir un DNS public mais c'est 
déconseillé. Un DNS doit être limité à quelques plages IP ou un AS, mais un DNS 
public n'est pas recommandé.

Quelles BCP conseillent explicitement ça ? si c'est un primaire ou secondaire, 
je ne pense pas que le filtrage proposé fonctionne. Si c'est un cache alors, 
oui ... peut-être ... mais bon c'est un peu dommage tout de même. Peut-être 
aussi qu'il y a confusion entre notion de public et service de cache DNS.
 
eduperron wrote quiz de la redondance?
Solarus wrote Tu redondes le premier avec le deuxième, ou inversement.

ça dépend aussi de quoi on parle. Pour un cache, le mieux est d'informer tes 
futurs clients des 2 ou 3 IP de ces serveurs et de les positionner sur des 
réseaux différents de préférence et dans la mesure du possible. S'il s'agit de 
DNS primaire alors le mieux est d'avoir 2 secondaires, l'un chez soit, l'autre 
chez un partenaire comme un FAI par exemple. Pour la gestion de zone reverse, 
le mieux est d'avoir un RIR en NS secondaire comme par exemple le RIPE avec 
ns.ripe.net. 

eduperron wrote Quelles sont les limites d'une solution open source comme Bind?
Solaris wrote Aucune.

;) tu fais plaisir à Paul Vixie là ! :) disons qu'il faut au moins viser la 
dernière ré-écriture en V9. La version 9.9.2-P1 publiée donne un petit listing 
des updates : 
https://lists.isc.org/pipermail/bind-announce/2012-December/000823.html arrive 
la V10, mais mieux vaut laisser les autres tester avant ;)
  
duperron wrote  Quiz de l'ipv6?

Cette page est intéressante aussi à parcourir : 
http://livre.g6.asso.fr/index.php/Recommandations_op%C3%A9rationnelles_pour_l%27int%C3%A9gration_d%27IPv6
   

@+°

Cyril H.
---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Les RFCs sur le protocole réseau ILNP sont sortis

2012-11-10 Par sujet Cyril HLAKKACHE
merci pour ce coup de projecteur. 

Vrai qu'il s'agit là d'un sérieux espoir pour simplifier le contexte actuel 
(multihoming, VM entre datacenters, transition V4/V6, mobilité ...). Ces 
initiatives, pour certaines bien avancées, sont des concepts qui ne remettent 
pas tout en cause mais révolutionnent en venant se greffer sur le socle actuel. 
Les surcouches de haut niveau pour répondre à de nouveaux besoins est une 
tendance à intensifier et s'appuyant sur la capilarité actuelle, car en 
réalité, logiciellement, il est déjà possible de tout faire, le challenge n'en 
reste pas moins la standardisation sans oublier la stabilité.

J'ai pour ma part une préférence pour LISP, car par exemple, je regrette 
l'usage de DNS dans ILNP, j'entends par là, par exemple, les notions de TTL sur 
les records sous la barre des 1000s. Même si peu d'impact sur les perf, on 
risque de ne plus réussir à passer un zonecheck de l'AFNIC si on continue comme 
ça :) Le DNS étant destiné également à évoluer et l'imbrication peut engendrer 
des effets de bords (genre DNSSEC), le mieux est encore de fonctionner par 
empilement en évitant de créer trop de dépendances. Il y a tout de même une 
fâcheuse tendance à embarquer DNS dans les constructions de solution, je pense 
par exemple à SPF, DKIM ... :)

Sinon 'est un peu dommage que ces initiatives ne soient pas encore assez 
connues parmi les experts car il s'agit là de travaux très prometteurs, à 
suivre aussi par les opérateurs et sur lesquels, eux aussi, doivent contribuer 
car le futur se dessine d'abord ensemble.




Cyril HLAKKACHE

From: Stephane Bortzmeyer
Date: 2012-11-10 10:58
To: frnog-tech
Subject: [FRnOG][TECH] Les RFCs sur le protocole réseau ILNP sont sortis
Je vous ai déjà embêté plusieurs fois avec les protocoles réseaux qui
séparent l'identificateur d'une machine de son localisateur
(contrairement à l'adresse IP actuelle, qui mélange les deux). Il
existe trois de ces protocoles qui sont normalisés ou proches de
l'être, un qui fonctionne dans les routeurs, en tunnelant le trafic
(LISP, dont les RFC sont prêts mais bloqués par deux drafts
auxiliaires pas encore publiés). Et deux qui ne fonctionnent que dans
les machines terminales (pas besoin de toucher à votre infra) et sont
considérés par leurs promoteurs comme les seuls « vrais » protocoles
de séparation ID/Loc. Ce sont HIP et le nouveau ILNP, dont les RFC
viennent de sortir.

Par contre, si vous êtes impatients de déployer, notez que ILNP est le
moins implémenté des trois. Pour l'instant, ces RFC sont surtout
utiles au programmeur, à l'étudiant, au curieux. L'opérateur réseau
devra attendre la prochaine phase pour tester ILNP.

http://www.bortzmeyer.org/6740.html



Auteur(s) du RFC: RJ Atkinson (Consultant), SN Bhatti (U. St Andrews)




Le protocole ILNP vient d'être spécifié dans une série de neuf RFC, 
dont ce RFC 6740 est le point de départ, décrivant l'architecture 
générale d'ILNP. ILNP appartient à la famille des protocoles à 
séparation de l'identificateur et du localisateur 
http://www.bortzmeyer.org/separation-identificateur-localisateur.html.
 Ces protocoles visent à résoudre une limite fondamentale de 
l'Internet : l'adresse IP est utilisée à la fois comme *identificateur* 
(nommer une machine, par exemple pendant la durée d'une session TCP) et 
comme localisateur (indiquer son point d'attachement au réseau). Cette 
confusion rend certaines configurations, notamment le multi-homing et 
la mobilité, très difficiles.

Ce n'est pas qu'ILNP soit le premier protocole à vouloir séparer ces 
deux fonctions. Avant de donner le feu vert à la publication de ces 
RFC, l'IESG a notamment examiné HIP 
http://www.bortzmeyer.org/hip-resume.html et LISP 
http://www.bortzmeyer.org/lisp-wg.html, avant de conclure qu'ILNP 
avait des caractéristiques suffisamment originales pour qu'il soit 
intéressant qu'il soit décrit dans des RFC.

ILNP avait été choisi par les présidents du groupe de recherche Routage 
de l'IRTF comme étant la base des futurs travaux sur une meilleure 
architecture pour l'Internet (travaux décrits dans le RFC 6115). S'il 
faut le résumer en cinq points :
* ILNP est défini comme une architecture abstraite, avec plusieurs 
concrétisations possibles. Celle décrite dans ces RFC est compatible 
avec l'Internet actuel (une autre, plus « table rase », serait 
possible).
* ILNP fonctionne entièrement dans les machines terminales, les 
routeurs ne sont pas changés.
* Chaque machine ILNP a au moins un Identificateur et au moins un 
Localisateur. En IPv6, ils sont indiqués dans chaque paquet (ILNP peut 
aussi tourner au dessus d'IPv4 mais c'est plus complexe.)
* Pour trouver le Localisateur d'une machine qu'on veut contacter, la 
méthode standard est d'utiliser le DNS (ILNP repose nettement plus sur 
le DNS que ses concurrents).
* Les changements de localisateur en cours de session sont faits par un 
nouveau message ICMP, Locator Update. Ces derniers

Re: [FRnOG] [MISC] Traitement de mail abuse chez un opérateur

2012-09-17 Par sujet Cyril HLAKKACHE
Hello Christophe,

L'existence de l'email abuse est définie dans la RFC2142, mais je ne connais 
pas d'autre document IETF qui détaillerait plus précisément son usage.

De ma vision, les documents les plus fiables et faisant référence sont ceux 
rédiger collégialement sur la zone communautaire MAAWG.
Ces documents sont consultable sur le link suivant : 
http://www.maawg.org/published-documents
  
un des documents renvoi d'ailleurs sur le RIPE qui a lui-même publié des 
éléments : https://www.ripe.net/ripe/policies/proposals/2011-06
  
Je pense qu'avec cela tu pourras tenter, dans cette masse de publication, 
d'identifier des éléments intéressants.

De toute manière, s'il existe des choses, cela ne reste que des 
recommandations. Le véritable enjeux est surtout d'avoir quelqu'un au bout du 
fil qui traite réellement les plaintes adressées à ab...@company.tld , tout 
comme le n...@company.tld et que cela ne tombe pas dans un process blackhole.

ce que tu cites ne semble pas réellement efficace et est bien en réalité 
étonnant, car à ce jour, la majorité des plaintes, appelées aussi FBL pour 
FeedBackLoop, sont générées automatiquement par des systèmes (fw, solution 
antispam ...) qui n'iront pas lire les accusés de réception ;) et sûrement pas 
remplir des formulaires. Cela signifie donc que cet interlocuteur drop un 
certains nombre de ces plaintes.

tiens nous au courant des éventuels échos que tu auras après ce dépôt de 
plainte.

@+°




Cyril HLAKKACHE

From: Christophe
Date: 2012-09-12 21:29
To: frnog-m...@frnog.org
Subject: [FRnOG][MISC] Traitement de mail abuse chez un opérateur
Bien le bonsoir à tous,

Suite à plusieurs attaques sur un serveur SMTP dont j'ai la charge , et 
la majorité provenant d'une même adresse IP chez un opérateur anglais 
(bloquée régulièrement par un Fail2ban, mais ca fait plusieurs jours que 
ca dure) , j'ai souhaité informer l'opérateur de ce désagrément sur 
l'adresse mail abuse correspondant au whois de l'adresse IP .

Je prend mon plus bel anglais, et c'est parti : envoi de mail, 
description du problème, et logs à la clé.
Je reçois un mail automatique dans les secondes qui suivent, qui 
m'invitent à compléter ma demande , avec un lien fourni. (Méthode un peu 
bizarre, mais admettons)

La je tombe sur un formulaire, avec un certain nombre de champs à 
remplir , genre Nom, Prénom, tout ca, mais un d'entre eux m'interpelle, 
en tant que champ obligatoire : The phone number your broadband is on 
, Peut-être est-ce lié à la question d'avant : Are you a customer ? .

Bien qu'en répondant non , à la dite question, il m'est impossible de 
valider le formulaire d'abuse.

Est-ce bien normal ?

Y'a t'il des règles qui régissent l'utilisation des mails sur 
ab...@domain.tld ?

Rien de grave en soit : coup d'iptables et l'histoire a été vite réglée, 
en revanche ma curiosité est dans tous ses états :) .

A bientôt.

Christophe.



---
Liste de diffusion du FRnOG
http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Blacklistage IP en 128.

2012-08-08 Par sujet Cyril HLAKKACHE
Je pense que le conseil de Fabien est le bon concernant le postmaster.

Par contre, première vérification est tout de même de vérifier que vous êtes 
bien conforme au standard :
= un reverse DNS qui existe et qui tient la route (cad sans terme portant à 
polémique pour héberger un smtp comme par exemple le terme *dyn* ).
= vous n'hébergez pas sur un des ranges des botnet sur lesquels hotmail vous 
aurait envoyer des plaintes sur votre ab...@company.com auquel vous n'auriez 
pas répondu car abuse mailbox non gérée
= que la déclaration au niveau de la WHOIS DB du RIPE dispose bien d'une 
mailbox ab...@tacompanie.tld
= ...
admettons que tous ces classiques soient conformes.

Ensuite, je pense que le site de troubleshooting est plutôt bien fait sur 
live.com au même titre que l'était le postmaster d'AOL, tous les codes erreurs 
plus précis sont commentés.
ici tu es en 550 SC-001 et le descriptif déclare bien que l'IP ou le range 
est en dur dans leur RBL.

La difficulté c'est que de plus en plus les gros founisseurs de service emails 
utilisent des systèmes imbriqués avec des algos complexes allant des BCP (genre 
ip lookup failed, reverse dyn ...) puis check les diffusion DNS spcifiques (tel 
que SPF), puis les RBL (local + externe), puis des base de réputation par 
score, puis des systèmes plus ingénieux comme des sortes de ralentisseurs ^^ (à 
base de 4XX ...) ... tu finis ensuite par douter de tout :)
Comme tu peux le voir un peu plus bas sur leur détail d'erreur, il exploite 
aussi dans leur système certaines listes de Spamhaus mais plutôt pour 
référencer les IP clairement identifiées grossièrement en IP dyn. Je pense donc 
que par déduction l'IP n'est pas considéré comme dynamique car l'erreur n'est 
pas linkée avec ce code. 
Il utilise aussi ReturnPath pour construire la réputation d'une IP et tu peut 
vérifier le score de l'IP précise directement en ligne sur : 
https://www.senderscore.org/ ça pourrait te donner une première indication.

Il se peut tès bien que ce range était alloué à un autre opérateur auparavant 
et qu'il est été référencé en dure dans leur RBL avant même que vous en 
héritiez. 
Il se peut très bien aussi qu'une plainte (FBL feedBackLoop) vous ait été 
envoyé avec un échantillon et que vous n'ayez pas traité à plusieurs reprises 
et qu'il utilise ça comme système de pression.

Mais de manière globale, Hotmail est investi dans la communauté et travaille en 
modèle ouvert en respectant des pratiques recommandées par les acteurs 
référents du domaine (enfin beaucoup me contrediront mais pour moi c'est pas du 
Sorbs). Cependant, il faut se douter qu'il réceptionne un certains nombres de 
réclamations il faudra ensuite user de patience ;)




Cyril HLAKKACHE
---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Blacklistage IP en 128.

2012-08-08 Par sujet Cyril HLAKKACHE
Jeremy wrote Hotmail ... postmaster m'avait répondu ... m'avais alors indiqué 
que comme la plage n'avait jamais été annoncé, elle était blacklisté par défaut.

Cela me semble effectivement une bonne piste. Mais il semble étrange qu'il n'y 
ai pas un processus d'update automatique de leurs bases car il est clair qu'en 
V4 nous allons passer dans une période de défragmentation de l'espace qui 
motivera sûrement l'usage de toutes les plages disponibles, ça serait dommage 
de devoir passer par le postmaster à chaque nouvelle allocation (bien qu'en 
terme d'allocation première main il ne doit pas rester grand chose il faut 
l'avouer ^^).

sinon pour les personnes investies dans la partie email et qui souhaitent 
réellement avancer sur les aspects anti-spam, blacklistage, sécurité email ... 
un des groupes de travail de référence reste le MAAWG http://www.maawg.org/  
pas mal de publications sur le site donnant des infos produitent collégialement 
(FAI, senders et fournisseurs de solution sécurité email). On retrouve dans ce 
workingroup tous les acteurs de référence, en particulier Dave Crocker 
(créateur de SMTP et ayant présidé à l'IETF) ainsi que John LEVINE ou encore 
Steve LINDFORD.




Cyril HLAKKACHE
---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: Re: [FRnOG] [TECH] Représentation d'Internet

2012-08-04 Par sujet Cyril HLAKKACHE
je trouve ça plutôt artistique en terme de résultat, on se rapproche assez 
d'une *nébuleuse diffuse*.
bien sur, beaucoup de têtes connues dans l'oeuvre mais l'immortalisation V6 
actuelle me semble un bon présage pour l'avenir.

je vais superposer les deux et passer en impression car je crois que j'ai 
trouvé de quoi décorer mes toilettes de manière originale pour étonner mes 
invités ^^ (en tout cas, de mon point de vue, plus qu'avec les inflorescences 
fractales d’un chou romanesco). 




Cyril H.

From: Guillaume Barrot
Date: 2012-08-04 12:08
To: Jérôme Nicolle
CC: frnog@FRnOG.org
Subject: Re: [FRnOG][TECH] Représentation d'Internet
Mandelbrot appliqué au reseau ?

Le 4 août 2012 00:48, Jérôme Nicolle jer...@ceriz.fr a écrit :

 Plop,

 Job Snijders[1], gestionnaire du NLNog Ring[2], a publié ce jour une
 représentation graphique des adjacences réseau telles que vues par le
 Looking Glass[3] mutualisé du ring.

 La vue graphique est intéressante il me semble, je vous laisse juges :

 http://instituut.net/~job/ring-lg/ipv6-bgp-adjacencies.jpeg
 http://instituut.net/~job/ring-lg/ipv4-bgp-adjacencies2.png

 [1] http://www.snijders-it.nl/
 [2] https://ring.nlnog.net/
 [3] http://lg.ring.nlnog.net/

 --
 Jérôme Nicolle
 06 19 31 27 14


 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/




-- 
Cordialement,

Guillaume BARROT

---
Liste de diffusion du FRnOG
http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/