KST

18/02/2021

Un drone qui s'adapte selon l'état de l'environnement et peut toute fois décoller en cas de besoin

18/02/2021

15/02/2021

15/02/2021

Now that’s precision engineering - check out this CNC work from Beijing

Via: Jingdiao Group

15/02/2021

26/07/2020

Outils monitoring réseaux......
# # # # # # # # # # # # # # # # # # # # # # #
LISTE DE QUELQUES OUTILS DE # # SURVEILLANCE DU RESEAU # # #
# # # # # # # # # # # # # # # # # # # # # # #
1) NetCrunch
2) Obkio (Solution SaaS)
3) Paessler PRTG
4) SolarWinds Network Performance Monitor
5) WhatsUp Gold 2017
6) Zabbix (open source)
7) Incinga (open source)
8) Datadog (environnements de cloud hybride)
9) ConnectWise Automate
10) Logic Monitor
11) OP5 Monitor
12) Fiddler
13) Splunk
14) Pandora FMS
15) Angry IP Scanner
16) Advanced IP Scanner
17) Capsa free
18) Nagios
19) The Dude
20) OpenNMS
21) NetworkMiner
22) GFI LanGuard
23) NetXMS
24) Total Network Monitor
25) Zenoss Core
26) Microsoft Network Monitor
27) WirelessNetView
28) monitors
29) NMAP
30) NTOP
31) Wireshark
32) NAGIOS CORE
33) Spiceworks
34) Pulseway
35) Observium
36) Monit
37) Dynatrace (Compuware APM)
38) ThousandEyes
39) SevOne
40) AppNeta
41) live-action
42) Vigilo NMS
43) Shinken
44) Cacti (Open sources)
45) Centreon

26/05/2020

une

Il s'agit d'une procédure pas à pas sur la façon de créer une pile LAMP dans Docker. C'était un projet de recherche amusant pour voir comment créer une boîte de développement pour mon travail à l'aide de Docker et Docker Compose (l'outil de Docker pour exécuter une application qui nécessite plusieurs conteneurs).
Considérez les conteneurs Docker comme de minuscules serveurs qui exécutent une seule chose spécifique. Habituellement, dans un serveur, vous auriez une instance avec un tas de programmes (Apache, PHP, MySQL) installés et en cours d'exécution. Dans Docker, chacun de ces programmes est séparé sur son propre petit serveur qui partage les ressources avec les autres conteneurs sur son ordinateur / serveur hôte. Dans ce cas, nous aurions 3 conteneurs
Apache
PHP
MySQL
Cependant pour cet exemple, j'ai combiné les programmes Apache / PHP ensemble. D'après ce que j'ai vu, il n'y a pas de méthode de «docker des meilleures pratiques» et vous pouvez construire les choses de manière différente. C'est donc à vous de décider comment vous voulez construire vos conteneurs (petits serveurs). Gardez à l'esprit que plus votre contenant est petit, mieux c'est. Donc, si vous avez des programmes dont vous n'êtes pas sûr qu'ils devraient être ensemble, suivez mon petit dicton:
En cas de doute, divisez-les.
Les DockerFiles
DockerFiles sont des fichiers que vous pouvez créer une image Docker. Considérez ce fichier comme un script que vous exécuteriez pour configurer votre environnement sur une VirtualBox après avoir installé le système d'exploitation hôte (Ubuntu, CentOS, etc.), puis exporté l'appliance pour que d'autres puissent l'utiliser. Les images Docker sont essentiellement le même concept. Vous créez une image pour votre petit serveur aka conteneur .
DevBox.DockerFile

Commande FROM
La commande FROM indique au fichier docker les images à utiliser comme image de base. Vous ne commencez généralement pas à partir de zéro. Je suis sûr qu'il y a des moments où vous le pouvez, mais ce sont probablement des circonstances assez rares.
Dans le fichier ci-dessus, vous commencez avec une image de base à partir de laquelle travailler. Dans ce cas, nous construisons à partir de la dernière version d'ubuntu.
La syntaxe des images dans Docker
nom_référentiel: nom_tag
Dans cet exemple, son ubuntu: latest . La dernière balise est utilisée dans la plupart des images pour récupérer la version la plus récente de l'image.
Commande ENV
ENV DEBIAN_FRONTEND = non interactif
La ligne ci-dessus vous permet de définir une variable d'environnement dans vos nouvelles images. Ce serait la même chose que de définir une variable d'environnement lorsque SSH est connecté à un serveur. Dans ce cas, cela fait en sorte que lorsque nous installons d'autres logiciels et qu'il y a une invite qui nécessite une intervention de l'utilisateur, elle sera contournée et n'entravera pas l'installation du logiciel. J'avais mon échec de construction d'image sur une extension php qui avait besoin d'une entrée. Cela m'a permis de contourner cela.
Commande RUN
Les commandes RUN sont comme si vous tapiez une commande dans votre fenêtre de terminal. Dans ce fichier, j'installais le noyau php et ses extensions correspondantes.
Commande COPY
La commande COPY copie un fichier d'un répertoire local de votre ordinateur vers le système de fichiers du conteneur. Considérez-la comme une commande scp sur un serveur normal.
Syntaxe de la commande de copie

/path/to/local/file.txt /path/to/container/filepath/file.txt

Commande CMD
Le but principal d'un CMD est de fournir des valeurs par défaut pour un conteneur en cours d'exécution. Dans ce cas, nous voulons lancer apache et l'exécuter au premier plan afin que le conteneur reste persistant et actif. Contrairement à un serveur normal qui fonctionnera 24h / 24 et 7j / 7 jusqu'à sa mise hors tension manuelle, un conteneur se tournera automatiquement une fois qu'il aura fini de fonctionner. En exécutant Apache au premier plan, cela empêche le conteneur de s'éteindre.
Commande EXPOSE
La commande Exposer autorise le port que vous souhaitez ouvrir EN INTERNE , dans le réseau des conteneurs Docker, mais pas sur le réseau extérieur.
MySQL.DockerFile

Construire l'image
Maintenant que nous avons les DockerFiles prêts à l'emploi, nous pouvons construire les images dans un conteneur réel de différentes manières. La façon dont je vais vous montrer est d'utiliser un outil CLI appelé Docker Compose.
Docker Compose vous permet d'écrire un fichier YAML pour faire tourner plusieurs conteneurs à la fois afin que vous n'écriviez pas une tonne de commandes docker dans votre fenêtre de terminal. Vous effectuez également tout ce travail en écrivant un script bash avec les commandes docker, mais l'utilisation de Docker Composer facilite la maintenance du script.
La commande build
Pour exécuter une génération à l'aide de docker-compose (dans le même répertoire de fichiers que votre fichier docker-composer.yml)
construction de docker-compose
sans utiliser aucun autre indicateur, le programme docker-compose recherchera le nom de fichier .yml par défaut de docker-compose.yml. Si vous nommez votre .yml un nom différent, vous

utiliseriez le -f dans la commande

docker-compose -f /path/to/docker-compose.yml/file build
Le docker-compose.yml

Voici une ventilation de ce que fait chaque ligne du fichier YAML

Plus d'informations sur Docker Compose File
Composer la référence de la version 3 du fichier
Référence et directives Ces rubriques décrivent la version 3 du format de fichier Compose. Ceci est la dernière version…
docs.docker.com
Comment allumer les conteneurs
Lorsque vous êtes prêt à démarrer vos conteneurs (et après avoir construit les conteneurs), vous pouvez exécuter la commande (dans le même répertoire de fichiers que votre fichier

docker-compose.yml)
docker-compositeur

Comme la commande ci-dessus lorsque vous créez vos images, vous pouvez également spécifier le nom de votre fichier docker-compose.yml en utilisant l'indicateur -f dans votre commande.........
docker-compose -f /path/to/docker-compose.yml/file build........
Plus d'informations sur Docker Compose
Présentation de Docker Compose
Vous recherchez une référence de fichier Compose? Trouvez la dernière version ici. Compose est un outil pour définir et exécuter…
docs.docker.com
Comment se connecter à un conteneur MySQL avec PHP
Pour vous connecter à une base de données MySQL depuis PHP, vous utilisez simplement le nom des conteneurs dans votre connexion db
Exemple de syntaxe........
mysqli_connect ("container_name_here", "my_user", "my_password", "my_db");
Donc, si nous utilisions le nom de notre conteneur MySQL d'en haut, cela ressemblerait à ceci: (C'est le nom que nous avons défini dans notre fichier docker-compose.yml plus tôt)
mysqli_connect (" devmysql ", "my_user", "my_password", "my_db");.......

