Serveur DNS, timout resolv.conf et dhclient

Support Debian
#1

Bonjour à tous,

Contexte:
Hier le serveur DNS primaire de mon FAI est tombé en rideau. Mort. Bon, au aurait pu penser que le resolver passerait automatiquement sur l’ip du DNS secondaire repris dans mon resolv.conf, et bien non. Du moins pas tout de suite. Le timeout par défaut semble être de l’ordre de 5 sec. Vous imaginez donc la lenteur des sites lourdement chargés en redirections et autres liens vers d’autres noms de domaine. J’ai donc cherché avant de trouver que la lenteur extrême d’internet était causée par un plantage du serveur primaire de mon FAI.

Tout d’abord, je m’étonne que la basculement sur le DNS secondaire ne soit pas immédiat et automatique. Un coup de man resolv.conf et ajout d’une ligne dans le resolv.conf:

options timeout:1 ou, mieux, du moins en terme de rapidité de résolution:

options rotate timeout:1L’option rotate fait que le resolver va essayer une résolution en parallèle sur tous les nameservers renseignés dans le resolv.conf

Effet immédiat et garanti mais…

Je n’utilise pas le paquet resolvconf et toute ma configuration des serveurs DNS se passe dans resolv.conf
FAI --> router --> dhclient --> resolv.conf <-- Gnome NetworkManager

Le resolv.conf semble être modifié à la fois par dhclient et le Gnome NetworkManager. Donc, à chaque fois qu’on redemande un nouveau bail à son serveur dhcp ou si NetworkManager réinitialise une interface, les lignes ajoutées dans resolv.conf sont écrasées. S’il est possible de forcer dhclient à ajouter des nameserver avec l’option append, prepend ou supersede de manière durable, je n’ai pas trouvé comment lui faire ajouter les options rotate et timeout. Un coup de man dhclient.conf m’a donné l’espoir de pouvoir ajouter un hook dans /etc/dhcp3/dhclient-enter-hooks.d/ et /etc/dhcp3/dhclient-exit-hooks.d/ pour ajouter les options directement dans resolv.conf. Ça marche tant que NetworkManager ne le modifie pas à son tour.

Du coup, j’ai mis mon script d’ajout de l’option dans /etc/NetworkManager/dispatcher.d/ et ça marche.

Mais je trouve tout ça assez pénible et limite désordre.

  • trouvez-vous normal que le timeout du basculement du serveur primaire vers le secondaire ne soit pas immédiat?
  • comment gérez-vous les problèmes de plantage des nameserver de vos FAI (installer un namesever perso? BIND? Unbound? Ou un cache comme dnsmask?)
  • comment centraliser la gestion du resolv.conf et de ses options sans qu’un autre gestionnaire ne vienne le foutre en l’air (paquet resolvconf?)

NB: si vous voulez tester comment votre config. bascule d’un nameserver à l’autre, il suffit de donner une ip bidon comme premier nameserver dans le /etc/resolv.conf et ensuite de faire un:

#2

Salut,

Je me trouve exactement dans la même situation.

Ce qui est amusant c’est que l’option rotate test le 2ème nameserver toujours en premier et ensuite le premier nameserver (j’ai pas testé avec plus que 2)

J’ai découvert ça dans un vieux post, mais c’est toujours le cas chez moi:
https://lists.isc.org/pipermail/bind-users/2003-October/046653.html

Ce que j’ai remarqué aussi, c’est que l’option timeout n’a pas le même temps si tu as rotate ou pas.
Avec rotate, timeout est ± 2 x plus rapide… (je n’ai pas calculé précisément, mais avec timeout:5, tu vois clairement la différence)

Mais sinon, je cherche aussi désespérement à automatiser ses 2 options-là, soit via le serveur dhcp mais cela ne semble pas être possible dans mon cas, soit par dhclient.conf, mais pas trouvé et je n’ai pas (encore) essayé resolvconf, surtout du fait que j’avais pas envie de remettre une couche supplémentaire de processus automatique…

Tu n’aurais pas trouvé la solution depuis ton post? :wink:

Kenny

#3

et si vous laissiez tomber les serveurs dns de vos FAI ?

installez bind avec sa conf par defaut
et dans resolv.conf pointez le 127.0.0.1

et voila vous interrogez directement les serveurs qui vont bien, sans vous soucier de vos FAI et de leurs dns menteurs

:smt006

#4

Salut thomas,

En fait, j’ai déjà un serveur bind qui tourne nickel sur mon lan.

