DuckDNS est un service de DNS dynamique (comme noip.com), mais simple, efficace, gratuit et vraiment "No bullshit". C'est sérieusement cool.
Ce n'est pas compatible avec le protocole DynDNS, mais c'est très facilement installable : https://www.duckdns.org/install.jsp
EDIT: Ah ben si, ils ont une API compatible DynDNS : https://www.duckdns.org/install.jsp
Dans un contexte où l’accès à l’information en ligne est essentiel, certaines entreprises comme Canal+ ont intensifié leurs efforts pour restreindre l’accès à des contenus spécifiques en imposant des censures via les fournisseurs de DNS. Cette pratique pose des problèmes d’accès à Internet pour de nombreux utilisateurs. Les réseaux privés virtuels (VPN) se révèlent être une solution efficace pour contourner ces restrictions.
Comprendre la censure par les fournisseurs de DNS
Les fournisseurs de DNS jouent un rôle clé dans la navigation Internet en traduisant les noms de domaine en adresses IP. En manipulant ces serveurs, il est possible de bloquer l’accès à certains sites Web en redirigeant ou filtrant les requêtes DNS.
Canal+ a récemment obtenu des décisions judiciaires contraignant des fournisseurs majeurs comme Google et Cloudflare à bloquer des sites pirates via leurs services DNS. Cette mesure vise à limiter l’accès aux contenus illégaux, mais elle peut également bloquer des sites légitimes.
Pour contourner la censure, certains utilisateurs se tournent vers des services DNS alternatifs tels que Google DNS ou Cloudflare. Cependant, ces services peuvent être contraints de se conformer aux décisions judiciaires et de bloquer l’accès à certains sites.
Des services comme OpenDNS ont même dû suspendre leurs activités en France en raison de pressions judiciaires. C’est dans ce contexte que des alternatives plus robustes, comme Quad9, continuent de fournir des services DNS sécurisés et non censurés.
Les VPN : une solution efficace pour contourner la censure
Les VPN offrent une solution complète pour contourner la censure. En chiffrant le trafic Internet et en le redirigeant via des serveurs situés dans des régions non censurées, les VPN permettent aux utilisateurs d’accéder librement à l’ensemble du web.
Contrairement à un simple changement de DNS, les VPN masquent également l’adresse IP de l’utilisateur et utilisent leurs propres serveurs DNS, échappant ainsi aux restrictions imposées localement.
Fonctionnement des VPN pour contourner la censure DNS
Lorsqu’un utilisateur se connecte à un VPN, sa connexion est chiffrée et acheminée vers un serveur VPN situé dans une région sans censure. Ce serveur effectue les requêtes DNS en utilisant ses propres serveurs non censurés, garantissant que les restrictions locales ne s’appliquent pas.
Ainsi, même si un fournisseur de DNS local bloque certains sites, le VPN permet de contourner ces blocages et d’accéder aux contenus souhaités.
Choisir le bon VPN pour contourner la censure
Tous les VPN ne sont pas égaux en termes de contournement de la censure. Il est essentiel de choisir un fournisseur de VPN offrant des fonctionnalités avancées, telles que :
Obscurcissement du trafic VPN
Protection contre les fuites DNS
Politique stricte de non-conservation des logs
Des services comme NordVPN et Surfshark VPN sont reconnus pour leur capacité à contourner efficacement les restrictions, même dans des environnements fortement censurés.
Les avantages supplémentaires des VPN
En plus de permettre le contournement de la censure, les VPN offrent plusieurs autres avantages :
Protection de la vie privée : en masquant l’adresse IP et en chiffrant les données, les VPN protègent contre la surveillance et le suivi en ligne.
Sécurité accrue : les VPN protègent contre les cybermenaces, notamment sur les réseaux Wi-Fi publics.
Accès à des contenus géo-restreints : les VPN permettent d’accéder à des services et contenus disponibles uniquement dans certaines régions du monde.
Les limites et précautions à prendre
Bien que les VPN soient des outils puissants, ils ne sont pas infaillibles. Certains services en ligne peuvent détecter et bloquer les connexions VPN.
Pour cette raison, il est recommandé d’utiliser des VPN disposant de fonctionnalités d’obscurcissement et de sélectionner des serveurs moins exposés aux blocages.
Il est également essentiel de respecter les lois locales concernant l’utilisation des VPN, car leur usage est restreint dans certains pays.
Conclusion
Face à la censure croissante imposée par des entreprises comme Canal+ via les fournisseurs de DNS, les VPN apparaissent comme une solution essentielle pour garantir la liberté d’accès à l’information.
En offrant une connexion sécurisée et non censurée, les VPN assurent aux utilisateurs un accès libre à Internet, tout en protégeant leur vie privée. Cependant, il est crucial de bien choisir son fournisseur de VPN et de rester informé des évolutions légales et technologiques liées à leur utilisation.
Les VPN ne sont pas seulement des outils de contournement, mais également des garants de la liberté numérique dans un environnement de plus en plus contrôlé.
salut Seb merci pour le taff, petites précisions qui pourrons certainement t'aider à améliorer ta page wiki :
_Windows à besoin du service "Client DNS" pour faire ipconfig \flushdns donc je conseil de faire la commande puis ensuite désactiver le service
_Sur Windows au lieu de se taper la mise à jour de ton fichier à la main tout les mois je conseil l'utilisation du logiciel HostMan qui permet de rentrer l'URL de ton fichier host et qui le met à jour tout seul etc
Dans ce tutoriel, nous allons configurer Windows pour bloquer les sites pornographiques à l'aide du DNS Cloudflare for Families qui assure un filtrage.
Encore un déterrage de brouillon, sur un problème qui doit être toujours d’actualité dans son concept. Un Problème surprenant (pour les pros du DNS peut-être pas), mais voilà, on a eu droit à un incident inattendu, que je voulais partager pour sa bizarrerie apparente. Parce que si j’ai trouvé la solution assez rapidement, il m’a fallu du temps pour comprendre, et je suis pas encore certain d’avoir tout intégré, même deux ans et demi après.
Pour fournir une résolution souple aux clients sur leur plateforme Kubernetes (parce que pourquoi pas), on leur a fourni un alias à configurer sur leur propre zone, histoire de ne pas avoir à dépendre d’eux pour d’éventuelles migrations/reconfigurations déménagements. Cet alias repose sur une fonctionnalité du DNS, les wildcard. Ça donne quelque chose dans ce genre-là :
#notredomaine.fr
prd A 1.2.3.4
sta A 5.6.7.8
*.prd CNAME prd
*.sta CNAME sta
On l’aura compris, « prd » c’est le cluster de prod, « sta » le cluster de staging. De leur côté, les clients déclarent l’alias dans leur propre zone :
Dans une situation simple, classique, c’est l’alias *.prd qui prend en charge et fournit la réponse aux clients qui cherchent à joindre un des domaines concernés par ce dispositif. Ah, et en passant, on ne peut pas appliquer un CNAME à l’apex (autrement appelé la racine) d’un domaine (RFC je sais plus, demandez à votre moteur de recherche). Et si vous vous demandez pourquoi un tel setup, c’est qu’on se sert aussi d’un tel « domaine technique » (comprendre un domaine différent de celui du vrai site et géré par nos soins) pour pouvoir tester le site dans différentes situations sans reposer sur le nom de domaine du client, notamment pendant certaines phases de validation, et pour pouvoir gérer ça au niveau des Ingress Rules.
Déplacement d’Ingress Controller, arrivent les problèmes
Eh oui, parce que la vie est ainsi faite, on nous demande de déployer un Ingress Controller particulier avec des paramètres bien précis, donc une nouvelle adresse IP, et de déplacer certains des sites derrière celui-ci. Je vais pas détailler la partie « kube » de ce dispositif, c’est assez trivial en principe (cherchez ingressClass si vraiment vous voyez toujours pas), mais voilà comment on prépare côté DNS :
prd-private A 4.3.2.1
*.prd-private CNAME prd-private
Et quand on doit bouger www.domain2.com, avec notre dispositif, avec le Go du client, j’applique la modif côté cluster et je déplace de manière explicite côté DNS de mon côté:
www.domain2.com.prd CNAME prd-private
Et là, patatras. Quand un collègue est venu me voir au bout d’un quart d’heure, en me disant qu’un autre domaine sans rapport avec ma modification était tombé, et ayant l’historique prouvant que j’étais le dernier à avoir modifié notre zone notredomaine.fr, il est clair que l’effet de bord n’avait pas été correctement anticipé. Mais quel effet me direz-vous, sachant qu’on avait testé en staging avant sans avoir détecté ce genre de comportement ?
Le premier indice, c’est que tous les domaines ne sont pas concernés. Sur les 4 alertes qui sont apparues, le point commun est que toutes les URLs ont des domaines en .com. Le second, c’est que ma modif fonctionne pour mon propre domaine. Au bout de cinq minutes, je dis à Camille : « je suis pas sûr mais je tente un truc ». J’ai rajouté une ligne :
*.com.prd CNAME prd
Et ça répond à nouveau. J’ai eu du pif, mais j’avoue que sur le moment, c’est plus de l’instinct qu’autre chose, et j’aurais été bien en peine d’expliquer pourquoi, mais au niveau du comportement, on voit maintenant ce qui se passe. Je vais essayer de formuler du mieux possible ce que j’en ai compris.
Explication pas forcément claire
Pour rappel, dans le DNS les domaines fonctionnent par niveau, chaque niveau est séparé par un point. On parle souvent de « sous-domaine », mais c’est un abus de langage, en pratique, chaque niveau dispose des mêmes fonctionnalités et propriétés, ils héritent de certaines caractéristiques, le système étant hiérarchique (com, domain.com, www.domain.com, etc). Dans le cas qui nous occupe, tant qu’on avait qu’un seul wildcard pour tout ce qui concernait les niveaux au dessus de prd.mondomaine.fr, le résolveur ne se posait pas trop de questions et répondait à tout. Mais quand j’ai déclaré www.domain2.com.prd dans mondomaine.fr, j’ai donc déclaré au moins une entrée sur .com.prd. À partir de ce moment-là, cette déclaration explicite exclut toutes les autres réponses par le wildcard. La seule solution de contournement implique de déclarer un wilcard supplémentaire pour ce niveau spécifiquement afin de retrouver un comportement initial.
Pourquoi ce comportement ? Eh bien, comme je l’ai dit, les domaines sont gérés par niveau, et il faut savoir que chaque niveau peut être délégué / géré par un résolveur différent. Dès lors, déclarer une entrée spécifique pour un niveau implique que le résolveur arrête d’appliquer les propriétés des niveaux précédents aux niveaux suivants, ce que permet justement le wildcard. Et c’est logique, si un niveau contient des informations (ici au moins un CNAME), si jamais il est délégué, on n’est pas censé répondre à la place dudit délégué. Certes ici c’est le même, et donc il aurait pu continuer de répondre. Il faut se souvenir que le système de DNS remonte à 1983, et même s’il a été mis à jour à la marge, la majorité du fonctionnement intrinsèque n’a pas bougé, et cette gestion en niveaux en fait partie.
On évite les wildcard alors ?
Certains diront oui, mais dans le monde réel, parfois c’est plus pratique/évident de faire avec (tout le monde ne peut pas composer avec de la résolution dynamique comme le fait Kubernetes en interne). Ici, la solution la plus pratique aurait été de supprimer l’utilisation des .com/.fr/.it/.whatever des alias, et ne garder que le nom sans le TLD, ce qui aurait rendu chaque entrée plus unique et donc limité l’impact de l’exclusion du wildcard global du « calcul » de la réponse.
Dans certaines situations, déléguer le niveau de l’alias est une solution plus adaptée, notamment dans le cadre de l’usage certains outils comme les CDN Cloudflare ou Akamai, ainsi ils se chargent notamment de la mise à jour dynamique de la ou les adresses IP par lesquelles vous passez. Certains utilisent aussi du DNS « géographique », à savoir donner une réponse différente en fonction de là où vous vous trouvez sur le réseau (plus ou moins corrélé à votre emplacement physique), réponse qui doit pointer sur un serveur plus proche et donc plus « performant ». Bref, vous l’aurez compris, le wildcard dans le DNS n’est pas toujours la solution la plus adaptée, et ce problème rencontré en production est là pour le rappeler.
Ah, et pour ceux qui pensent qu’on aurait pu juste tout déclarer manuellement, quand on pense une plateforme pour de l’hébergement massif, semi-dynamique, et qu’on a pas les API / accès pour gérer la zone programmatiquement, et qu’on a passé les 50 sites, ben utilise les wildcards DNS « épicétou »
ping can resolve .local domains, but e.g. host can't, which is annoying when trying to resolve the IP address of a mDNS host from a e.g. script.
Fortunately, there is avahi-resolve that can do that, and is easy enough to use in scripts.
The reason I needed that was to consolidate a setup where a network scanner provides a mDNS name, but it can't be used in the SANE device path, only the IP works. So, replace the IP field in the call with "$(avahi-resolve --name -4 NAME.local | awk '{print $2}')" and voila.
European Alternatives is a project that collects and analyzes European alternatives to digital services and products, such as cloud services and SaaS products. We regularly receive advice and suggestions from European Alternatives users, so feel free to reach out!
Dans ce tutoriel, nous allons configurer Windows pour bloquer les sites pornographiques à l'aide du DNS Cloudflare for Families qui assure un filtrage.
Connexion