Des conseils de dépannage
Problème de connexion à MySQL
Ran into Lost connection to MySQL server at ' reading initial communication packet', erreur système: 0
Cela était dû à une ligne d'adresse de

liaison dans /etc/mysql/mysql/mysql.conf.d/mysqld.cnf

n'autorisant pas les connexions de n'importe où pour le conteneur mysql. Je l'ai commenté et j'ai redémarré les conteneurs et j'ai pu accéder à MySQL avec mon client de base de données (Sequel Pro sur Mac)
Dernières pensées
Tout en installant toutes les dépendances de vos applications Web (php-curl, php-json, etc.) et en vous assurant que votre Apache est en cours d'exécution et que votre conteneur MySQL fonctionne également; vous devriez pouvoir visiter localhost et voir votre système fonctionner. Si vous en avez besoin, vous pouvez toujours pirater votre fichier / etc / hosts pour qu'un point de nom de domaine pointe vers votre hôte local (127.0.0.1). Encore une fois, vous seul savez ce qui doit être défini dans votre environnement pour que votre application fonctionne.
Toutes les choses que vous exécuteriez dans le terminal pour faire fonctionner votre application Web peuvent être placées dans votre DockerFile, de cette façon, elles peuvent être exécutées automatiquement pendant votre processus de construction.
Vous utilisez le fichier docker-compose.yml pour déclencher le démarrage de tous vos conteneurs. Considérez-le comme un script qui allume tous vos serveurs et les configure pour communiquer entre eux.
J'espère que ce didacticiel simple et rapide vous permettra d'exécuter une simple boîte de pile LAMP. De là, vous pouvez faire des tonnes de constructions plus complexes et même pousser votre image personnalisée vers des dépôts publics pour les autres. Consultez Docker Hub pour voir une liste d'images que les gens ont publiées pour que vous puissiez les utiliser.

26/05/2020

une Linux avec Azure CLI Windunix.ml
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

Ce démarrage rapide vous montre comment utiliser l'interface de ligne de commande (CLI) Azure pour déployer une machine virtuelle (VM) Linux dans Azure. La CLI Azure est utilisée pour créer et gérer des ressources Azure à partir de la ligne de commande ou dans des scripts.

Dans ce tutoriel, nous allons installer Ubuntu 16.04 LTS. Pour montrer la VM en action, vous vous connecterez à celle-ci à l'aide de SSH et installerez le serveur Web NGINX.

Si vous n'avez pas d'abonnement Azure, créez un compte gratuit avant de commencer.

Lancez Azure Cloud Shell
Azure Cloud Shell est un shell interactif gratuit que vous pouvez utiliser pour exécuter les étapes de cet article. Il a des outils Azure communs préinstallés et configurés pour être utilisés avec votre compte.

Pour ouvrir Cloud Shell, sélectionnez simplement Try it dans le coin supérieur droit d'un bloc de code. Vous pouvez également ouvrir Cloud Shell dans un onglet de navigateur distinct en accédant à https://shell.azure.com/bash . Sélectionnez Copier pour copier les blocs de code, collez-le dans le Cloud Shell et sélectionnez Entrée pour l'exécuter.

Si vous préférez installer et utiliser la CLI localement, ce démarrage rapide nécessite Azure CLI version 2.0.30 ou ultérieure. Exécutez az --versionpour trouver la version. Si vous devez installer ou mettre à niveau, consultez Installer Azure CLI .

Créer un groupe de ressources
Créez un groupe de ressources avec la commande az group create . Un groupe de ressources Azure est un conteneur logique dans lequel les ressources Azure sont déployées et gérées. L'exemple suivant crée un groupe de ressources nommé myResourceGroup à l' emplacement eastus :

Azure CLI

Copie

Essayez-le:
--------------------------------------------------------------------------
az group create --name myResourceGroup --location eastus
---------------------------------------------------------------------------------
Créer une machine virtuelle
Créez une machine virtuelle avec la commande
**************************
az vm create .
*****************
L'exemple suivant crée une machine virtuelle nommée myVM et ajoute un compte d'utilisateur nommé azureuser . Le --generate-ssh-keysparamètre est utilisé pour générer automatiquement une clé SSH et la placer à l'emplacement de clé par défaut ( ~ / .ssh ). Pour utiliser un jeu de clés spécifique à la place, utilisez l' --ssh-key-valueoption.

Azure CLI

Copie
************************Début***************************************************
Essayez-le
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys
La création de la machine virtuelle et des ressources de support prend quelques minutes. L'exemple de sortie suivant montre que l'opération de création de machine virtuelle a réussi.

Production

Copie
{
"fqdns": "",
"id": "/subscriptions//resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "40.68.254.142",
"resourceGroup": "myResourceGroup"
}
*************************************Fin**********************************************
Notez le vôtre publicIpAddressdans la sortie de votre machine virtuelle. Cette adresse est utilisée pour accéder à la machine virtuelle dans les étapes suivantes.

Ouvrez le port 80 pour le trafic Web
Par défaut, seules les connexions SSH sont ouvertes lorsque vous créez une machine virtuelle Linux dans Azure. Utilisez az vm open-port pour ouvrir le port TCP 80 à utiliser avec le serveur Web NGINX:

Azure CLI

Copie

Essayez-le
------------------------------------------------------------------------------------------------------
az vm open-port --port 80 --resource-group myResourceGroup --name myVM
-----------------------------------------------------------------------------------------------------------
Se connecter à une machine virtuelle
SSH sur votre VM comme d'habitude. Remplacez publicIpAddress par l'adresse IP publique de votre machine virtuelle, comme indiqué dans la sortie précédente de votre machine virtuelle:

Frapper

