Configuration dns comment les applications communiquent ?


#1

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


#2

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 .

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


#3

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:)


#4

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() 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 .


Anonymous Coward


#5

Merci pour tes explications, je pense que le souci vien des dns de mon FAI enfin sa reste encore a confirmer.


#6

Si tu souhaites nous expliquer le problème pour que l’on puisse t’aider, c’est volontiers.


AnonymousCoward


#7

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.

Il manque une étape car les serveurs DNS de la zone fr ne connaissent pas l’adresse IP de toto.fr mais seulement les noms des serveurs DNS de la zone toto.fr. C’est à l’un de ces serveurs qu’il faut encore envoyer une requête pour recevoir l’adresse de toto.fr.

La commande suivante simule ce processus récursif depuis le client :

dig +trace toto.fr

dig est inclus dans le paquet dnsutils.


#8

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


#9

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.


#10

ok je vais voir la doc aux sujet de time to live , c’est un début de piste

Merci pour ta réponse