Le problème vient du fait qu’il y a plusieurs entités indépendantes sur le lan (associations, …).
Les autres auront donc le même resolv.conf que pour ceux de mon réseau. En soi pas de problème.
Sauf si le serveur est éteint ou en panne. (bon… si en panne, je serai là pour venir le réparer)
Eteint car pour des raisons de consommation (et de sécurité… un serveur éteint est mieux protégé qu’un serveur allumé :smiley: ) et vu que ce sont des assoc qui n’ont pas des besoins d’accès 24/24, le serveur sera éteint en quittant les bureaux le soir et redémarré le matin.

Donc, à ce moment, tous les autres connectés sur le lan se retrouve avec comme premier serveur Dns un serveur éteint… et là… paf… ± 5 à 10 sec à attendre pour toute requète vers un nouveau nom de domaine.

Ex de resolv.conf obtenu sur mon lan

search mondomaine
nameserver 172.19.99.3 (mon serveur Dns)
nameserver 172.19.3.1 (mon routeur)

Avec l’option rotate et timeout:1, ça marche nickel dans tous les cas…

Mais comment faire parvenir ses 2 options via un des processus automatique (dhclient, network-manager, resolconf)?

Toute idée est la bienvenue…

Kenny

#5

Je voulais préciser:

Le serveur dhcp, je n’ai pas trop le choix, je dois utiliser celui du routeur vu qu’il y a d’autres entités sur le lan.
Donc, pas possible d’installer mon propre serveur Dhcp vu qu’on ne peut pas forcer un client à choisir un serveur Dhcp plutôt qu’un autre.

J’avais pensé avoir trouvé la solution via l’interface du routeur, car il permet de définir de nouveaux sous-réseaux, ce que j’ai fait.
Et pour ce sous-réseau seulement, je renvoie l’info du nameserver de mon serveur Dns et l’option ‘search mondomaine’ (mais pas d’option rotate ou timeout dans mon routeur).
Et pour le sous-réseau de base, le normal.

Là aussi, je ne sais pas pourquoi, mais le routeur me connecte tout le monde sur ce nouveau sous-réseau quand une demande dhcp arrive…

Je peux juste jouer avec les mapping adresse Mac et adresse Ip via l’interface ‘serveur dhcp’ du routeur et limiter la plage Dhcp au nombre d’ordis qui peuvent se connecter à mondomaine.
Très bien tant qu’il n’y a pas de nouvel ordi ou bien tant qu’un invité ne passe et n’ai besoin de se connecter à mondomaine et accéder aux services fournis (ce qui arrive régulièrement).

Il est vrai que je peux leur apprendre comment faire pour ajouter la nouvelle machine dans l’interface du routeur, comment récupérer l’adresse Mac, etc, mais c’est du bidouillage et j’espère trouver une solution un peu plus pro.

J’ai aussi la solution de petits scripts à éxécuter quand on est connecté sur mon lan pour mettre à jour le resolv.conf selon mes besoins, mais là encore, c’est du bidouillage et un peu la solution de dernier ressort… :blush:

Bref, je tourne un peu en rond.

Il existe peut-être un solution plus simple, mais je n’ai pas (encore) trouvé.

Kenny

#6

[quote=“thomas.leclerc”]et si vous laissiez tomber les serveurs dns de vos FAI ?

installez bind avec sa conf par defaut
et dans resolv.conf pointez le 127.0.0.1

et voila vous interrogez directement les serveurs qui vont bien, sans vous soucier de vos FAI et de leurs dns menteurs

:smt006[/quote]
Attention pour le cas d’orange, à l’époque de wanadoo (quand les gens de FT ne se suicidaient pas et qu’il y avait un semblant de service public), smtp.wanadoo.fr ne donnait pas la même IP suivant le DNS de wanadoo et un autre DNS…

#7

Merci pour ses réponses à côté de la question :unamused:

Ce serait sympa d’éviter ça.

Merci

Kenny

#8

J’ai essayé resolvconf (ils auraient pu prendre un autre nom :laughing: ) et on peut aisément manipuler le resolv.conf, les options rotate et timeout y compris.

Il suffit, sous Debian Lenny, d’editer le fichier /etc/resolvconf/resolv.conf/tail et d’y ajouter:

options rotate
options timeout:1

Cela se met à la fin du fichier resolv.conf.
On peut aussi placer avant via le fichier /etc/resolvconf/resolv.conf/head et au milieu, mais après les infos reçues du serveur dhcp, avec le fichier /etc/resolvconf/resolv.conf/base.

Pour mon cas, le serveur Dhcp sur le lan renvoie:

nameserver 172.19.3.1 (accès routeur, donc nickel pour tout le monde)
nameserver 172.19.99.3 (accès mon serveur Dns Bind)
search mondomaine

Mon serveur Dns n’est utilisé par personne par défaut, donc bien pour les autres entités sur le lan qui ne sont pas dérangées par celui-ci.

Pour ceux qui sont sur mon lan, je rajoute les options rotate et timeout:1 via resolvconf.