Copie
---------------------------------------------
ssh azureuser@publicIpAddress
-----------------------------------------------------
Installer le serveur Web
Pour voir votre machine virtuelle en action, installez le serveur Web NGINX. Mettez à jour les sources de votre package, puis installez le dernier package NGINX.

Frapper

Copie
****************************************
sudo apt-get -y update
sudo apt-get -y install nginx
****************************************************
Une fois terminé, tapez exitpour quitter la session SSH.

Afficher le serveur Web en action
Utilisez un navigateur Web de votre choix pour afficher la page d'accueil par défaut de NGINX. Utilisez l'adresse IP publique de votre machine virtuelle comme adresse Web. L'exemple suivant montre le site Web NGINX par défaut:

Voir la page d'accueil de NGINX

Nettoyer les ressources
Lorsque vous n'en avez plus besoin, vous pouvez utiliser la commande az group delete pour supprimer le groupe de ressources, la machine virtuelle et toutes les ressources associées.

Azure CLI

Copie

Essayez-le
****************************************************
az group delete --name myResourceGroup
**********************************************************

20/05/2020

DOCKER, qu'est-ce que c'est ?
--------------------------------------------------

Le terme « DOCKER » désigne plusieurs choses : le projet d'une communauté Open Source, les outils issus de ce projet Open Source, l'entreprise Docker Inc. qui constitue le principal soutien de ce projet, ainsi que les outils que l'entreprise prend officiellement en charge. Des technologies et une entreprise qui partagent le même nom, cela peut prêter à confusion.

Voici donc une rapide explication de cet état de fait.

Le logiciel « Docker » est une technologie de conteneurisation qui permet la création et l'utilisation de conteneurs Linux®.
La communauté Open Source Docker travaille à l'amélioration de cette technologie disponible gratuitement pour tout le monde.
L'entreprise Docker Inc. s'appuie sur le travail de la communauté Docker, sécurise sa technologie et partage ses avancées avec tous les utilisateurs. Elle prend ensuite en charge les technologies améliorées et sécurisées pour ses clients professionnels.
Avec la technologie DOCKER, vous pouvez traiter les conteneurs comme des machines virtuelles très légères et modulaires. En outre, ces conteneurs vous offrent une grande flexibilité : vous pouvez les créer, déployer, copier et déplacer d'un environnement à un autre, ce qui vous permet d'optimiser vos applications pour le cloud.

Les conteneurs Linux, qu'est-ce que c'est ?
Comment fonctionne la technologie Docker ?
La technologie Docker utilise le noyau Linux et des fonctions de ce noyau, telles que les groupes de contrôle cgroups et les espaces de noms, pour séparer les processus afin qu'ils puissent s'exécuter de façon indépendante. Cette indépendance reflète l'objectif des conteneurs : exécuter plusieurs processus et applications séparément les uns des autres afin d'optimiser l'utilisation de votre infrastructure tout en bénéficiant du même niveau de sécurité que celui des systèmes distincts.

Les outils de conteneurs, y compris Docker, sont associés à un modèle de déploiement basé sur une image. Il est ainsi plus simple de partager une application ou un ensemble de services, avec toutes leurs dépendances, entre plusieurs environnements. Docker permet aussi d'automatiser le déploiement des applications (ou d'ensembles de processus combinés qui forment une application) au sein d'un environnement de conteneurs.

