đŸ Archived View for lord.re âș fast-posts âș 66-retour-sur-blocky âș index.gmi captured on 2023-03-20 at 17:38:06. Gemini links have been rewritten to link to archived content
âĄïž Next capture (2024-08-18)
-=-=-=-=-=-=-
-------------------------------------------------
[16/02/2023] - ~4mins - #dns #software #linux
-------------------------------------------------
Bon étrangement ça parle pas mal de DNS ces derniers temps sur ma timeline du Fediverse du coup j'ai eu envie de faire un ptit retour sur *Blocky*.
Je vous ai fait
il y a maintenant ⊠presque 3 ans !!
Il est toujours d'actualité.
Alors déjà , j'utilise toujours *Blocky*.
Le projet Ă©tait vraiment tout jeune Ă l'Ă©poque et maintenant il a connu plein de nouvelles releases.
Il marche toujours aussi bien en étant léger, rapide et toujours aussi simple à utiliser.
Niveau installation il commence Ă arriver dans les distros donc c'est encore plus simple qu'avant.
Ăa fait plaisir de le voir reconnu par le monde nunuxien :-)
Son premier argument de vente est dans son nom : il est lĂ pour bloquer des requĂȘtes.
Il se repose donc sur des blocklists qu'il met Ă jour de lui-mĂȘme, ça ne nĂ©cessite aucune intervention.
J'ai ajouté quelques blocklists dont
celle de l'inénarrable Sebsauvage
mĂȘme si franchement ça ne sert que trĂšs peu dans mon cas.
L'avantage de *blocky* par rapport à un résolveur classique est qu'il permet d'utiliser plusieurs résolveurs upstreams.
Et quand je dis plusieurs c'est pas 2 comme on l'entend habituellement.
Non lĂ on peut en avoir autant qu'on veut.
Blocky va rĂ©partir les requĂȘtes sur tous les rĂ©solveurs que vous allez lui filer.
C'est l'un des avantages qui me plaĂźt le plus dans ce logiciel.
Ăa permet de rĂ©partir mes requĂȘtes sur biens plus de rĂ©solveurs diffĂ©rents.
De ce fait, si un résolveur "tombe" (que ce soit en panne ou entre de mauvaises mains), il ne vera qu'une petite partie de mon trafic DNS global.
Ăa augmente donc Ă la fois la fiabilitĂ© mais surtout ça rĂ©duit le potentiel de nuisance sur la vie privĂ©e d'un rĂ©solveur.
D'ailleurs chaque requĂȘte sera envoyĂ© sur deux rĂ©solveurs et il prendra la rĂ©ponse du plus rapide.
Les rĂ©solveurs ne rĂ©pondant pas assez vite ou bien Ă©tant en erreur auront moins de chance d'ĂȘtre contactĂ© par la suite.
Une des nouveautés depuis mon article précédent est la présence d'un exporter *prometheus*.
Cela permet donc de générer des stats et de visualiser tout cela dans *grafana*.
Et franchement ? J'adore voir tout ça !
Pour cet article j'ai limité les stats sur les derniÚres 24h.
{{< img src="stats_diverses.png" alt="diverses stats plus ou moins utiles" title="Tous les champs ne sont pas fonctionnels mais c'est pas bien grave." >}}
Alors déjà on a pas mal d'information dÚs ce premier écran.
Tout d'abord on voit que le temps de réponse moyen est de 2.41ms ce qui est extrÚmement rapide.
C'est en trÚs grande partie grùce au cache qui évite d'aller consulter des ressources extérieures dans une grande partie des cas.
D'ailleurs on voit que 97% des réponses proviennent du cache.
Bon j'ai un taux anormalement élevé de réponses provenant de ce dernier parceque j'ai certaines machines qui font des tests réseaux constamment vers des pairs réseaux identiques.
Du coup, comme c'est testĂ© chaque minute, bha ⊠j'ai de trĂšs nombreuses requĂȘtes pour la mĂȘme destination.
Ensuite, on voit que j'ai gĂ©nĂ©rĂ© prĂšs de 93000 requĂȘtes et je n'ai eu que 2 erreurs (rĂ©solveurs upstreams HS si je ne m'abuse) durant cette pĂ©riode.
{{< img src="duration.png" alt="graphique montrant la répartition des durées de réponses concentrée majoritairement autour des 25ms." title="Mes temps de réponses sont vraiment pas dégueux !" >}}
Alors là , je ne sais pas pourquoi mais *Grafana* a un bug d'affichage, il décale la légende vers le bas ce qui fausse tout.
Il faut en gros tout décaller de deux lignes vers le bas.
Ce graph permet de voir un peu comment est réparti le temps de réponses.
On voit que c'est trĂšs souvent autour des 25ms et surtout rien au-dessus de 200ms
C'est plutĂŽt dispensable ce morceau.
{{< img src="query_type.png" alt="46 de requĂȘtes pour du AAAA et 54% pour du A" title="Ă peu prĂšs la moitiĂ© des requĂȘtes sont pour de l'IPv6 !">}}
Haa ça c'est de suite bien plus intéressant comme stats.
Ăa permet de voir qu'environ la moitiĂ© des pairs auxquels je me connecte je le fais en IPv6 !
C'est plutĂŽt chouette !
On a fait la moitié du chemin pour pouvoir virer IPv4.
{{< img src="response_type.png" alt="96% des requĂȘtes proviennent du cache, 4% sont resolved et seulement 65 soit 0% ont Ă©tĂ© bloquĂ©es." title="De l'intĂ©ret d'un rĂ©solveur cache bloquant." >}}
Le cĆur du boulot de Blocky.
Ici on voit bien qu'il m'Ă©vite une Ă©norme partie de trafic DNS sortant grĂące Ă son cache.
En plus ça accélÚre le process vu que ça reste local.
{{< img src="sources.png" alt="Répartition de l'utilisation des résolveurs upstreams. Le plus gros est à 7% et le plus petit à 1%." title="Le graph qui me procure le plus de plaisir." >}}
Voilà la dillution de mon trafic DNS représenté en 1 graph.
On voit que le résolveur upstreams qui reçoit le plus de trafic de ma part n'en voit que 7%.
Idéalement j'aimerai bien en avoir encore plus dans la liste pour dilluer toujours plus.
J'aimerai notamemment dégager ceux de Cloudflare de la liste et n'avoir si possible plus que du DoT ou DoH.
Si jamais vous connaissez des fournisseurs qui peuvent répondre à mes critÚres, je suis preneur !
Je vous le recommande chaudement en plus maintenant ils ont
pour présenter le projet.
------------------------------------
------------------------------------
[16/02/2023] [dns software linux]
------------------------------------