Posté(e) le 12 août 20159 a Perso ça m'a prit plus de temps de monter une machine de test et la régler que de le mettre en dure chez moi. Et trois commandes et deux edit de .conf ça fonctionne... Mais faut encore que je vérifie que l'ipv6 passe bien et que je soit pas limité a l'ipv4
Posté(e) le 12 août 20159 a J'ai fait des tests de perfs (latence sur les réponses) sur ma ligne ADSL (pourrie) ce week-end. Me reste encore à mettre en forme et écrire une bafouille.
Posté(e) le 12 août 20159 a Je pense qu’après une bonne semaine d'utilisation le cache est bien rempli et réduit les latences.
Posté(e) le 12 août 20159 a Nope, le cache se vide assez vite (merci les TTL de 600 (Google) voir 60 secondes de Twitter qui forcent à refaire des requêtes fréquentes - bon heureusement les enregistrements NS ont souvent un TTL plus long mais pas tout le temps). Pour vraiment garder un cache à jour, il faut requêter en permanence les domaines. Le prefetch permet de pallier en parti à ça, mais il ne permet de pallier les longues phases où l'on va dormir En clair, mon test portait sur environ 1000 réponses (ça fait un peu plus de 1000 requêtes - mais là j'ai pas compté ) sur un cache de 3-4 jours : d <=50ms -> 480 requêtes 50ms< d <=100ms -> 113 100ms< d <=200ms -> 77 200ms< d <=300ms -> 63 d >300ms -> 274 où d correspond à la valeur dns.time dans Wireshark, soit la durée entre la dernière question d'une requête et l'arrivée de la réponse à la requête. Testé sous Linux car sous Windows, si la réponse n'est pas arrivée au bout d'une seconde, il renvoie la même requête et c'est donc cette dernière qui est prise en compte par Wireshark, ce qui fausse les résultat En clair, 48% des requêtes tapent dans le cache. Faut que je vérifie, mais la manie de Firefox à faire des demandes fréquentes sur les onglets ouverts joue et 11% sont sous les 100ms (ce qui indique grosso modo que tu connais le serveur à questionner). Le reste nécessite de passer par la racine ou les DNS des TLD (ce qui est plus probable) Sur le DNS de mon FAI (OVH), même conditions de tests, 0% des requêtes sont arrivées en moins de 50ms, en revanche 70% ont pris entre 50 et 100ms. Avec un cache vide, on obtient 45% de réponses à plus de 200ms (contre 33 ici). Le test que j'ai fait cache vide n'utilise néanmoins pas tout à fait la même méthodo (je l'ai fait sous Windows, avant de découvrir que cela posait problème) et n'ai donc pas fiable. Bon mes résultats sont assez mauvais, je précise que ma ligne ADSL est vraiment pourri (j'ai eut du 4Mbits/1Mbits stable et un ping correct pendant 2 ans et demi et depuis début juin, je peine à avoir 3.5Mbits/400kbits avec un ping qui joue au yo-yo - ticket en cours chez le FAI ) Je compte bien tester sur une ligne VDSL correcte la semaine prochaine. L'idéal serait d'avoir les résultats sur un accès fibre. Autre point que dont j'aimerai connaitre l'INpact est la validation DNSSEC. Combien de temps rajoute-t-elle ? Le fait que les serveurs de mon FAI ne l'utilise pas joue-t-il ?... Bon par contre, flemme de configurer un serveur ne validant pas les réponses
Posté(e) le 12 août 20159 a Ce que je vient de voir pour la config de unbound me ravi ! local-zone: "doubleclick.net" redirectlocal-data: "doubleclick.net A 127.0.0.1"local-zone: "googlesyndication.com" redirectlocal-data: "googlesyndication.com A 127.0.0.1"local-zone: "googleadservices.com" redirectlocal-data: "googleadservices.com A 127.0.0.1"local-zone: "google-analytics.com" redirectlocal-data: "google-analytics.com A 127.0.0.1"local-zone: "ads.youtube.com" redirectlocal-data: "ads.youtube.com A 127.0.0.1"local-zone: "adserver.yahoo.com" redirectlocal-data: "adserver.yahoo.com A 127.0.0.1"
Posté(e) le 12 août 20159 a Sur le site de Calomel, y a une méthode pour récupérer une liste sur le ouèbe et l'intégrer à la conf
Posté(e) le 12 août 20159 a Ouais me serais plutôt du genre à travailler à base de liste de peerguardian ou adblock Peerguardian étant mon préféré (TMG if you know what i mean )
Posté(e) le 12 août 20159 a La liste proposée (de yoyo.org) est utilisée dans plusieurs bloqueurs de pubs, dont AdAway sur Android. Ensuite, c'est pas avec résolveur DNS qui va empêcher quelqu'un de se connecter avec ton client Torrent
Posté(e) le 12 août 20159 a Oui mais ya pas que ca dans les liste de Peerguardian. Du coup je vais étudier un script pour extraire des listes pour convertir en ligne pour unbound. Voir même pour iptables
Posté(e) le 12 août 20159 a C'est une liste du type 127.0.0.1 example.org Y a un script dans le lien que je filais Sinon, va falloir faire du sed
Posté(e) le 12 août 20159 a Aaaaah les joies iptables. J'espère que tu as aussi ip6tables à te farcir. Ça serait bête de passer à coté
Posté(e) le 12 août 20159 a Surtout iptables6. A terme j'aimerais éviter de me servir d'ipv4. Je pense même baser mon Projet de licence sur une migration d'une entreprise de V4 ->V6 à faible coût et a base de LL.
Posté(e) le 13 août 20159 a En passant, j'ai écrit un tuto sur comment monter un serveur de cache DNS avec unbound s'appuyant directement sur les serveurs racines. (http://homeserver-diy.net/wiki/index.php?title=Installer_et_configurer_son_serveur_DNS_connecté_aux_serveurs_root_avec_Unbound) J'en avait profité pour expliquer comment le faire mentir à propos des IP des régies pubs comme Krapace le cite plus haut. En cherchant un peu j'ai trouvé une grosse liste de noms de domaines de régies pubs. Je vous la pose là: Liste de régies pubs Sinon pour partager mon expérience, j'avais installé 2 serveurs DNS. Un sur une machine locale et l'autre sur un VPS. Celui sur le VPS a rapidement été détourné pour participer à une attaque par amplification. Donc comme le dit S. Bortzmeyer, pensez à fermer vos serveurs. Modifié le 13 août 20159 a par John Shaft Les joies de l'encodage de caractères
Posté(e) le 13 août 20159 a Celui sur le VPS a rapidement été détourné pour participer à une attaque par amplification Ouch. Pas de de contrôle d'accès ? EDIT : j'ai modifié ton post, y avait des crasses dans l'encodage de caractères
Posté(e) le 13 août 20159 a Ouch. Pas de de contrôle d'accès ? Le but était de partager ce serveur avec qui le souhaitait et quelque soit le client. Je n'avais donc mis en place aucun contrôle d'accès. Les pirates en ont profité quelques heures...
Posté(e) le 13 août 20159 a Ok. J'avais eut la même idée, mais en cherchant de la doc, j'étais tombé sur l'article de Bortzmeyer et le RFC 5358
Posté(e) le 28 août 20159 a @Milton pardon j'ai lu en diagonale, j'ai confondu ubuntu avec unbound ( que je ne connaissais pas ). Il faut donc regarder dans le fichier unbound.conf la zone : forward-zone: name: "." forward-addr: 8.8.8.8 # Google Public DNS forward-addr: 74.82.42.42 # Hurricane Electric forward-addr: 4.2.2.4 # Level3 Verizon C'est les dns utilisés par unbound Normalement le localhost a un masque de 8 bit donc la 127.0.1.1 devrait être compris dans la plage. Un traceroute 127.0.1.1 devrait le confirmer. Heu, alors une ipv4, c'est 32 bits, 4x8 donc. On a donc 0 pour les 8 derniers bits soit 2^8, qui nous donne: 256. En info, on commence à compter à partir de zéro, donc --> 255. Donc, 127.0.0.254 maxi. Tu ne sors pas de la plage IP. Ton IP doit être 127.0.0.1. Si mes souvenirs sont bons mais je peux me tromper. Modifié le 28 août 20159 a par Ricard
Posté(e) le 28 août 20159 a Oui l'IPv4 est en 32 bit mais le masque est de 8 bit : IPv4 Table de routage =========================================================================== Itinéraires actifs : Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.74 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 toutes les IP en 127.X.Y.Z sont compris dans le localhost Avec un masque de 24 bit on reste dans la plage 127.0.0.0 -> 127.0.0.255 Sauf que 127.0.0.0 est réservé car désigne le réseau et la 127.0.0.255 l'adresse de broadcast donc en fait tu ne peux adresser que de 127.0.0.1 à 127.0.0.254 avec un masque de 24 bits. Edit: correction des fautes d'ortho ( pas réveillé encore ) Modifié le 28 août 20159 a par Skywa
Posté(e) le 28 août 20159 a Ok. J'avais eut la même idée, mais en cherchant de la doc, j'étais tombé sur l'article de Bortzmeyer et le RFC 5358 Spède de Geek. Oui l'IPv4 est en 32 bit mais le masque est de 8 bit : IPv4 Table de routage =========================================================================== Itinéraires actifs : Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.74 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 toutes les IP en 127.X.Y.Z sont compris dans le localhost Avec un masque de 24 bit on reste dans la blage 127.0.0.0 -> 127.0.0.255 Sauf que 127.0.0.0 est réservé car désigne le réseau est la 127.0.0.255 l'adresse de broadcast donc en fait tu ne peux adresser que de 127.0.0.1 à 127.0.0.254 avec un masque de 24 bits. Oui exact. Faute de frappe. je corrige mon post.
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.