Je ne sais pas si c’est un bug ou une feature, mais l’option rotate interroge le 2ème nameserver avant le premier (jusqu’à présent c’était à tous les coups comme ça, et cette option/bug date depuis au moins 2003), et ça m’arrange bien.

Quand mes clients se connectent sur mon lan, ils commencent par interroger mon serveur Dns (gràce à rotate) avant d’essayer le routeur.
Voici le resolv.conf complet obtenu:

nameserver 172.19.3.1
nameserver 172.19.99.3
search mondomaine
options rotate
options timeout:1

Et quand les laptops vont se connecter ailleurs:

nameserver Ip du routeur
options rotate
options timeout:1

D’après mes tests, cela fonctionne nickel aussi. J’avais un peu peur avec l’option timeout à 1, mais jusqu’à présent, aucun problème.
Il est vrai qu’on bouge beaucoup d’un petit réseau local à un autre, donc la demande vers le routeur (client dns) est très rapide.

Finalement, c’est surtout l’option rotate qui est importante. L’option timeout permet, s’il y a un problème avec le serveur Dns, de garder un accès internet fluide.

Bon, c’est quand même pas une solution limpide… Ca reste un peu du bidouillage. :smt003
J’imagine qu’il doit y avoir des serveurs dhcp plus élaboré sur d’autres routeurs.

Pour ma part, c’est surtout prévu pour un environnement d’assoc où c’est plus à la débrouille. Pas trop d’argent à investir dans du matériel pro.

Et pour rappel, c’est intéressant pour le cas où j’ai plusieurs assoc sur le lan et donc qu’il faut créer son petit monde au milieu de ça sans perturber les autres.

Si je suis seul sur le réseau, là y a pas de problème. Juste le serveur Dhcp suffit, mais intervertir les 2 nameserver par rapport à mon exemple plus haut, pas besoin de rotate ou timeout.

Kenny

#9

Une autre solution est de ne pas utiliser network-manager et consorts, mais simplement le service init en configurant la connexion dans /etc/network/interfaces. Il suffit de rajouter une ligne post-up echo -e “options rotate\noptions timeout:1” >> /etc/resolv.conf ou bien echo “nameserver 127.0.0.1” > /etc/resolv.conf. On peut aussi faire un script dans /etc/network/if-up.d, si on veut faire des modifications « post-dhcp » plus conséquentes.

#10

Merci kna.
Et tu as tout à fait raison.

Je me suis finalement dirigé vers cette solution car cela me paraissait un peu trop scabreux comme technique celle du ‘rotate’.

J’ai donc créer un script dans le dossier /etc/network/if-up.d/ qui check la présence de mon serveur sur le lan en comparant son adresse ip et l’adresse Ethernet trouvé à cette adresse, et s’il le trouve, modifie le resolv.conf.
S’il ne le trouve pas, il ne fait rien.

#!/bin/sh

# VARIABLES
ProjectName="monproject"
Gateway="172.19.3.1"
IpAddressServeur="172.19.3.254"
EthAddressServeur="00:11:85:62:53:e9"

NewResolvConfInfo="# RESOLV.CONF GENERATED BY QUENENNI'S SCRIPT IN\n# /etc/networking/if-up.d/QResolvConf\n#\n# This script change the resolv.conf only if you are connected to $ProjectName network\n# It will let your resolv.conf untouched if not\n\n"
NewResolvConf="search mondomaine\nnameserver $IpAddressServeur\nnameserver $Gateway"

# PING D'ABORD SINON ARP RENVOIE AUTO PAS BON
ServeurPingRes="$(ping -n -c 1 $IpAddressServeur)"

# TEST ARP SUR L'ADRESSE DU SERVEUR
ServeurPingRes="$(arp $IpAddressServeur)"

# TEST SI HOSTNAME CORRESPOND A ADRESSE IP
# $RES AURA L'ADRESSE IP COMME VALEUR SI BON, VIDE SI PAS BON
if [ "$(expr match "$ServeurPingRes" ".*${EthAddressServeur}.*")" -gt 0 ]
then
        # ON EST SUR MON RESEAU -> MAJ DU RESOLV.CONF
        echo -e "$NewResolvConfInfo$NewResolvConf" > /etc/resolv.conf
fi

Le ‘ping’ avant la commande ‘arp’ est nécessaire, sinon il renvoie tout le temps ‘unknow host’.

Cela plutôt bien, même avec la connexion wifi.
Et cela ne touche à rien quand je vais me connecter ailleurs.

Je dois juste trouver 5 min pour l’améliorer un peu et faire un test sur le résultat du ping avant de lancer la commande arp.

En attendant de trouver une technique où je ne dois rien mettre sur le client, celle-ci me convient.