Ces outils conçus sur des conteneurs Linux (d'où leur convivialité et leur singularité) offrent aux utilisateurs un accès sans précédent aux applications, la capacité d'accélérer le déploiement, ainsi qu'un contrôle des versions et de l'attribution des versions.

La technologie Docker est-elle la même que celle des conteneurs Linux traditionnels ?
Non. À l'origine, la technologie Docker a été créée sur la base de la technologie LXC, que la plupart des utilisateurs associent aux conteneurs Linux « traditionnels », mais elle s'est depuis émancipée. LXC était un outil de virtualisation léger très utile, mais il n'offrait pas une expérience à la hauteur pour les utilisateurs ou les développeurs. La technologie Docker permet non seulement d'exécuter des conteneurs, mais aussi de simplifier la conception et la fabrication des conteneurs, l'envoi d'images, le contrôle des versions d'image, etc.

Les conteneurs Linux traditionnels utilisent un système init capable de gérer plusieurs processus. Ainsi, des applications entières peuvent s'exécuter comme un bloc. La technologie Docker encourage la décomposition des applications en processus distincts et fournit les outils nécessaires. Cette approche granulaire présente bien des avantages.

Les avantages des conteneurs Docker
Modularité
L'approche de Docker en matière de conteneurisation repose sur la décomposition des applications : c'est-à-dire la capacité de réparer ou de mettre à jour une partie d'une application sans devoir désactiver l'ensemble de cette dernière. En plus de cette approche basée sur les microservices, Docker vous permet de partager des processus entre différentes applications quasiment comme vous le feriez avec une architecture orientée services (SOA).

Couches et contrôle des versions d'image
Chaque fichier image Docker est composé d'une série de couches. Ces couches sont assemblées dans une image unique. Chaque modification de l'image engendre la création d'une couche. Chaque fois qu'un utilisateur exécute une commande, comme run ou copy, une nouvelle couche se crée.

Docker réutilise ces couches pour la construction de nouveaux conteneurs, accélérant ainsi le processus de construction. Les modifications intermédiaires sont partagées entre les images, ce qui optimise la vitesse, la taille et l'efficacité. Qui dit superposition de couches, dit contrôle des versions. À chaque changement, un journal des modifications est mis à jour afin de vous offrir un contrôle total des images de votre conteneur.

Restauration
La fonction la plus intéressante de la superposition de couches est sans doute la restauration. Chaque image est composée de couches. Aussi, si l'itération actuelle d'une image ne vous convient pas, vous pouvez restaurer la version précédente. Cette fonction favorise le développement agile et vous aide à mettre en œuvre les pratiques d'intégration et de déploiement continus (CI/CD) au niveau des outils.

Déploiement rapide
Avant, il fallait plusieurs jours pour mettre en place du nouveau matériel, le faire fonctionner, l'approvisionner et le rendre disponible. C'était un processus complexe et fastidieux. Aujourd'hui, avec les conteneurs Docker, vous pouvez effectuer tout cela en quelques secondes seulement. En créant un conteneur pour chaque processus, vous pouvez rapidement partager les processus similaires avec les nouvelles applications. De plus, comme vous n'avez pas besoin de redémarrer le système d'exploitation pour ajouter ou déplacer un conteneur, le délai de déploiement s'en trouve encore réduit. Et ce n'est pas tout. La vitesse du déploiement est telle que vous pouvez vous permettre de créer et de détruire facilement et à moindre coût les données de vos conteneurs, sans aucun problème.

Pour résumer, la technologie Docker propose une approche plus granulaire, contrôlable et basée sur des microservices, qui place l'efficacité au cœur de ses objectifs.

En savoir plus sur les avantages de Docker
Existe-t-il des limites à l'utilisation de Docker ?
Docker est une technologie très efficace pour la gestion de conteneurs uniques. Cependant, à mesure qu'augmente le nombre de conteneurs et d'applications conteneurisées (tous décomposés en centaines de composants), la gestion et l'orchestration se complexifient. Au final, vous devez prendre du recul et regrouper plusieurs conteneurs pour assurer la distribution des services (réseau, sécurité, télémétrie, etc.) vers tous vos conteneurs. C'est précisément à ce niveau qu'intervient la technologie Kubernetes.

En savoir plus sur l'orchestration des conteneurs avec Kubernetes
Avec Docker, vous ne profitez pas des mêmes fonctionnalités de type UNIX qu'offrent les conteneurs Linux traditionnels, c'est-à-dire que vous ne pouvez notamment pas utiliser de processus tels que cron ou syslog au sein du conteneur, en parallèle de votre application. Il existe aussi des limites au niveau du nettoyage des processus petits-enfants après l'arrêt des processus enfants, alors que ce nettoyage était effectué par les conteneurs Linux traditionnels. Vous pouvez contourner ces problèmes en modifiant le fichier de configuration et en configurant ces fonctions dès le début, même si ce n'est pas immédiatement évident.

De plus, il existe d'autres sous-systèmes et périphériques Linux qui n'appartiennent pas à un espace de noms, notamment les périphériques SELinux, cgroups et /dev/sd*. Cela signifie que si un pirate prenait le contrôle de ces sous-systèmes, l'hôte serait compromis. Afin de préserver sa légèreté, le noyau de l'hôte est partagé avec les conteneurs, ce qui ouvre une brèche de sécurité. Ce n'est pas le cas avec les machines virtuelles, car elles sont bien mieux isolées du système hôte.

Les conteneurs Docker sont-ils vraiment sûrs ?
Le démon Docker peut également poser des problèmes de sécurité. Pour utiliser et exécuter des conteneurs Docker, il est conseillé d'utiliser le démon Docker, qui s'exécute en permanence pour la gestion des conteneurs. Le démon Docker nécessite des privilèges root, il est donc important de surveiller l'accès à ces processus, ainsi qu'à leur emplacement. Par exemple, un démon en local est plus difficile à attaquer qu'un démon qui réside dans un emplacement public, comme un serveur Web.

17/05/2020

Système hiérarchique de nommage des ressources d'un réseau, un des protocoles de base de l'Internet
Le Domain Name System, généralement abrégé DNS, qu'on peut traduire en « système de noms de domaine », est le service informatique distribué utilisé pour traduire les noms de domaine Internet en adresse IP ou autres enregistrements. En fournissant dès les premières années d'Internet, autour de 1985, un service distribué de résolution de noms, le DNS a été un composant essentiel du développement du réseau.
Pour les articles homonymes, voir DNS (homonymie).
Faits en bref: Fonction, Sigle …
À la demande de la DARPA (Defense Advanced Research Projects Agency, « Agence pour les projets de recherche avancée de défense ») américaine, Jon Postel et Paul Mockapetris ont conçu le « Domain Name System » en 1983 et en ont rédigé la première implémentation.
Rôle du DNS
Les équipements (hôtes) connectés à un réseau IP, comme Internet, possèdent une adresse IP qui les identifie sur le réseau. Ces adresses sont numériques afin de faciliter leur traitement par les machines. En IPv4, elles sont représentées sous la forme « ###.###.###.### », où « ### » est un nombre entre 0 et 255 (en représentation décimale). En IPv6, les adresses sont représentées sous la forme « ###x:###x:###x:###x:###x:###x:###x:###x », où « ###x » représente une valeur hexadécimale de 0000 à FFFF.
Pour faciliter l'accès aux hôtes sur un réseau IP, un mécanisme a été mis en place pour associer un nom à une adresse IP. Ce nom, plus simple à retenir, est appelé « nom de domaine ». Résoudre un nom de domaine consiste à trouver l'adresse IP qui lui est associée.
En plus des adresses IP, des informations complémentaires peuvent être associées aux noms de domaines comme des enregistrements dans le contexte de la lutte contre le spam (SPF), RRSIG pour la sécurité des informations du DNS (DNSSEC) ou NAPTR pour associer des numéros de téléphone à des adresses e-mail (ENUM).
Histoire
Article détaillé : hosts.
Avant le DNS, la résolution d'un nom sur Internet devait se faire grâce à un fichier texte appelé HOSTS.TXT (RFC 608) maintenu par le NIC du Stanford Research Institute (SRI) et copié sur chaque ordinateur du réseau par transfert de fichier. En 1982, ce système centralisé montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le système distribué Grapevine de Xerox et IEN 116. Le premier (Grapevine) est jugé trop compliqué tandis que le second (IEN 116) est insuffisant. C’est finalement l’équipe dirigée par Elizabeth Feinler au NIC qui définira le Domain Name System afin de gérer la croissance de l'internet en déléguant la gestion des noms de domaine à des serveurs de noms distribués. Paul Mockapetris publie le design du système dans les RFC 882 et RFC 883 en 1983. La norme correspondante est publiée dans les RFC 1034 et RFC 1035 en 1987. En 1987, le fichier HOSTS.TXT contenait 5 500 entrées, tandis que 20 000 hôtes étaient définis dans le DNS.
Un système hiérarchique et distribué
Hiérarchie du DNS.
Résolution itérative d'un nom dans le DNS par un serveur DNS (étapes 2 à 7) et réponse (étape 8) suite à l'interrogation récursive (étape 1) effectuée par un client (resolver) DNS. (remarque: Le serveur DNS récursif est dit récursif car il accepte ce type de requêtes mais il effectue des requêtes itératives)
Hiérarchie du DNS
Le système des noms de domaine consiste en une hiérarchie dont le sommet est appelé la racine. On représente cette dernière par un point. Dans un domaine, on peut créer un ou plusieurs sous-domaines ainsi qu'une délégation pour ceux-ci, c'est-à-dire une indication que les informations relatives à ce sous-domaine sont enregistrées sur un autre serveur. Ces sous-domaines peuvent à leur tour déléguer des sous-domaines vers d'autres serveurs.
Tous les sous-domaines ne sont pas nécessairement délégués. Les délégations créent des zones, c'est-à-dire des ensembles de domaines et leurs sous-domaines non délégués qui sont configurés sur un serveur déterminé. Les zones sont souvent confondues avec les domaines.
Les domaines se trouvant immédiatement sous la racine sont appelés domaine de premier niveau (TLD : Top Level Domain). Les noms de domaines ne correspondant pas à une extension de pays sont appelés des domaines génériques (gTLD), par exemple .org ou .com. S'ils correspondent à des codes de pays (fr, be, ch…), ce sont des domaines de premier niveau national, aussi appelés ccTLD de l'anglais country code TLD.
On représente un nom de domaine en indiquant les domaines successifs séparés par un point, les noms de domaines supérieurs se trouvant à droite. Par exemple, le domaine org. est un TLD, sous-domaine de la racine. Le domaine windunix.org. est un sous-domaine de .org. Cette délégation est accomplie en indiquant la liste des serveurs DNS associée au sous-domaine dans le domaine de niveau supérieur.
Les noms de domaines sont donc résolus en parcourant la hiérarchie depuis le sommet et en suivant les délégations successives, c'est-à-dire en parcourant le nom de domaine de droite à gauche.
Pour qu'il fonctionne normalement, un nom de domaine doit avoir fait l'objet d'une délégation correcte dans le domaine de niveau supérieur.
Résolution du nom par un hôte
Les hôtes n'ont qu'une connaissance limitée du système des noms de domaine. Quand ils doivent résoudre un nom, ils s'adressent à un ou plusieurs serveurs de noms dits récursifs, c'est-à-dire qu'ils vont parcourir la hiérarchie DNS et faire suivre la requête à un ou plusieurs autres serveurs de noms pour fournir une réponse. Les adresses IP de ces serveurs récursifs sont souvent obtenues via DHCP ou encore configurés en dur sur la machine hôte. Les fournisseurs d'accès à Internet mettent à disposition de leurs clients ces serveurs récursifs. Il existe également des serveurs récursifs publics comme ceux de Yandex.DNS, Google Public DNS ou OpenNIC.
Quand un serveur DNS récursif doit trouver l'adresse IP de fr.windunix.org, un processus itératif démarre pour consulter la hiérarchie DNS. Ce serveur demande aux serveurs DNS appelés serveurs racine quels serveurs peuvent lui répondre pour la zone org. Parmi ceux-ci, le serveur va en choisir un pour savoir quels serveurs sont capables de lui répondre pour la zone windunix.org. C'est un de ces derniers qui pourra lui donner l'adresse IP de fr.windunix.org. S'il se trouve qu'un serveur ne répond pas, un autre serveur de la liste sera consulté.
Pour optimiser les requêtes ultérieures, les serveurs DNS récursifs font aussi office de DNS cache : ils gardent en mémoire (cache) la réponse d'une résolution de nom afin de ne pas effectuer ce processus à nouveau ultérieurement. Cette information est conservée pendant une période nommée Time to live et associée à chaque nom de domaine.
Un nom de domaine peut utiliser plusieurs serveurs DNS. Généralement, les noms de domaines en utilisent au moins deux : un primaire et un secondaire. Il peut y avoir plusieurs serveurs secondaires.
L'ensemble des serveurs primaires et secondaires font autorité pour un domaine, c'est-à-dire que la réponse ne fait pas appel à un autre serveur ou à un cache. Les serveurs récursifs fournissent des réponses qui ne sont pas nécessairement à jour, à cause du cache mis en place. On parle alors de réponse ne faisant pas autorité (non-authoritative answer).
Cette architecture garantit au réseau Internet une certaine continuité dans la résolution des noms. Quand un serveur DNS tombe en panne, le bon fonctionnement de la résolution de nom n'est pas remis en cause dans la mesure où des serveurs secondaires sont disponibles.
Résolution inverse
Pour trouver le nom de domaine associé à une adresse IP, on utilise un principe semblable. Dans un nom de domaine, la partie la plus générale est à droite : org dans fr.windunix.org, le mécanisme de résolution parcourt donc le nom de domaine de droite à gauche. Dans une adresse IP V4, c'est le contraire : 213 est la partie la plus générale de 213.228.0.42. Pour conserver une logique cohérente, on inverse l'ordre des quatre termes de l'adresse et on la concatène au pseudo domaine in-addr.arpa. Ainsi, par exemple, pour trouver le nom de domaine de l'adresse IP 91.198.174.2, on résout 2.174.198.91.in-addr.arpa.
La déclaration inverse est importante sur les adresses IP publiques Internet puisque l'absence d'une résolution inverse est considérée comme une erreur opérationnelle (RFC 1912) qui peut entraîner le refus d'accès à un service. Par exemple, un serveur de messagerie électronique se présentant en envoi avec une adresse IP n'ayant pas de résolution inverse (PTR) a de grandes chances de se voir refuser, par l'hôte distant, la transmission du courrier (message de refus de type : IP lookup failed).
De plus, cette résolution inverse est importante dans le cadre de la réalisation de diagnostics réseaux car c'est elle qui permet de rendre les résultats de la commande traceroute humainement exploitables. Les dénominations des noms d'hôtes inverses sont souvent des composites de sous-domaines de localisation (ville, région, pays) et de domaines explicites indiquant le fournisseur d'accès Internet traversé comme francetelecom.net (###X.nctou202.Toulouse.francetelecom.net) et opentransit.net (###X.Aubervilliers.opentransit.net) pour France Télécom, ou encore proxad.net (###X.intf.routers.proxad.net) pour Free.
Une adresse IP peut être associée à différents noms de domaine via l'enregistrement de plusieurs entrées PTR dans le sous-domaine .arpa consacré à cette adresse (in-addr.arpa. pour IPv4 et ip6.arpa. pour IPv6). L'utilisation d'enregistrements PTR multiples pour une même adresse IP est éventuellement présente dans le cadre de l'hébergement virtuel de multiples domaines web derrière la même adresse IP mais n'est pas recommandée dans la mesure où le nombre des champs PTR à renvoyer peut faire dépasser à la réponse la taille des paquets UDP de réponse et entraîner l'utilisation du protocole TCP (plus coûteux en ressources) pour envoyer la réponse à la requête DNS.
Résolution inverse CIDR
Les délégations des zones inverses se font sur une frontière d'octet, ce qui fonctionne quand les blocs d'adresses sont distribués de façon classful mais pose des problèmes quand les blocs assignés sont de taille quelconque.
Par exemple, si deux clients A et B disposent chacun des blocs 192.168.0.0/25 et 192.168.0.128/25, il n'est pas possible de déléguer 0.168.192.in-addr.arpa. au premier pour qu'il puisse définir les PTR correspondant à ses hôtes, car cela empêcherait le second de faire de même.
La RFC 2317 a défini une approche pour traiter ce problème, elle consiste à faire usage de domaines intermédiaires et de CNAME.
$ORIGIN 0.168.192.in-addr.arpa.
0/25 NS ns.clientA.fr.
128/25 NS ns.clientB.fr.
0 CNAME 0.0/25.0.168.192.in-addr.arpa.
1 CNAME 1.0/25.0.168.192.in-addr.arpa...
127 CNAME 127.0/25.0.168.192.in-addr.arpa.
128 CNAME 128.128/25.0.168.192.in-addr.arpa...
255 CNAME 255.128/25.0.168.192.in-addr.arpa.
Le client A définit la zone 0/25.0.168.192.in-addr.arpa. :
$ORIGIN 0/25.0.168.192.in-addr.arpa.
1 PTR hote1.clientA.fr...
127 PTR hote127.clientA.fr.
Le client B fait de même pour 128/25.0.168.192.in-addr.arpa. et les adresses 128 à 255.
La résolution inverse de 192.168.0.1 aboutira aux requêtes suivantes :
1.0.168.192.in-addr.arpa. CNAME 1.0/25.0.168.192.in-addr.arpa.
1.0/25.0.168.192.in-addr.arpa. PTR hote1.clientA.fr.
Ce qui assure le fonctionnement de la résolution inverse, moyennant un niveau d'indirection supplémentaire.
Serveurs DNS racine
Article détaillé : Serveur racine du DNS.
Les serveurs racine sont gérés par douze organisations différentes : deux sont européennes, une japonaise et les neuf autres sont américaines. Sept de ces serveurs sont en réalité distribués dans le monde grâce à la technique anycast et neuf disposent d'une adresse IPv6. Grâce à anycast, plus de 200 serveurs répartis dans 50 pays du monde assurent ce service. Il existe 13 autorités de nom appelées de a à m.root-servers.net. Le serveur k reçoit par exemple de l'ordre de 70 000 à 100 000 requêtes par seconde en avril 2019.
Le DNS ne fournit pas de mécanisme pour découvrir la liste des serveurs racine, chacun des serveurs doit donc connaître cette liste au démarrage grâce à un encodage explicite. Cette liste est ensuite mise à jour en consultant l'un des serveurs indiqués. La mise à jour de cette liste est peu fréquente de façon que les serveurs anciens continuent à fonctionner.
Fully Qualified Domain Name
Article détaillé : Fully qualified domain name.
On entend par Fully qualified domain name (FQDN), ou Nom de domaine pleinement qualifié un nom de domaine écrit de façon absolue, y compris tous les domaines jusqu'au domaine de premier niveau (TLD), il est ponctué par un point final, par exemple fr.windunix.org.
La norme prévoit qu'un élément d'un nom de domaine (appelé label) ne peut dépasser 63 caractères, un FQDN ne pouvant dépasser 253 caractères.
Nom de domaine internationalisé
Article détaillé : Nom de domaine internationalisé.
Dans leur définition initiale, les noms de domaines sont constitués des caractères de A à Z (sans casse : les lettres capitales ne sont pas différenciées), de chiffres et du trait d'union.
La RFC 3490 définit un format appelé Punycode qui permet l'encodage d'un jeu de caractère plus étendu.
Les techniques du DNS Round-Robin pour la distribution de la charge
Article détaillé : DNS round-robin.
Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin (en français tourniquet DNS), une des techniques de répartition de charge qui consiste à associer plusieurs adresses IP à un FQDN. Les différentes versions de windunix, comme fr.windunix.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 et 207.142.131.248. L'ordre dans lequel ces adresses sont renvoyées sera modifié d'une requête à la suivante. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important entre les différentes machines ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers (client DNS).
Principaux enregistrements DNS
Article détaillé : Liste des enregistrements DNS.
Le type d'enregistrement de ressource (RR pour Resource Record) est codé sur 16 bits, l'IANA conserve le registre des codes assignés. Les principaux enregistrements définis sont les suivants :
A record ou address record (également appelé enregistrement d’hôte) qui fait correspondre un nom d'hôte ou un nom de domaine ou un sous-domaine à une adresse IPv4 de 32 bits distribués sur quatre octets ex: 123.234.1.2 ;
AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits distribués sur seize octets ;
CNAME record ou canonical name record qui permet de faire d'un domaine un alias vers un autre. Cet alias hérite de tous les sous-domaines de l'original ;
MX record ou mail exchange record qui définit les serveurs de courriel pour ce domaine ;
PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisqu'il fait exactement le contraire du A record ;
NS record ou name server record qui définit les serveurs DNS de ce domaine ;
SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, courriel de contact, différentes durées dont celle d'expiration, numéro de série de la zone ;
SRV record qui généralise la notion de MX record, mais qui propose aussi des fonctionnalités avancées comme le taux de répartition de charge pour un service donné, standardisé dans la RFC 2782 ;
NAPTR record ou Name Authority Pointer record qui donne accès à des règles de réécriture de l'information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la RFC 3403 ;
TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement est utilisé pour implémenter la spécification Sender Policy Framework) ;
d'autres types d'enregistrements sont utilisés occasionnellement, ils servent simplement à donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hôte, c'est-à-dire sa latitude et sa longitude). Certaines personnes disent que cela aurait un intérêt majeur mais n'est que très rarement utilisé sur le monde Internet.
NS record
L'enregistrement NS crée une délégation d'un sous-domaine vers une liste de serveurs.
Dans la zone org, les enregistrements NS suivants créent le sous-domaine windunix et délèguent celui-ci vers les serveurs indiqués.
L'ordre des serveurs est quelconque. Tous les serveurs indiqués doivent faire autorité pour le domaine.
windunix NS ns1.windunix.ml.
windunix NS ns2.windunix.ml.
windunix NS ns0.windunix.ml.
PTR record
À l'inverse d'une entrée de type A ou AAAA, une entrée PTR indique à quel nom d'hôte correspond une adresse IPv4 ou IPv6. Si elle est spécifiée, elle doit contenir l'enregistrement inverse d'une entrée DNS A ou AAAA.
Par exemple (pour une adresse IPv4) cet enregistrement PTR est :
232.174.198.91.in-addr.arpa. IN PTR text.esams.windunix.ml.
correspond à cette entrée A :
text.esams.windunix.ml. IN A 91.198.174.232
Dans le cas d'une adresse IPv6, les entrées de type PTR sont enregistrées dans la zone ip6.arpa. (pendant de la zone in-addr.arpa. des adresses IPv4).
La règle permettant de retrouver l'entrée correspondant à une adresse IPv6 est similaire à celle pour les adresses IPv4 (renversement de l'adresse et recherche dans un sous-domaine dédié de la zone arpa.), mais diffère au niveau du nombre de bits de l'adresse utilisés pour rédiger le nom du domaine où rechercher le champ PTR : là où pour IPv4 le découpage de l'adresse se fait par octet, pour IPv6 c'est un découpage par quartet qui est utilisé.
Par exemple à l'adresse IPv6 :
2001:610:240:22::c100:68b
correspond le nom de domaine :
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. PTR www.ipv6.ripe.net.
MX record
Une entrée DNS MX indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. Par exemple :
windunix.ml. IN MX 10 mchenry.windunix.ml.
windunix.ml. IN MX 50 lists.windunix.ml.
On voit que les courriels envoyés à une adresse en .ml sont envoyés au serveur mchenry.windunix.ml. ou lists.windunix.ml. Le nombre précédant le serveur représente la priorité. Le serveur avec la priorité numérique la plus petite est employé en priorité. Ici, c'est donc mchenry.windunix.ml. qui doit être utilisé en premier, avec une valeur de 10.
Les serveurs indiqués doivent avoir été configurés pour accepter de relayer les courriers pour le nom de domaine indiqué. Une erreur courante consiste à indiquer des serveurs quelconques comme serveurs secondaires, ce qui aboutit au rejet des courriers quand le serveur primaire devient inaccessible. Il n'est pas indispensable de disposer de serveurs secondaires, les serveurs émetteurs conservant les messages pendant un temps déterminé (typiquement, plusieurs jours) jusqu'à ce que le serveur primaire soit à nouveau disponible.
Les entrées MX sont généralisées par les entrées SRV qui permettent de faire la même chose mais pour tous les services, pas seulement SMTP (le courriel). L'avantage des entrées SRV par rapport aux entrées MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la répartition de charge plus efficacement. L'inconvénient c'est qu'il existe encore peu de programmes clients qui gèrent les entrées SRV. Cependant, depuis 2009, avec l'augmentation de l'utilisation du protocole SIP sur les services de VoIP, les enregistrements SRV deviennent plus fréquents dans les zones DNS.
CNAME record
L'enregistrement CNAME permet de créer un alias.
Par exemple :
fr.windunix.org. IN CNAME text.windunix.ml.
text.windunix.ml. IN CNAME text.esams.windunix.ml.
text.esams.windunix.ml. IN A 91.198.174.232
Celui-ci exclut tout autre enregistrement (RFC 1034 section 3.6.2, RFC 1912 section 2.4), c'est-à-dire qu'on ne peut avoir à la fois un CNAME et un A record pour le même nom de domaine.
Par exemple, ceci est interdit :
fr.windunix.org. IN CNAME text.windunix.ml.
fr.windunix.org. IN A 91.198.174.232
Par ailleurs, pour des raisons de performance, et pour éviter les boucles infinies du type
fr.windunix.org. IN CNAME text.windunix.ml.
text.windunix.org. IN CNAME fr.windunix.ml.
les spécifications (RFC 1034 section 3.6.2, RFC 1912 section 2.4) recommandent de ne pas faire pointer un CNAME sur un autre CNAME ni sur un DNAME (alias pour un nom et tous ses sous-noms).
Ainsi, le premier exemple serait préférablement enregistré de la façon suivante :
fr.windunix.org. IN CNAME text.esams.windunix.ml.
text.windunix.ml. IN CNAME text.esams.windunix.ml.
text.esams.windunix.ml. IN A 91.198.174.232
NAPTR record
Peu répandus à l'heure actuelle (ils sont surtout utilisés par ENUM), ils décrivent une réécriture d'une clé (un nom de domaine) en URI. Par exemple, dans ENUM, des enregistrements NAPTR peuvent être utilisés pour trouver l'adresse de courrier électronique d'une personne, connaissant son numéro de téléphone (qui sert de clé à ENUM).
Ses paramètres sont dans l'ordre :
Order : indique dans quel ordre évaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une certaine valeur de order à examiner, les enregistrements des valeurs suivantes de order n'entrent pas en considération ;
Preference : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même valeur de order ;
Flags : indique par exemple si l'enregistrement décrit une réécriture transitoire (dont le résultat est un nom de domaine pointant sur un autre enregistrement NAPTR) ou une réécriture finale ; la sémantique précise du paramètre flags dépend de l'application DDDS ('Dynamic Delegation Discovery System', RFC 3401) employée (ENUM en est une parmi d'autres) ;
Services : décrit le service de réécriture ; par exemple dans ENUM, la valeur de services spécifie le type de l'URI résultante ; la sémantique précise de ce paramètre dépend également de l'application DDDS employée ;
Regexp : l'opération de réécriture elle-même, formalisée en une expression rationnelle ; cette expression rationnelle est à appliquer à la clé ; ne peut être fourni en même temps que replacement ;
Replacement : nom de domaine pointant sur un autre enregistrement NAPTR, permettant par exemple une réécriture transitoire par délégation ; ne peut être fourni en même temps que regexp.
L'enregistrement NAPTR est défini par la RFC 3403.
SOA record
Article détaillé : SOA Resource Record.
Cet enregistrement permet d'indiquer le serveur de nom maître (primaire), l'adresse e-mail d'un contact technique (avec @ remplacé par un point) et des paramètres d'expiration.
Il désigne l'autorité (start of authority) ou le responsable de la zone dans la hiérarchie DNS. C'est l'acte de naissance de la zone DNS.
Ces paramètres sont dans l'ordre :
windunix.org. IN SOA ns0.windunix.ml. hostmaster.windunix.ml. 2010060311 43200 7200 1209600 3600
Serial : indique un numéro de version pour la zone (32 bits non signé). Ce nombre doit être incrémenté à chaque modification du fichier zone ; on utilise par convention une date au format « yyyymmddnn » (« yyyy » pour l'année sur 4 chiffres, « mm » pour le mois sur 2 chiffres, « dd » pour le jour sur 2 chiffres, « nn » pour un compteur de révision si le numéro de série est modifié plusieurs fois dans un même jour. Cette convention évite tout débordement du 32 bits non signé jusqu'en l'an 4294) ;
Refresh : l'écart en secondes entre les demandes successives de mise à jour réalisées depuis le serveur secondaire ou les serveurs esclaves ;
Retry : le délai en secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur précédente requête a échoué ;
Expire : le délai en secondes au terme duquel la zone est considérée comme invalide si le secondaire ou les esclaves ne peuvent joindre le serveur primaire ;
Minimum ou negative TTL : utilisé pour spécifier, en secondes, la durée de vie pendant laquelle sont conservées en cache les réponses qui correspondent à des demandes d'enregistrements inexistants.
Les versions récentes de BIND (named) acceptent les suffixes M, H, D ou W pour indiquer un intervalle de temps en minutes, heures, jours ou semaines respectivement.
Time to live
Chaque record est associé à un Time to live (TTL) qui détermine combien de temps il peut être conservé dans un serveur cache. Ce temps est typiquement d'un jour (86400 s) mais peut être plus élevé pour des informations qui changent rarement, comme des records NS. Il est également possible d'indiquer que des informations ne doivent pas être mises en cache en spécifiant un TTL de zéro.
Certaines applications, comme des navigateurs web disposent également d'un cache DNS, mais qui ne respecte pas nécessairement le TTL du DNS. Ce cache applicatif est généralement de l'ordre de la minute, mais Internet Explorer par exemple conserve les informations jusqu'à 30 minutes, indépendamment du TTL configuré.
Glue records
Quand un domaine est délégué à un serveur de noms qui appartient à ce sous-domaine, il est nécessaire de fournir également l'adresse IP de ce serveur pour éviter les références circulaires. Ceci déroge au principe général selon lequel l'information d'un domaine n'est pas dupliquée ailleurs dans le DNS.
Par exemple, dans la réponse suivante au sujet des NS pour le domaine windunix.ml :
windunix.ml. IN NS ns2.windunix.ml.
windunix.ml. IN NS ns1.windunix.ml.
windunix.ml. IN NS ns0.windunix.ml.
Il est nécessaire de fournir également les adresses IP des serveurs indiqués dans la réponse (glue records), car ils font partie du domaine en question :
ns0.windunix.ml. IN A 208.80.152.130
ns1.windunix.ml. IN A 208.80.152.142
ns2.windunix.ml. IN A 91.198.174.4
Mise à jour dynamique
Une extension du DNS nommée DNS dynamique (DDNS) permet à un client de mettre à jour une zone avec des informations qui le concernent (RFC 2136). Ceci est utile quand des clients obtiennent une adresse IP par DHCP et qu'ils souhaitent que le DNS reflète le nom réel de la machine.
Considérations opérationnelles
Mise à jour du DNS
Les mises à jour se font sur le serveur primaire du domaine, les serveurs secondaires recopiant les informations du serveur primaire dans un mécanisme appelé transfert de zone. Pour déterminer si un transfert de zone doit avoir lieu, le serveur secondaire consulte le numéro de version de la zone et le compare à la version qu'il possède. Le serveur primaire détermine à quelle fréquence le numéro de version est consulté. Quand un changement est effectué, les serveurs envoient des messages de notification aux serveurs secondaires pour accélérer le processus.
Il se peut que des informations qui ne sont plus à jour soient cependant conservées dans des serveurs cache. Il faut alors attendre l'expiration de leur Time to live pour que ces informations cachées disparaissent et donc que la mise à jour soit pleinement effective. On peut minimiser le temps nécessaire en diminuant le TTL associé aux noms de domaines qui vont être modifiées préalablement à une opération de changement.
Cohérence du DNS
Quand la liste des serveurs de noms change, ou quand une adresse IP qui fait l'objet d'un 'Glue record' est modifiée, le gestionnaire du domaine de niveau supérieur doit effectuer la mise à jour correspondante.
Robustesse du DNS
Pour éviter les points individuels de défaillance, on évite de partager l'infrastructure entre les serveurs qui font autorité. Un serveur secondaire sera de préférence délocalisé et routé différemment que le serveur primaire.
Bien que cela soit techniquement possible, on évite de mêler sur un même serveur le rôle de DNS récursif et celui de serveur qui fait autorité.
De même, un hôte sera configuré avec plusieurs serveurs récursifs, de sorte que si le premier ne répond pas à la requête, le suivant sera employé. En général, les serveurs récursifs fournis par les FAI refusent les requêtes émanant d'adresses IP appartenant à d'autres FAI.
Il existe des services de DNS récursifs ouverts, c'est-à-dire qu'ils acceptent les requêtes de tous les clients. Il est donc possible à un utilisateur de configurer ceux-ci en lieu et place de ceux fournis par le FAI. Ceci pose cependant les problèmes suivants :
il n'y a pas de garantie que les réponses fournies seront les mêmes qu'avec des serveurs récursifs habituels. Un tel service pourrait en effet faire référence à une autre hiérarchie depuis la racine, disposer de TLD additionnels non standard, restreindre l'accès à certains domaines, voire altérer certains records avant leur transmission au client.
il n'y a pas de garantie de confidentialité, c'est-à-dire que ce service pourrait déterminer à quels domaines un utilisateur a accès en conservant des traces des requêtes DNS.
Sécurité du DNS
Le protocole DNS a été conçu avec un souci minimum de la sécurité. Plusieurs failles de sécurité du protocole DNS ont été identifiées depuis. Les principales failles du DNS ont été décrites dans le RFC 3833 publié en août 2004.
Interception des paquets
Une des failles mises en avant est la possibilité d'intercepter les paquets transmis. Les serveurs DNS communiquent au moyen de paquets uniques et non signés. Ces deux spécificités rendent l'interception très aisée. L'interception peut se concrétiser de différentes manières, notamment via une attaque de type « man in the middle », de l'écoute des données transférées et de l'envoi de réponse falsifiée (voir paragraphe ci-dessous).
Fabrication d'une réponse
Les paquets des serveurs DNS étant faiblement sécurisés, authentifiés par un numéro de requête, il est possible de fabriquer de faux paquets. Par exemple, un utilisateur qui souhaite accéder au site http://mabanque.example.com fait une demande au site DNS. Il suffit, à ce moment, qu'un pirate informatique réponde à la requête de l'utilisateur avant le serveur DNS pour que l'utilisateur se retrouve sur un site d'hameçonnage.
Corruption des données
La trahison par un serveur, ou corruption de données, est, techniquement, identique à une interception des paquets. La seule différence venant du fait que l'utilisateur envoie volontairement sa requête au serveur. Cette situation peut arriver lorsque, par exemple, l'opérateur du serveur DNS souhaite mettre en avant un partenaire commercial.
Empoisonnement du cache DNS
Article détaillé : empoisonnement du cache DNS.
L'empoisonnement du cache DNS ou pollution de cache DNS (en anglais, DNS cache poisoning) est une technique permettant de leurrer les serveurs DNS afin de leur faire croire qu'ils reçoivent une requête valide tandis qu'elle est frauduleuse.
Déni de service
Article détaillé : Déni de service.
Une attaque par déni de service (ou attaque par saturation; en anglais, Denial of Service attack ou DoS attack) est une attaque sur un serveur informatique qui résulte en l'incapacité pour le serveur de répondre aux requêtes de ses clients.
DNSSEC
Article détaillé : DNSSEC.
Pour contrer ces vulnérabilités (corruption des données, empoisonnement de cache DNS, etc), le protocole DNSSEC (RFC 4033, RFC 4034, RFC 4035) a été développé. Il utilise les principes de cryptographie asymétrique et de signature numérique pour garantir l'intégrité des données, ainsi qu'une preuve de non-existence si l'enregistrement demandé n'existe pas. La zone racine du DNS a été signée le 15 juillet 2010, et le déploiement de DNSSEC sur les domaines de premier niveau (TLD : Top Level Domain) continue, une liste des domaines couverts étant disponible.
Chiffrement
Depuis 2015, l'IETF travaille à la sécurité du canal de communication du DNS (là où DNSSEC protège les données). Cela a débouché sur la publication de plusieurs RFC permettant l'utilisation de TLS afin de chiffrer la communication entre les clients DNS et les résolveurs. Il s'agit principalement de : DNS sur TLS (en) (RFC 7858, utilisant le port 853) et DNS sur HTTPS (RFC 8484, requête DNS encapsulée dans une requête HTTP, et traitée par un serveur Web).
Il n'y a pas, en 2018, de possibilités de chiffrer – via TLS – les communications entre un résolveur et un serveur faisant autorité.
Exemple d'attaques majeures contre des serveurs DNS
En juillet 2008, quelques jours après la publication du rapport de la United States Computer Emergency Readiness Team concernant la faille de sécurité des serveurs DNS permettant d'empoisonner leur cache, plusieurs serveurs DNS majeurs ont subi des attaques. Une des plus importantes fut celle menée contre les serveurs de AT&T. L'attaque empoisonnant le cache des serveurs DNS de AT&T a permis au pirate informatique de rediriger toutes les requêtes de Google vers un site d'hameçonnage.
Détails du protocole
DNS utilise en général UDP et le port 53. La taille maximale des paquets utilisée est de 512 octets. Si une réponse dépasse cette taille, la norme prévoit que la requête doit être renvoyée sur le port TCP 53. Ce cas est cependant rare et évité, et les firewalls bloquent souvent le port TCP 53. Les transferts de zone s'effectuent par TCP sur le même numéro de port. Pour des raisons de sécurité, les serveurs restreignent généralement la possibilité de transférer des zones.
L'extension EDNS0 (RFC 2671) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.
La norme prévoit qu'il existe une classe associée aux requêtes. Les classes IN (Internet), CH (Chaos) et HS (Hesiod (en)) sont définies, seule la classe IN étant réellement utilisée en pratique. La classe chaos est utilisée par BIND pour révéler le numéro de version.
Exemples de consultation DNS
Pour vérifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systèmes d'exploitation utilisés.
Par exemple sur Windows la commande nslookup est disponible via l'invite de commande :
> nslookup www.google.fr
Serveur : Livebox-6370
Address: 192.168.1.1
Réponse ne faisant pas autorité :
Nom : www.l.google.com
Addresses:
209.85.229.104
209.85.229.106
209.85.229.103
209.85.229.147
209.85.229.105
209.85.229.99
Aliases: www.google.fr
www.google.com
ou encore dig sur les systèmes compatibles avec UNIX :
> dig www.google.com aaaa
; DiG 9.7.0-P1 www.google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER