L’article explore les solutions pour bloquer les trackers et domaines malveillants via un résolveur DNS menteur, en exploitant le mécanisme RPZ (Response Policy Zone). L’auteur, confronté aux limites d’un adblocker sur son Turris, teste plusieurs résolveurs DNS (Bind9, Knot-resolver, Unbound, Blocky, Pi-hole) pour évaluer leur capacité à filtrer efficacement les requêtes. Il souligne l’importance de RPZ, qui permet de bloquer des domaines, des IP ou des plages d’IP, tout en offrant une alternative aux outils traditionnels comme Pi-hole ou Blocky.
Pour automatiser la gestion des listes RPZ, l’auteur a développé un script Python, rpz-maker.py, capable de combiner, dédupliquer et optimiser des listes de domaines par catégorie, avec des options de personnalisation avancées. Ce script, sans dépendances externes, simplifie la configuration et permet une gestion fine des autorisations et restrictions par réseau client.
Enfin, l’article présente un tableau comparatif des résolveurs testés, évaluant leur simplicité de configuration, leur interface en ligne de commande, leur support des ACL, leur interface web, leur compatibilité avec Prometheus et Redis Sentinel. Blocky et Knot-resolver (version 6) ressortent comme les solutions les plus équilibrées, tandis que Pi-hole et Unbound se distinguent par leur flexibilité mais avec des compromis en termes de complexité ou de consommation de ressources.
Quien est un outil en ligne de commande conçu pour analyser en profondeur un nom de domaine ou une adresse IP, offrant une alternative plus complète que la commande classique whois. Il centralise plusieurs fonctionnalités comme la recherche d’informations d’enregistrement, l’analyse DNS, la configuration email (MX, SPF, DMARC) et l’évaluation SEO (balises, données structurées, Core Web Vitals).
L’outil propose une interface interactive (TUI) et une sortie au format JSON pour une intégration dans des scripts. Son installation est flexible, disponible via Homebrew, APT ou directement avec Go. Des sous-commandes permettent de cibler des analyses spécifiques, comme les données DNS ou la stack technique d’un site.
Quien peut aussi être testé sans installation via ssh quien.sh, ce qui le rend accessible rapidement. Il se positionne comme une solution pratique pour remplacer whois au quotidien, en fournissant des données plus détaillées et structurées.
Cette page explore le fonctionnement du réseau internet et des communications modernes à partir de principes fondamentaux. Elle explique comment les données (voix, messages, vidéos) sont transformées en signaux électriques, lumineux ou radio, traversant des infrastructures complexes et indépendantes pour atteindre leur destination en quelques millisecondes. L’auteur souligne l’absence de contrôle centralisé, malgré la fiabilité impressionnante du système, qui repose sur des protocoles comme le packet switching, TCP ou DNS, chacun répondant à des problèmes spécifiques apparus au fil du temps.
L’article retrace aussi l’évolution historique des réseaux, bien antérieurs à l’informatique, depuis les systèmes mécaniques (comme les fils entre boîtes en métal) jusqu’aux réseaux électriques et numériques. Il montre que l’internet actuel est le résultat d’ajouts successifs, où chaque couche protocolaire corrige des limites concrètes, plutôt que d’une conception globale. Cette approche progressive explique pourquoi certaines technologies, comme les câbles sous-marins, restent essentielles malgré leur âge.
Enfin, l’auteur vise à rendre compréhensibles les mécanismes invisibles du web, comme la sécurité des connexions (TLS), les latences ou les pannes de routage, en les reliant à une vision cohérente des réseaux. L’objectif est de transformer des mystères quotidiens en connaissances intuitives, en partant des bases physiques jusqu’aux couches logicielles.
L'auteur décrit la refonte de son infrastructure DNS pour éliminer les points de défaillance uniques (SPOF) et améliorer la résilience. Son ancien setup, basé sur un seul conteneur LXC combinant AdGuard Home et NPM, souffrait d'un manque de redondance et d'une résolution inefficace des noms de domaine locaux, générant du trafic inutile via le NAT (hairpin). La nouvelle architecture sépare les rôles en quatre composants : Technitium DNS Server pour la gestion des zones DNS locales et la haute disponibilité, AdGuard Home pour le filtrage avancé des requêtes, NextDNS comme résolveur chiffré en amont, et NPM pour la gestion des proxy inverses.
Technitium assure la synchronisation automatique entre deux instances, permettant une continuité de service immédiate en cas de panne d'un nœud Proxmox. AdGuard Home, déployé dans un conteneur dédié, applique des règles de filtrage personnalisées par client ou groupe, tandis que NextDNS prend le relais pour les requêtes publiques et offre une protection renforcée hors réseau. NPM, isolé dans son propre conteneur, gère les redirections des noms de domaine locaux et publics sans conflit.
Cette refonte élimine les inefficacités du hairpin NAT et garantit un filtrage cohérent, que ce soit en local ou à distance, tout en assurant une haute disponibilité grâce à la redondance des composants.
Stéphane Bortzmeyer explique pourquoi le terme « propagation » est impropre pour décrire la mise à jour des données DNS. Contrairement à des protocoles comme BGP, le DNS fonctionne en pull (tirage) : les résolveurs demandent les informations aux serveurs faisant autorité, qui les conservent en cache selon un TTL (Time To Live) défini. Plutôt que de « propager », les données sont « réjuvénées » (terme proposé par Michel Py) lorsque le cache expire. L’auteur illustre ce mécanisme avec des exemples concrets via dig, montrant comment le TTL contrôle la durée de validité des réponses. Une lecture éclairante pour comprendre le fonctionnement réel du DNS !
Ce tutoriel explique comment sécuriser l'envoi d'e-mails en utilisant les protocoles SPF, DKIM et DMARC. Il détaille les failles du protocole SMTP et comment ces trois mécanismes complémentaires, basés sur le DNS, permettent de vérifier l'identité des expéditeurs et de lutter contre le spam et le phishing. Le tutoriel aborde la configuration de chaque protocole, leurs limites et leurs synergies, avec des exemples de syntaxe pour les enregistrements DNS.
Ce partage explique le fonctionnement du DNS (Domain Name System), un système qui traduit les noms de domaine en adresses IP. L'auteur partage son expérience personnelle de résolution de problèmes liés à la propagation DNS et au TTL (Time to Live). Le résumé détaille la hiérarchie DNS, incluant les serveurs racine, les domaines de premier niveau (TLD), les domaines et les sous-domaines. Il explique également les différents types d'enregistrements DNS tels que les enregistrements A, AAAA, CNAME et MX, et leur utilité. Une ressource utile pour comprendre comment les noms de domaine sont résolus en adresses IP et comment gérer les enregistrements DNS.
L’Italie a infligé une amende record à Cloudflare pour ne pas avoir bloqué des sites pirates via ses serveurs DNS, déclenchant un débat sur la neutralité du réseau et la souveraineté numérique. Cloudflare, qui gère 200 milliards de requêtes quotidiennes, argue que filtrer ces sites ralentirait l’internet mondial et ouvre la porte à une fragmentation du web, tout en reconnaissant qu’il le fait déjà pour son DNS "famille". L’Italie et la France privilégient des blocages administratifs rapides (30 minutes sans juge), tandis que l’Allemagne rejette cette approche au nom de la disproportion. Les alternatives existent (registrars, FAI, déréférencement, blocage IP), mais aucune n’est parfaite. Le CEO de Cloudflare, Matthew Prince, menace de rétorsions (coupure des services gratuits en Italie, retrait des serveurs), tout en invoquant le free speech — un argument critiquable, vu les censures passées de l’entreprise et l’hypocrisie des géants tech américains. Le vrai enjeu ? Notre dépendance à des infrastructures contrôlées par des acteurs privés aux agendas politiques, face à des États européens tentés par des mesures administratives expéditives. Aucun camp n’est exemplaire : ni les régulateurs, ni les géants du net. La question reste : qui doit décider ce qui est acceptable en ligne, et selon quelles règles ?
Ce billet explique comment configurer des domaines personnalisés avec SSL dynamique pour une application multi-tenant utilisant Coolify et Traefik. L'auteur, Hugo Lassiège, détaille les étapes pour rediriger le trafic via des enregistrements DNS (CNAME, ALIAS, ou A) et configurer Traefik pour gérer les certificats SSL pour ces domaines personnalisés, en évitant de redémarrer l'application et en permettant une gestion programmatique.
L'auteur partage son expérience de migration de NSD à Knot DNS pour gérer ses certificats Let's Encrypt de manière plus efficace. Il explique les limites de NSD, notamment l'absence de gestion automatique des signatures RRSIG et le manque de support pour la RFC 2136 (Dynamic DNS). En adoptant Knot DNS, il résout ces problèmes et automatise la gestion des certificats, y compris les wildcards, grâce aux mises à jour dynamiques des zones DNS. Il détaille également son processus de configuration et de vérification, incluant l'utilisation d'Ansible pour gérer Knot DNS.
L'auteur de ce billet critique la dépendance excessive aux géants du cloud pour l'hébergement de sites web, y compris pour les projets personnels. Il argue que l'autohébergement peut offrir une fiabilité suffisante, surtout pour des sites à trafic modéré. Il propose des solutions pour améliorer la résilience, comme la redondance des serveurs DNS, et encourage à repenser la nécessité d'une disponibilité absolue pour les petits projets.
Ce billet explique comment configurer une application multi-tenant avec des sous-domaines dynamiques (ex: clientA.monapp.com, clientB.monapp.com) en utilisant Coolify et Nuxt. Coolify, une alternative open-source aux PAAS comme Heroku, permet de déployer des applications et services managés. L’astuce repose sur l’utilisation des wildcard domains et la modification des Container labels de Traefik pour accepter tout le trafic sur *.monapp.com via une expression régulière (HostRegexp(.+.monapp.com$)). Côté Nuxt, un composableuseTenant()` extrait le sous-domaine de l’URL pour identifier le client. Une solution simple une fois la configuration Traefik bien comprise !
Il s'agit d'une alternative à Adguard ou Pi-hole, un intercepteur DNS pour bloquer les requêtes vers les domaines indésirables.
Ce billet explique comment résoudre en DNS les noms de conteneurs Docker sous le domaine local .docker en utilisant systemd-resolved plutôt que dnsmasq, une solution plus simple et performante depuis systemd 258. L’auteur utilise toujours dnsdock pour gérer la résolution DNS, mais délègue désormais la zone .docker à ce service via un fichier de configuration /etc/systemd/dns-delegate.d/docker.dns-delegate. Après avoir lancé dnsdock et configuré resolved, il devient possible de résoudre les noms des conteneurs (basés sur leur nom, alias ou étiquettes) directement depuis la machine hôte, facilitant ainsi la gestion de plusieurs services comme PostgreSQL sans conflit de ports. Une mise à jour pratique pour les utilisateurs de Docker et systemd.
L'article traite des problèmes courants liés au DNS dans Kubernetes, en se concentrant sur trois principaux problèmes :
- Problème des ndots : Kubernetes tente d'être intelligent en essayant plusieurs suffixes DNS pour résoudre les noms, ce qui peut entraîner une charge accrue sur le serveur DNS et une latence plus importante. La solution consiste à utiliser des noms de domaine complets (FQDN) ou à ajuster la valeur de ndots.
- Problème de Lameduck : Lors de la suppression d'un pod, il peut y avoir un délai avant que kube-proxy ne mette à jour les règles iptables, ce qui peut entraîner des erreurs de connexion. La solution consiste à configurer un délai de grâce (lameduck) pour permettre à kube-proxy de se réconcilier.
- Problème de conntrack : Il existe un bug non corrigé dans kube-proxy en mode iptables qui provoque une perte de trafic UDP lors de la suppression d'un pod, affectant particulièrement le DNS. Les solutions partielles incluent l'ajout d'un timeout DNS ou la limitation du redémarrage des pods CoreDNS.
L'article souligne que ces problèmes peuvent avoir un impact significatif sur les performances et la fiabilité des clusters Kubernetes, en particulier ceux hébergés sur des plateformes comme AWS EKS.
Tout est dans le titrea
Tout est dans le titre
Tout est dans le titre
Présentation du type de données RESINFO permettant de connaître les caractéristiques d'un résolveur DNS : chiffrement des requêtes, DNS menteur, minimisation des requêtes, etc.