# Configuration dns comment les applications communiquent ? **URL:** \ **Category:** Support Debian\ **Created:** [Novembre 21, 2018, 10:58 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038 "2018-11-21T10:58:10Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\ **Post date:** [Novembre 21, 2018, 10:58 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/1 "2018-11-21T10:58:11Z")
Bonjours, je voudrai bien comprendre comment le circuit du dns fonctionnent. j’utilise unbound pour le dns , isc-dhcp-server pour la configuration en dhcp des interfaces recevant les pc client, et isc-dhcp-client pour qu’il puisse ce connecter a la box. Dans quel sens sa tourne ? isc-dhcp-server fourni l’adresse ip dns via la clause: option domain-name-servers aux client et donc unbound écoute sur la même interface, meme ip . ? avec la clause : interface (je ne suis pas sur que cela soie juste par contre) un exemple option domain-name-servers 192.168.100.100 interface: 192.168.100.100 le client aurai alors pour adresse dns 192.168.100.100 il manque peut être quelque chose ? Merci d’avance ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Novembre 21, 2018, 1:39 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/2 "2018-11-21T13:39:27Z")
`isc-dhcp-server` fournit une adresse IP au PC client ainsi que, le plus souvent, plusieurs paramètres supplémentaires (appelés options) dont l’adresse IP d’un service/serveur DNS. Exemple pour un réseau 192.168.133.0/24 : Client : Qui veut bien me donner une adresse IP ? ISC-dhcp-server : Tiens, utilises donc 192.168.133.51/24 ! Et aussi un routeur/une route par défaut sur 192.168.133.1 et un service DNS en 192.168.133.1 et un service NTP pour avoir l’heure en 192.168.133.1 . Il faudrait que tu fasses bien la différence entre une interface réseau et une adresse IP. Une interface telle que `enp1s0` peut être liée à zéro, une ou plusieurs adresses IP. Et pour complexifier le tout, sous Linux une adresse IP est en réalité liée au système entier, pas à une interface réseau. C’est le weak [host model](https://en.wikipedia.org/wiki/Host_model) . Le daemon/service appelé dhcpd , du paquet isc-dhcp-server, attend les demandes sur une ou plusieurs interfaces réseau. Notamment du au fait que son code n’est pas très moderne. Et il provoquera une erreur si tu lui demande de s’attacher à une interface qui n’est pas déjà active. Le daemon unbound, quant à lui, attend les demandes (on dit écouter) sur une ou plusieurs adresses IP. Et la quasi-totalité des logiciels / services réseau existants font de même. `dhcpd` est une exception. – AnonymousCoward ---
**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\ **Post date:** [Novembre 21, 2018, 4:26 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/3 "2018-11-21T16:26:14Z")
Merci beaucoup pour ta réponse claire sur le sujet ça fait plaisirs. Donc unbound écoute ( donc en attente) le dhcp donne la configuration , (après avoir tester c’est juste si l’interface est pas active ça miaule.) Le client une fois qu’il a reçus ces paramètre , il fait ça demande à qui, unbound ? Ou est ce qu’il passe passe par le isc-dhcp-server puis unbountd? Merci pour tes explications:) ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Novembre 26, 2018, 4:01 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/4 "2018-11-26T16:01:33Z")
Le “client” DHCP reçoit une adresse d’un serveur/service DHCP et l’enregistre alors dans le fichier `/etc/resolv.conf` Ensuite, quand un programme sur le “client” à besoin de résoudre un nom de domaine en adresse IP genre `toto.fr`, il fait appel à la fonction [`getaddrinfo()`](https://linux.die.net/man/3/getaddrinfo) et cela lui fait envoyer une requête DNS au serveur/service indiqué dans /etc/resolv.conf . Le serveur/service DNS reçoit la requête sur une adresse IP, en UDP (ou TCP) sur le port 53. Suite à cela, si le service est assuré par unbound (qui demande un paramétrage préalable pour autoriser les connexions), unbound envoie une requête aux serveurs racines de l’Internet pour connaitre des adresses IP de serveurs pour la zone `fr.` . Une fois la réponse reçue, unbound envoie une autre requête DNS à un serveur pour la zone `fr.` et lui demandant l’info pour `toto.fr.` . Une fois cette dernière réponse reçue, il la fait suivre à “client”. Dès lors, le programme sur “client” n’a plus qu’à ouvrir une connexion réseau à destination de l’adresse IP 46.105.57.169 (oui, `toto.fr` existe). Toute cette partie par unbound est une résolution “récursive”. On peut aussi demander à unbound de juste faire suivre la demande à un autre serveur en demandant à celui-ci de faire le boulot. Par exemple à un serveur comme ceux de la FDN, ceux de Google, ceux de Cloudflare ou encore ceux de ton fournisseur d’accès à Internet. Si tu souhaites pouvoir débogguer les éventuels problèmes de DNS, je te suggère d’utiliser l’utilitaire `host` voir les utilitaires du paquet [`dnsutils`](https://packages.debian.org/stretch/dnsutils) . – Anonymous Coward ---
**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\ **Post date:** [Décembre 3, 2018, 3:22 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/5 "2018-12-03T03:22:19Z")
Merci pour tes explications, je pense que le souci vien des dns de mon FAI enfin sa reste encore a confirmer. ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Décembre 3, 2018, 8:43 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/6 "2018-12-03T20:43:59Z")
Si tu souhaites nous expliquer le problème pour que l’on puisse t’aider, c’est volontiers. – AnonymousCoward ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 3, 2018, 9:10 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/7 "2018-12-03T21:10:15Z")
> [@AnonymousCoward](#): > > unbound envoie une requête aux serveurs racines de l’Internet pour connaitre des adresses IP de serveurs pour la zone `fr.` A noter qu’un serveur DNS cache récursif n’interroge pas les serveurs racine pour chaque résolution d’un nom en .fr : une fois qu’il a reçu la liste des serveurs DNS de la zone fr, il la mémorise et s’en ressert directement pour les demandes suivantes. > [@AnonymousCoward](#): > > Une fois la réponse reçue, unbound envoie une autre requête DNS à un serveur pour la zone `fr.` et lui demandant l’info pour `toto.fr.` . Une fois cette dernière réponse reçue, il la fait suivre à “client”. Il manque une étape car les serveurs DNS de la zone fr ne connaissent pas l’adresse IP de [toto.fr](http://toto.fr) mais seulement les noms des serveurs DNS de la zone [toto.fr](http://toto.fr). C’est à l’un de ces serveurs qu’il faut encore envoyer une requête pour recevoir l’adresse de [toto.fr](http://toto.fr). La commande suivante simule ce processus récursif depuis le client : ``` dig +trace toto.fr ``` dig est inclus dans le paquet dnsutils. ---
**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\ **Post date:** [Décembre 4, 2018, 4:51 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/8 "2018-12-04T16:51:38Z")
Merci pour ta réponse: mine de rien sa fait un sacrer parcourt:) je trouve que unbound va souvent faire une requête pour le même site déjà visiter aux moment ou le client fait une nouvelle demande , il y a un moyen de rallonger la durée dans la quelle unbound conserve et répond aux client sans faire une nouvelle demande ? La documentation est en anglais t j’ai un peux de mal a voir ou cela peux ce situer? Aux besoins je peux donner ma conf , il n’y a cependant pas d’intérêt car c’est juste la doc qui pourrai jouer un rôle que j’aurai mal remplis/compris ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 4, 2018, 7:20 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/9 "2018-12-04T19:20:57Z")
La durée de vie en cache (TTL = Time To Live) d’un enregistrement DNS est spécifiée dans l’enregistrement lui-même. Cela permet de spécifier un TTL de plusieurs jours pour un enregistrement DNS qui ne change jamais, ou de quelques secondes pour un enregistrement DNS dynamique qui peut changer à tout moment. Je ne connais pas unbound, mais je suppose que par défaut il applique le TTL contenu dans les enregistrements et il y a peut-être des options pour forcer un TTL minimum. ---
**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\ **Post date:** [Décembre 4, 2018, 10:22 UTC](https://www.debian-fr.org/t/configuration-dns-comment-les-applications-communiquent/78038/10 "2018-12-04T22:22:30Z")
ok je vais voir la doc aux sujet de time to live , c’est un début de piste Merci pour ta réponse