dog is a command-line DNS client.
For documentation on how to use dog, see the website: https://dns.lookup.dog/
— Permalien
Pour faire suite au wébinaire "Comment créer et tester votre résolveur DNS sur TLS et DNS sur HTTPS (DoT/DoH)", l’Afnic publie les ressources présentées à cette occasion, en association avec son Conseil scientifique.
Le DNS est utilisé dans la quasi-totalité des échanges sur internet (accès aux noms de domaine, services, applications, etc.).
Ce protocole majeur était l’un des derniers à ne pas être protégé par la cryptographie pour le transport des informations (requêtes et réponses). Il évolue rapidement ces dernières années pour renforcer la sécurisation des requêtes DNS et l’utilisation des nouveaux canaux (TLS, http/2, http/3) afin de ne plus transiter en clair sur le réseau.
L’objectif principal de cette mise en œuvre étant de protéger le lien entre un utilisateur et le résolveur configuré.
Il est à noter que le renforcement du niveau de confidentialité des échanges est complémentaire à DNSSEC, qui reste un mécanisme nécessaire pour la vérification de l’intégrité d’une réponse DNS.
L’Afnic est partie du constat qu’il n’existait pas ou peu de ressources francophones sur la mise en œuvre d’un résolveur DoT ou DoH (aujourd’hui principalement des guides pour configurer le transfert de ses requêtes vers un résolveur tiers supportant DoT ou DoH). Pour combler ce manque, l’Afnic a créé et met à disposition ces nouvelles contributions, illustrées d’exemples concrets et accessibles à tous. L’ensemble des personnes et organisations francophones qui le souhaitent peuvent ainsi approfondir leurs connaissances sur ce sujet.
Vous serez ainsi en mesure de tester la mise en œuvre d’un résolveur DoT ou DoH mais également de vérifier son bon fonctionnement au regard des standards grâce au logiciel libre développé par l’Afnic (RFC 7858 pour DoT et RFC 8484 pour DoH).
L’Afnic, attachée à sa mission de transfert d’expertise via le partage et la diffusion des connaissances, espère contribuer à une meilleure compréhension de ces évolutions et leur adoption par le plus grand nombre d’opérateurs de résolveurs, qui aujourd’hui représentent des acteurs importants pour la diversité et la résilience de l’internet.
Les ressources mises à disposition sont les suivantes :
La vidéo du wébinaire
Le tutoriel « Créez votre propre résolveur DoT/Dot » et disponible depuis le Gitlab d’Afnic Labs
Le logiciel libre développé par l’Afnic permettant de tester la conformité par rapport aux standards, de l’implémentation de résolveurs DoT et DoH.
Nous remercions tout particulièrement Stéphane Bortzmeyer et Alexandre Pion pour l’ensemble de ces travaux.
]]>Vous gérez un résolveur DNS qui promet de protéger la vie privée des utilisateurs et utilisatrices ? Alors, vous serez certainement intéressé par ce nouveau RFC qui rassemble les bonnes pratiques en matière de gestion d'un tel résolveur, et explique comment documenter la politique du résolveur, les choix effectués. On y trouve une bonne analyse des questions de sécurité, une discussion de ce qui doit être dans une politique, une analyse comparée des politiques, et même un exemple de politique.
Depuis la publication du RFC 7626, les risques pour la vie privée posés par l'utilisation du DNS sont bien connus. Par exemple, un de ces risques est que le trafic DNS entre une machine terminale et le résolveur est en clair et peut donc trivialement être écouté, ce qui est d'autant plus gênant que ce trafic inclut toutes les informations (il n'y a pas de minimisation possible de la question, par exemple). Un autre risque est que le gérant du résolveur voit forcément tout le trafic, même si on chiffre le trafic entre la machine terminale et lui. Il peut abuser de cette confiance qu'on lui fait. Une des solutions possibles face à ces risques est d'utiliser, non pas le résolveur annoncé par le réseau d'accès à l'Internet mais un résolveur extérieur, à qui vous faites confiance, et avec qui vous communiquez de manière chiffrée. De tels résolveurs existent. Certains sont publics (accessibles à tous), gérés par des GAFA comme Cloudflare (avec son résolveur 1.1.1.1) ou gérés par des associations ou bien des individus (vous trouverez une liste partielle à la fin du README de ce logiciel). D'autres de ces résolveurs sont réservés à tel ou tel groupe ou organisation.
Le problème pour l'utilisateur est celui du choix : lequel prendre ? Pour cela, il faut déjà que ceux et celles qui gèrent le résolveur aient documenté leurs pratiques et qu'on leur fasse confiance pour respecter leurs promesses. C'est l'un des buts de ce RFC : fournir un cadre général de description des pratiques d'un résolveur « vie privée », pour faciliter la tâche des rédacteurs et rédactrices de ces documents, dans l'esprit du RFC 6841, qui faisait la même chose pour DNSSEC. Notre RFC n'impose pas une politique particulière, il décrit juste les choix possibles, et ce qu'il ne faut pas oublier de mettre dans son RPS, son Recursive operator Privacy Statement.
— Permalien
Les 1 et 2 septembre 2020, plusieurs FAI (Fournisseurs d’Accès à l’Internet) français, dont SFR et Bouygues, ont été « en panne », problème qui a été largement commenté dans les médias. En fait, leurs résolveurs DNS étaient hors-service, et il semble bien que c’était suite à une attaque menée contre ces résolveurs. Quelles leçons en tirer ?
https://www.cert.ssi.gouv.fr/actualite/CERTFR-2020-ACT-006/
— Permalien
Le 11 mai 2017, c'était la première édition de mon cours DNS de trois heures au CNAM. Pour l'anecdote, c'était dans le bâtiment où il y avait eu la première connexion UUCP/Usenet, et le premier serveur HTTP public, en France. https://www.bortzmeyer.org/files/cours-dns-cnam-SHOW.pdf
— Permalien
This site is the home of a collaborative open project to promote, implement and deploy DNS Privacy. The goals of this project include:
Current contributors to this project include Sinodun IT, NLnet Labs, SalesForce and No Mountain Software.
]]>Google and a few other companies provide open dns resolvers to the people around the globe. Unfortunately it may happen that the resolver was hijacked and used for different purposes, such as redirecting to malicious pages or to block certain addresses (censorship). Our goal is to identify hijacked resolvers by analyzing their fingerprints, in order to increase safety of Internet users. To do that, we utilize data collected via RIPE Atlas (atlas.ripe.net). Our solution to the problem is based on observing characteristic features in replies to DNS queries. A hijacked server will likely run different software than the legitimate server, thus it should be possible to spot some small differences in server behavior. We build “fingerprints” of recursive DNS servers, or “feature vectors”. Next, we use machine learning algorithms to train computer to be able to discern between a legitimate server and a hijacked one. https://github.com/recdnsfp/recdnsfp.github.io
— Permalien
Lorsqu'un client DNS parle à un résolveur, il pose une question et obtient une réponse. Avant DNSSEC, ce mode de fonctionnement simple était souvent satisfaisant. Mais, avec DNSSEC, il est beaucoup plus fréquent de devoir faire plusieurs requêtes pour obtenir toute l'information nécessaire pour valider les réponses. (Il faut les clés de toutes les zones situées entre la racine et la zone visée.) Cela coûtait cher en latence. Cette extension EDNS expérimentale permet au client DNS de demander au résolveur de chercher et de renvoyer toutes les réponses d'un coup.
Cette extension est particulièrement utile pour le cas de machines terminales hébergeant leur propre résolveur validant (ce qui est la meilleure configuration, question confiance et sécurité). Ce n'est donc pas un hasard si l'auteur du RFC travaille chez Red Hat, système qui est livré par défaut avec une telle configuration. Mais, lorsqu'un tel résolveur validant veut vérifier les informations obtenues sur foo.bar.example, il devra (en supposant qu'il y a une zone par composant du nom de domaine) obtenir la délégation sécurisée de example (dig @la-racine DS example), la clé de example (dig @ns-example DNSKEY example), la délégation sécurisée de bar.example, etc (la clé de la racine, elle, est en dur dans le résolveur, il faut bien partir de quelque part). À faire séquentiellement, cela serait beaucoup de requêtes, donc du temps passé à attendre les réponses. Sur des liens à latence élevée (ce qui arrive souvent aux machines terminales), cela peut être pénible, même si le cache DNS aidera, pour les requêtes suivantes.
— Permalien
The DNS is normally a relatively open protocol that smears its data (which is your data and mine too!) far and wide. Little wonder that the DNS is used in many ways, not just as a mundane name resolution protocol, but as a data channel for surveillance and as a common means of implementing various forms of content access control. But all this is poised to change. Now that the Snowden files have sensitized us to the level of such activities, we have become acutely aware that many of our tools are just way too trusting, way too chatty, and way too easily subverted. First and foremost in this collection of vulnerable tools is the Domain Name System.
— Permalien
Traditionnellement, les requêtes DNS voyageaient sur le réseau en clair, visibles par tous. Ce n'est évidemment plus acceptable, notamment depuis les révélations de Snowden, et ce RFC normalise donc un mécanisme qui permet de chiffrer les requêtes DNS pour en assurer la confidentialité vis-à-vis d'un éventuel surveillant.
— Permalien
DNS Diagnostics and Performance Measurement Tools
Ever been wondering if your ISP is hijacking your DNS traffic? Ever observed any misbehavior with your DNS responses? Ever been redirected to wrong address and suspected something is wrong with your DNS? Here we have a set of tools to perform basic audits on your DNS requests and responses to make sure your DNS is working as you expect.
You can measure the response time of any given DNS server for arbitrary requests using dnsping. Just like traditional ping utility, it gives you similar functionality for DNS requests.
You can also trace the path your DNS request takes to destination to make sure it is not being redirected or hijacked. This can be done by comparing different DNS queries being sent to the same DNS server using dnstraceroute and observe if there is any difference between the path.
dnseval evaluates multiple DNS resolvers and helps you choose the best DNS server for your network. While it is highly recommended to use your own DNS resolver and never trust any third-party DNS server, but in case you need to choose the best DNS forwarder for your network, dnseval lets you compare different DNS servers from performance (latency) and reliability (loss) point of view.
— Permalien
The service Sci-Hub is a great help for the scientists, allowing them to access to a lot of scientific papers that were before locked behind paywalls. The publishing companies keep trying to censor Sci-Hub and block access to this service, for instance by taking down domain names like it happened a few days ago with sci-hub.io. If you control your DNS resolver, you can easily restore access.
Sci-Hub's domain sci-hub.io was recently taken down. There are several ways to still use Sci-Hub, such as "domain hopping" (using another TLD such as sci-hub.bz) or using Tor (the address is scihub22266oqcxt.onion). But there is one which does not seem to have been publically documented yet.
For the rest of the article, we will rely on a local DNS resolver. ("local" does not imply it is on your own machine: it may be on the local network. The important point is that you can change its configuration.) A local resolver is a great tool against DNS censorship. By default, it does not see Sci-Hub domains (NXDOMAIN means "No Such Domain")
— Permalien
Une tribune sensationnaliste dans le Monde le 6 mai prétendait que « Google [avait] changé l'Internet » et portait une accusation précise : le navigateur Google Chrome utiliserait une racine DNS spécifique à Google. Passons sur le fond politique de l'article, est-ce qu'au moins les faits allégués sont exacts ?
]]>“One World, One Internet, One Namespace” is the essence for the success of today’s Internet. The top level of the unique identifier system, the DNS root system, has been operational for 25+ years. It is pivot to make the current Internet useful. So it is considered somewhat ossified for stability reasons. It is hard to test and implement new ideas evolving to a more advanced level to counter challenges like IPv6-only operation, DNSSEC key/algorithm rollover, scaling issues, etc. In order to make the test more practical, it is also necessary to involve users’ environment which is highly diversified, to study the effect of the changes in question.
To benefit the Internet development as a whole, the proposal of Yeti Project is formed to build a parallel experimental live IPv6 DNS root system to discover the limits of DNS root name service and deliver useful technical output. Possible research agenda will be explored on this testbed covering several aspects but not limited to:
IPv6-only operation
DNSSEC key rollover
Renumbering issues
Scalability issues
Multiple zone file signers
]]>A buffer overflow error in GNU libc DNS stub resolver code was announced last week as CVE-2015-7547. While it doesn't have any nickname yet (last year's Ghost was more catchy), it is potentially disastrous as it affects any platform with recent GNU libc—CPEs, load balancers, servers and personal computers alike. The big question is: how exploitable is it in the real world?
— Permalien
A dramatic increase in DNS reflection/amplification DDoS attacks abusing Domain Name System Security Extension (DNSSEC) configured domains have been observed in the past few months, according to a security bulletin released by Akamai’s Security Intelligence Response Team (SIRT). Since the beginning of November 2015, Akamai SIRT reports to have observed the domain "leveraged to launch DDoS attacks against customers in multiple verticals over the same time period, and it is most likely the work of attackers making use of a DDoS-for-Hire service that uses purchased VPS services, public proxies, a classic botnet and basic attack types such as DNS reflection attacks, SYN floods, UDP floods, SSDP floods, NTP floods, ICMP floods and even HTTP GET floods."
— Permalien
If you’re involved in the Internet governance world, you likely subscribe to any number of mailing lists. Email inboxes fill daily with discussions of a wide variety of topics in the ecosystem, from ICANN accountability to marketing to Internet infrastructure. Following these important discussions can get - with apologies to the brilliant folks posting there - a little tedious. However, every now and then a real gem is posted.
— Permalien
La norme de vérification Sender Policy Framework (SPF) permet de vérifier qu'un email est bien envoyé d'un serveur gérant le nom de domaine en question. Ce mémo aide à la mise en place d'un enregistrement DNS de type TXT pour le SPF.
— Permalien
Another DNS-zone serial number updater.
Usage
By default, each time you save a bindzone file, the script will look for the DNS serial number and update it. You can also update it without saving the file by invoking the :DNSSerialUpdate function.
Patterns
In order to be detected, the DNS serial number must match one the following pattern:
YYYYMMDDXX ; serial
YYYY is the year (4 digits, must start by either 19 or 2);
MM is the month (2 digits);
DD is the day (2 digits);
XX is any non-negative number (1 or more digits);
the word serial is not case-sensitive;
there can be any number of blanks on each sides of the semicolon.
SSSSSSSSSS ; serial
SSSSSSSSSS is the UNIX tiemstamp (10 digits, must start by 1);
the word serial is not case-sensitive;
there can be any number of blanks on each sides of the semicolon.
XX ; serial
XX is any non-negative number (1 or more digits);
the word serial is not case-sensitive;
there can be any number of blanks on each sides of the semicolon.
According to those patterns, only dates between 1900 and 2999 will be detected; however this should not be a problem at all. Most importantly, only timestamps between September 9 2001 and March 17 2030 will be detected.
— Permalien
The author hesitated for a long time before publishing this article, because there are strong ethical issues. Documenting the effects of censorship can be seen as helping censors. For instance, if measurements show that censorship is very limited in practice, it may motivate some authorities to increase the pressure and its negative consequences. But I believe that censors are already better informed than the average citizen and that it is necessary to have factual information in order to have an informed debate in democracies.
Another big ethics issue concerns the measurements themselves. Is there a risk of endangering people who host a probe by doing DNS lookups for illegal/forbidden/questionable things (for instance DNS lookup for a porn site from a probe in Iran)? Today, the DNS is typically "under the radar" for most surveillance activities. Doing an HTTP request for an illegal site attracts attention to you in some countries (and it is one of the reasons why RIPE Atlas probes do not perform HTTP queries for arbitrary URLs), but it does not seem to be the case (yet) for DNS requests. (See RFC 7626, "DNS Privacy Considerations".)
— Permalien
create an "nsupdate" script from DNS zone file differences
The nsdiff program examines the old and new versions of a DNS zone, and outputs the differences as a script for use by BIND's nsupdate program. It provides a bridge between static zone files and dynamic updates.
The nspatch script is a wrapper around nsdiff | nsupdate
that checks and reports errors in a manner suitable for running from cron.
The nsvi script makes it easy to edit a dynamic zone.
If you use BIND 9.7 or 9.8, you can use nsdiff as an alternative to the DNSSEC inline-signing feature which appeared in BIND 9.9. The server updates the DNSSEC records dynamically, but you can continue to manage the unsigned static zone file as before and use nsdiff | nsupdate
to push changes to the server.
There are other situations where you have a zone which is partly dynamic and partly static, for example, a reverse DNS zone mostly updated by a DHCP server, which also has a few static entries. You can use nsdiff to update the static part of the zone.
— Permalien
cas intéressant cité par Phil Mayers sur la liste des utilisateurs de BIND va me permettre, cher lecteur, de t'instruire sur la différence entre nom de domaine et nom de machine.
La question originale était de savoir pourquoi on pouvait faire une résolution DNS (par exemple avec dig) de nexistesurementpas.um.outlook.com alors que les commandes comme ping ne pouvaient pas utiliser ce nom :
% dig +short nexistesurementpas.um.outlook.com
*.um.outlook.com.glbdns2.microsoft.com.
wildcard-emeasouth.um.outlook.com.
157.55.9.252
On récupère bien une adresse IP (c'est pareil avec d'autres outils DNS comme host) mais :
% ping nexistesurementpas.um.outlook.com
ping: unknown host nexistesurementpas.um.outlook.com
Mais, alors, pourquoi est-ce que ping prétend que ce nom n'existe pas ? (Le problème n'est pas spécifique à ping, d'autres commandes comme telnet font le même diagnostic.)
L'explication est qu'il existe une différence entre les noms de domaine (domain names) et les noms de machines (host names). Les premiers permettent à peu près tous les caractères possibles (cf. RFC 2181, section 11, et regardez le nom &-funny-%-syntax-$.bortzmeyer.org pour s'en convaincre). Les seconds obéissent à une syntaxe bien plus restrictive, documentée dans le RFC 1123, section 2.1. En gros, un nom de machine est restreint à LDH (Letters, Digits and Hyphen). C'est pour cela que je peux résoudre le nom rigolo indiqué plus haut :
% dig +short +nodnssec '&-funny-%-syntax-$.bortzmeyer.org'
www.bortzmeyer.org.
204.62.14.153
Mais que je ne peux pas l'utiliser :
% ping '&-funny-%-syntax-$.bortzmeyer.org'
ping: unknown host &-funny-%-syntax-$.bortzmeyer.org
— Permalien
DNSdumpster.com is a FREE domain research tool that can discover hosts related to a domain. Finding visible hosts from the attackers perspective is an important part of the security assessment process.
D'autres outils DNS:
https://github.com/tomsteele/blacksheepwall
https://github.com/jhaddix/domain
https://code.google.com/p/gxfr/
http://trac.assembla.com/fierce
https://pentest-tools.com/information-gathering/find-subdomains-of-domain
https://code.google.com/p/dnsmap/
https://github.com/guelfoweb/knock
https://github.com/darkoperator/dnsrecon
— Permalien
nslookup is badly designed. It's a very poor tool for several reasons. It has been widely acknowledged for several years that it is a bad tool. Even the company that writes BIND states that nslookup is deprecated and may be removed from future releases of BIND. (Even though your particular operating system vendor may have packaged it separately, nslookup is in fact a diagnostic tool that is a part of the BIND package.)
Stop using nslookup right now. Start using better, less flawed, tools instead. Almost every DNS server software package comes bundled with tools to manually query the DNS for diagnostic purposes. Use the tools that came with the package that you have.
Even BIND itself comes with better tools. The company that writes BIND has in fact rewritten nslookup for BIND version 9.x . It no longer contains one of the daft design flaws. But it also no longer contains some of the functionality of the original tool, and prints a prominent warning message every time that it is invoked stating a BIND-centric version of what this page recommends — i.e. that one should stop using nslookup in favour of host and dig.
]]>Zonemaster is a program that was designed to help people check, measure and hopefully also understand the workings of the DNS (Domain Name System). It consists of three basic modules: - Engine (a test framework that supports all functionality to perform DNS tests) - The CLI interface and - The web interface
When a domain (such as "zonemaster.net") is submitted to Zonemaster interfaces (CLI or Web) it will investigate the domain’s general health by traversing the DNS from root (.) to the TLD (Top Level Domain, like .net) to eventually the nameserver(s) that holds the information about the specified domain (zonemaster.net). The different sanity checks conducted by the zonemaster tool is documented in the Test Requirements document
— Permalien
« Ce[tte] RFC est en fait à la croisée de deux activités. L'une d'elles consiste à documenter les problèmes de vie privée, souvent ignorés jusqu'à présent dans les RFC. Cette activité est symbolisée par le RFC 6973 (…). Et la seconde activité qui a donné naissance à ce RFC est le projet d'améliorer effectivement la protection de la vie privée des utilisateurs du DNS, en marchant sur deux jambes : minimiser les données envoyées (…) et les rendre plus résistantes à l'écoute, via le chiffrement. ».
— Permalien
The mapping of IPv6 reverse DNS zones must be made on nibble boundaries. That means, that if your official IPv6 address block does not have a prefix length divisible by 4, you have to split it in multiple reverse zones. GestióIP's free online subnet calculator includes a reverse zone generator which permits to easily map a given IPv6 address block in the corresponding reverse zones. The tool can be used for networks on nibble boundaries as well as networks on non-nibble boundaries.
— Permalien
Les serveurs DNS de cedexis.net ne semblent pas tourner sous une "popular authoritative DNS implementations"
— Permalien
Après avoir écrit ce billet http://signal.eu.org/blog/2015/04/18/pourquoi-la-loi-renseignement-instaure-une-surveillance-de-masse/ sur la surveillance de masse comparée aux écoutes téléphoniques classiques, je ressens la nécessité de revenir en détail sur le communiqué de eu.org http://eu.org/fr/loirens.html , en particulier l’extrait ci-dessous sur ses motifs :
En effet, cette loi — dont le texte http://www.assemblee-nationale.fr/14/ta-pdf/2697-p.pdf doit encore être voté définitivement à l’assemblée le 5 mai 2015, puis au sénat — instaure une surveillance légale systématique du trafic Internet par les services de renseignement français, dans des conditions d’opacité complète, sous la seule responsabilité de l’exécutif, sans contre-pouvoir.
Ce trafic inclut notamment des requêtes de résolution DNS des utilisateurs accédant aux 28 000 domaines délégués par Eu.org.
Eu.org ne peut moralement laisser en toute connaissance de cause le trafic de ses utilisateurs — incluant des sites d’activisme politique dans le monde entier — et, par ricochet, le trafic d’accès de leurs propres utilisateurs, exposé à de telles écoutes.
Ces éléments méritent d’être développés car ils ne touchent pas tout à fait aux mêmes sujets que l’hébergement web proprement dit. Ils concernent :
le trafic DNS, et la question de son chiffrement
les méta-données
la localisation des serveurs EU.org
Elles sont au cœur du projet de loi sur le renseignement.
[...]
Les spécificités de la loi renseignement française
La plupart des pays démocratiques pratiquent des écoutes, mais ce sont généralement des écoutes légales ciblées, sur le modèle déjà évoqué des écoutes téléphoniques, et encadrées par une décision judiciaire préalable.
En aucun cas — dans les pays démocratiques — il ne s’agit, comme le gouvernement souhaite le faire en France, d’écoutes légales et sans autorisation judiciaire a priori et systématiques (en masse), et même destinées à détecter des comportements parfaitement légaux mais “déviants”.
Je parle bien ici de la loi et non des décrets et mises en œuvre techniques, qui promettent à ce jour un cadre plus restreint que ne le permettra la loi elle-même, mais ne disent rien de mesures encore plus intrusives qui pourraient être déployées ultérieurement sans nécessité de retour au parlement.
Il peut exister parfois, n’importe où, et comme l’affaire Snowden/NSA l’a montré, des écoutes illégales ou découlant d’une interprétation très extensive de la loi, contre lesquelles il est difficile de se prémunir.
Mais mieux vaut, à mon avis, risquer ce genre d’écoute dans un pays où elles sont explicitement illégales que dans un pays où elles sont explicitement légales.
— Permalien
Comment indiquer qu'un domaine ne reçoit jamais de courrier ? Jusqu'à présent, il n'existait pas de mécanisme standard, permettant d'indiquer aux clients de ne pas perdre de temps à essayer d'écrire. Ce nouveau RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l'enregistrement MX.
— Permalien
This is the Yeti DNS Project, an experimental testbed network of DNS root name servers.
— Permalien
Monitoring programs over the Internet? Should we be afraid of it, what impact on the average citizen?
============================================
Des choses intéressantes, mais du bon gras aussi, des pseudo-analyses politiques discutables etc
— Permalien
Pour les Livebox, les adresses des serveurs DNS sont automatiquement configurées à la connexion et ne peuvent pas être modifiées par l'utilisateur.
Pour les clients qui n'utilisent pas de Livebox mais un modem xDSL Orange conseille d'utiliser les serveurs DNS : 80.10.246.2 (primaire) et 80.10.246.129 (secondaire).
— Permalien
L'Afnic travaille, notamment au sein du CENTR et de l'IETF, à améliorer la protection de la vie privée pour les utiisateurs du DNS. Le protocole DNS est un élément peu connu mais crucial de l'infrastructure de l'Internet. Aujourd'hui où les préoccupations sur la vie privée ont pris beaucoup d'ampleur, il est donc normal de se pencher sur la question « DNS et vie privée ». Tout utilisateur de l'Internet se sert abondamment du DNS, même s'il ne s'en rend pas compte, et même s'il ignore tout du DNS et des noms de domaine. À chaque fois que cet utilisateur envoie un message, qu'il clique sur un lien hypertexte, que son ordinateur met à jour ses logiciels, il y a une (et souvent bien plus d'une) requête DNS. Mais, autant les questions de vie privée liées au protocole du Web, HTTP, ont été longuement discutées (qu'on songe aux débats comme « faut-il une autorisation explicite de l'utilisateur pour placer des cookies ? » ou bien « l'adresse IP est-elle une donnée nominative ? »), autant celles liées au DNS ont été d'abord négligées, puis ensuite étudiées uniquement dans un petit cercle, essentiellement à l'IETF. La sortie prochaine du RFC « DNS privacy considerations » sera la première manifestation officielle de cet intérêt.
— Permalien
A blog post has created some attention online through its extremely negative attitude to DNSSEC. Through the years, I have come in contact with many arguments against DNSSEC that suggest that anyone who is critical has not managed to or wanted to familiarize themselves with what DNSSEC is and does. We have received many questions concerning the article, so I feel it’s appropriate to respond to the criticism.
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://www.theregister.co.uk/2015/03/18/is_the_dns_security_protocol_a_waste_of_everyones_time_and_money/
— Permalien
Le DNS est un système décentralisé, mais arborescent : toute zone (à part la racine) dépend d'une zone parente, qui doit notamment indiquer les serveurs de noms de ses zones filles. En théorie, l'information dans la zone parente et celle dans la zone fille doivent parfaitement coïncider mais, en pratique, des différences apparaissent souvent, et elles ont parfois des conséquences ennuyeuses, pouvant aller jusqu'à mettre en danger le bon fonctionnement de la zone. La principale raison de cette « désynchronisation » est qu'il n'existait aucun mécanisme standard par lequel le gestionnaire d'une zone fille pouvait transmettre à la zone parente les données à distribuer. C'est ce manque que comble notre tout nouveau RFC, avec l'introduction des enregistrements DNS de type CSYNC (Child SYNChronization).
— Permalien
Vous avez peut-être (mais sans doute pas) entendu parler des lois LOPPSI et Terrorisme (cette dernière votée fin 2014) et de leur décret d’application (sorti en début d’année 2015).
Ces lois permettent à la police, sans intervention d’un juge et sans aucune transparence, de bloquer, avec l’aide de certains fournisseurs d’accès (pour l’instant, seuls les 4 plus gros en France, à savoir Orange, Free, SFR-Numéricâble et Bouygues) un site Internet faisant l’apologie du terrorisme.
Pour ne pas accabler le gouvernement, il faut savoir que le PS a combattu le blocage sans juge avec succès lorsqu’il était dans l’opposition, pendant le mandat Sarkozy, avant de le voter quasi unanimement en 2014, avec l’aide du PCF (qui voulait en fait voter contre mais ne s’en est aperçu qu’après).
https://www.bortzmeyer.org/censure-francaise.html
https://www.libre-parcours.net/post/censure-administrative-sites/
http://www.numerama.com/magazine/32492-un-site-d-information-islamique-censure-en-france-sans-decision-judiciaire.html
http://www.nextinpact.com/news/93457-islamic-news-info-bloque-sans-juge-pour-apologie-ou-provocation-au-terrorisme.htm
http://esquisses.clochix.net/2015/03/16/censure/#light
http://ecrans.liberation.fr/ecrans/2015/03/16/cinq-sites-web-projihad-bloques-de-l-interieur_1222042
https://firstlook.org/theintercept/2015/03/17/whats-scarier-terrorism-governments-unilaterally-blocking-websites-name/
https://edri.org/france-censorship-without-judicial-oversight/
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000030195477&dateTexte=&categorieLien=id
https://www.laquadrature.net/fr/la-france-persiste-et-signe-la-censure-administrative-du-net
http://www.la-croix.com/Culture/Nouvelles-technologies/Premiers-blocages-de-sites-Internet-pour-apologie-du-terrorisme-en-France-2015-03-16-1291766
http://www.lepoint.fr/societe/terrorisme-la-france-bloque-pour-la-premiere-fois-un-site-web-16-03-2015-1913186_23.php
http://ecrans.liberation.fr/ecrans/2015/03/16/cinq-sites-web-projihad-bloques-de-l-interieur_1222042
http://reflets.info/putain-de-dns-menteurs/
http://reflets.info/censure-administrative-du-net-pour-parfaire-le-decor/
http://www.numerama.com/magazine/32516-moi-censure-par-la-france-pour-mes-opinions-politiques.html
http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/6573/show/le-conseil-scientifique-de-l-afnic-partage-sur-le-filtrage-internet-par-dns.html
http://www.afnic.fr/medias/documents/conseilscientifique/CS-consequences-du-filtrage-internet-par-le-DNS.pdf
— Permalien
This repository is an attempt to answer the age old interview question "What happens when you type google.com into your browser's address box and press enter?"
Except instead of the usual story, we're going to try to answer this question in as much detail as possible. No skipping out on anything.
— Permalien
https://bugzilla.mozilla.org/show_bug.cgi?id=1093983
https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c14
https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c16
https://lists.dns-oarc.net/pipermail/dns-operations/2015-February/012886.html
— Permalien
Implementations of the Transport Layer Security (TLS) protocol must handle a variety of protocol versions and extensions, authentication modes and key exchange methods, where each combination may prescribe a different message sequence between the client and the server. We address the problem of designing a robust composite state machine that can correctly multiplex between these different protocol modes.
We systematically test popular open-source TLS implementations for state machine bugs and discover several new critical security vulnerabilities that have lain hidden in these libraries for years. We call these collection of vulnerabilities SMACK: State Machine Attacks on TLS.
This page presents exploits and disclosure information related to these attacks. For a technical overview of the TLS state machine and our protocol fuzzing methodology, please refer to our research paper (to appear at IEEE Security & Privacy 2015).
Threat Model
All the attacks on this page assume a network adversary (i.e. a man-in-the-middle) to tamper with TLS handshake messages. The typical scenario to mount such attacks is by tampering with the Domain Name System (DNS), for example via DNS rebinding or domain name seizure.
— Permalien
La censure d'internet peut perturber l'accès à des logiciels, au savoir, à la culture et à l'information. Elle peut être mise en place par le fournisseur d'accès à internet (FAI) pour des raisons économiques ou sur injonction d'une autorité.
Pour bloquer un site, l'intermédiaire technique (le FAI) envoie des données mensongères en réponse aux requêtes de l'internaute. C'est une atteinte à la neutralité du réseau.
Malheureusement, un blocage déborde couramment sur des sites sans rapport avec la cible : on appelle cela le surblocage. Les sites bloqués peuvent aussi souffrir d'un long délai administratif de déblocage après suppression du contenu litigieux.
Autant de cas où accéder à ces ressources malgré un intermédiaire peu coopératif (ou zélé, selon le point de vue) peut être nécessaire. Heureusement, quelques minutes suffisent souvent pour cela. Voici deux méthodes.
— Permalien
Je viens de finaliser la première version de pdns-console, un outil en ligne de commande qui permet de gérer un serveur PowerDNS : un puissant serveur DNS qui repose sur des bases de données comme MySQL. La particularité de pdns-console est qu'il permet de versionner ses zones.
— Permalien
As a person responsible for operating various DNS services, performance has always been an area of interest for me. One performance metric on which we all focus is: How fast is my service? Let me be more specific here, by “fast” we mean that when a DNS query is made, an answer is provided quickly to a DNS client. We call this query resolution time. We are going to be running several tests in upcoming months that focus on DNS performance. This first analysis is about the performance of DNS root servers.
— Permalien
Les serveurs de noms de domaine (DNS) sont actuellement incontournables pour utiliser Internet.
Chaque fois que vous accédez à un service sur Internet avec une adresse qui ressemble à www.example.com ou foo.example.com ou encore example.com, vous utilisez un nom de domaine. C’est également le cas lorsque vous cliquez sur un lien, sur une page web.
Pour accéder à la destination demandée, les ordinateurs ont besoin de convertir ce nom de domaine (facile à retenir) en une adresse IP (beaucoup moins facile à retenir). Ce processus est totalement transparent pour vous, et vous avez rarement l’occasion de voir ces adresses IP, qui ressemblent à 2001:db8::1 ou encore 203.0.113.1. Ce sont les serveurs de noms de domaine — aussi appelés serveurs DNS — qui aident systématiquement votre ordinateur à traduire les noms de domaine qu’il rencontre, en adresses IP.
En fonction de l’endroit où vous connectez votre ordinateur à Internet, votre ordinateur récupérera automatiquement une adresse de serveur de noms de domaine, qu’il utilisera durant tout le temps de votre connexion. En général, c’est le fournisseur d’accès à Internet (FAI) qui décide du serveur qui sera utilisé, en le transmettant à votre ordinateur lorsqu’il demande à se connecter à la box Internet ou au point d’accès Wifi.
Ce mécanisme permet à votre FAI (ou l’administrateur inconnu du point d’accès Wifi) de facilement censurer votre accès à Internet. S’il ne souhaite pas que vous accédiez à un site web en particulier par exemple, il suffit qu’il indique à son serveur de noms de domaine de répondre à votre ordinateur qu’il n’y a pas d’adresse IP correspondant au nom de domaine qui est associé. Vous aurez alors l’impression que le site web est purement inaccessible. On appelle ça un serveur DNS menteur, et c’est probablement la principale méthode de censure qui est utilisée actuellement.
Chaque fois que votre ordinateur demande à ce serveur de noms de domaine de lui fournir l’adresse IP correspondant à un nom de domaine, il indique également à votre FAI (ou l’administrateur inconnu du point d’accès Wifi) que vous consultez le service Internet qui y est associé. Si vous tapez youporn.com dans votre navigateur chaque vendredi soir à 22h, ou que vous cliquez sur un lien qui y mène, votre FAI est immédiatement au courant que vous avez pour habitude de vous astiquer ou vous frotter en soirée chaque fin de semaine. Selon le type de site que vous visitez, il connaît aussi vos orientations. Que ça soit sexuel, politique, religieux ou tout autre préférence que vous n’avez pas à partager avec une entreprise opaque qui ne vous donne aucune garantie vis-à-vis du respect de votre vie privée (ou vous promet au contraire, dans ses conditions générales d’utilisation, d’en faire usage dans le cadre de revente à des partenaires commerciaux inconnus).
Pour contrer cette méthode censure et de surveillance, vous pouvez imposer à votre ordinateur d’utiliser un serveur de noms de domaine différent de celui qu’il va récupérer par défaut. Il faut évidemment que ce soit un tiers de confiance. Il est donc hors de question, par exemple, d’utiliser le serveur de noms de domaine de Google, qui est public, mais qui n’est absolument pas de confiance vis-à-vis du respect de vos libertés et de votre intimité.
Lorraine Data Network fait partie de ces associations qui ont une charte très claire, concernant le traitement des données qu’elle peut avoir à manipuler. Les statuts de l’association indiquent noir sur blanc qu’elle « s’engage à un respect le plus total concernant la confidentialité des données qu’elle héberge ou fait transiter (dans le cadre strict des lois en vigueur auxquelles elle est soumise) notamment en s’interdisant formellement de consulter (manuellement ou automatiquement) tout donnée ou métadonnée qui ne serait pas strictement nécessaire au fonctionnement des services ».
Ainsi, vous pouvez demander à votre système d’exploitation (GNU/Linux, Windows, Mac, etc.) d’utiliser systématiquement ces deux adresses de serveur de noms de domaine, éventuellement en vous faisant aider par un ami qui saurait mieux le faire que vous :
2001:913::8
80.67.188.188
Vous pouvez également utiliser les adresses des serveurs de l’association FDN, qui sont également de confiance, en complément :
2001:910:800::12
80.67.169.12
Si vous utilisez un réseau particulièrement censuré, des méthodes complémentaires, qui demandent un peu plus de travail au niveau technique, sont proposées par LDN.
Bonne navigation !
— Permalien
Pour ceux qui ne serait pas forcément au courant, le DNS est à la base de tout l’Internet tel qu’on le connaît aujourd’hui.Sans lui nous serions contraint d’apprendre par cœur les adresses IP des serveurs qu’on souhaite consulter. Et forcément 62.210.124.124 ou pire 2001:bc8:3f23:100::1 c’est beaucoup moins sexy que imirhil.fr…
https://gist.github.com/aeris/1a1ba71264c9c1e49e03
— Permalien
La censure de Pékin sur Internet a récemment eu pour effet de détourner les connexions vers des sites tiers, qui s’en trouvent saturés.
Quel est le point commun entre une société de design numérique de Caroline du Nord, un night-club californien , un syndicat français et une association de défense des libertés sur Internet ? A priori, pas grand-chose. Pourtant Iconfactory, DNA Lounge, la CGT et la Quadrature du Net ont subi, ces dernières semaines, le même phénomène : un trafic anormalement élevé sur leurs serveurs web - jusqu’à 11 000 connexions par seconde pour la CGT, 13 000 pour Iconfactory - pendant quelques heures… Le symptôme habituel d’une attaque «par déni de service distribué», c’est-à-dire par saturation sous un afflux de connexions (1).
— Permalien
No Censorship. No Bullshit. Just DNS.
— Permalien
Ils demandaient donc aux quatre FAI de mettre en œuvre « toutes mesures propres à empêcher l'accès, à partir du territoire français et/ou par leurs abonnés à raison d'un contrat souscrit sur ce territoire, par tout moyen efficace et notamment par le blocage des noms de domaines ».
— Permalien
Le ministère de l’Intérieur a publié ce matin au Journal officiel le décret sur le blocage administratif des sites faisant l’apologie ou provocant au terrorisme et ceux diffusant des contenus pédopornographiques. Une bonne occasion de faire le point sur ce sujet sensible. http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000030195477&dateTexte=&categorieLien=id [...] Que devront faire les FAI ? es fournisseurs d’accès devront bloquer l’accès à ces sites très rapidement, dans les 24 heures et par tous moyens. Les FAI n’auront évidemment pas de marge de manœuvre. Ils ne pourront par exemple pas modifier les éléments de cette liste, « que ce soit par ajout, suppression ou altération » dit le décret. Tous les FAI seront-il impactés ? Non ! Seuls ceux destinataires de la liste noire devront bloquer. Les autres, au parc d'abonnés plus modeste, seront en principe écarté du dispositif.
— Permalien
This is well-known, for many years, that the chinese governement censors the Internet via several means, including DNS lies. For a long time, these DNS lies have been generated by the netwok itself: when a DNS query for a censored name is seen, an active censorship device generates a lie and sends a reply with the wrong IP address. A few weeks ago, there have been a change in this system: the IP addresses returned by the Great FireWall are more often actual addresses used by real machines, which suddently have to sustain a big traffic from China.
This technique have been studied and documented in several papers such as "The Great DNS Wall of China" or "Source code to identify the fake DNS packets from China". Basically, every DNS request in a chinese network, whatever the destination IP address, is examined and, if the qname (Query Name) in it matches a predefined list of censored domains, a fake reply is generated and sent to the requester. The bad consequences of this technique outside of China have been described in articles like "Accidentally Importing Censorship or "China censorship leaks outside Great Firewall via root server": since the censorship system acts whatever the destination IP address is, if one of your DNS packets happen to goes through China, you will be subjected to chinese censorship.
— Permalien