dog is a command-line DNS client.
For documentation on how to use dog, see the website: https://dns.lookup.dog/
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.
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 ?
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
This site is the home of a collaborative open project to promote, implement and deploy DNS Privacy. The goals of this project include:
- Raising awareness of the issue of DNS Privacy
- Empowering users to take advantage of DNS Privacy tools and resources (client applications, DNS Privacy resolvers)
- Evolving the DNS to support DNS Privacy in particular developing new DNS Protocol standards
- Working towards full support for DNS Privacy in a range of Open Source DNS implementations including: getdns, Unbound, NSD, BIND and Knot (Auth and Resolver)
- Co-ordinating deployment of DNS Privacy services and documenting operational practices
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
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.
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.
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.
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.
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")
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?
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."
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.
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.
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.
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".)