Problème avec resolvconf / resolv.conf

Support Debian
#1

Voilà,
pendant la levée d’un tunnel PPTP, j’utilise un script “ifup” à moi qui met à jour les routes, lève le pare-feu et le sniffing, déclenche des “fetchmail”, etc…
Avant, j’ai mon resolv.conf (bien lié symboliquement vers le fichier de resolvconf) comme ca:

emeraude:/home/console# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.xxx.xxx
search maison.ntec.lan

L’option “usepeerdns” de pppd ne donnant rien chez moi, dans le script, j’utilise resolvconf pour mettre à jour ma résolution de noms de la manière suivante:

<...>
cat <<EOT | resolvconf -a ${IFNAME}
nameserver 192.168.yyy.yyy
search client.lan
EOT
<...>

aprés execution du script je retrouve bien

emeraude:/home/console# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.xxx.xxx
nameserver 192.168.yyy.yyy
search maison.ntec.lan client.lan

pourtant, si je fais un “host -a machin” ou un “host -a machin.client.lan” pour un client existant et réferencé sur le réseau distant, je n’ai que des réponses de type:

emeraude:/home/console# host -a bidon
Trying "bidon.maison.ntec.lan"
Trying "bidon.client.lan"
Trying "bidon"
Host bidon not found: 3(NXDOMAIN)
Received 101 bytes from 192.168.xxx.xxx#53 in 130 ms

ce qui semble montrer que seul mon dns local est interrogé, mais qu’il prend bien les suffixes de recherche.

pourquoi pas mon dns secondaire, alors, à votre avis ? :confused:

#2

je vais ptet dire une connerie, mais il me semble que le dns secondaire est conrtacte uniquement si le primaire est injoignable, or la tu recois bien une reponse de ton dns primaire, donc host ne va pas plus loin

#3

C’est aussi mon approche: “je vais peut etre dire une connerie”, :slightly_smiling: mais il me semble que ce comportement de ne consulter que le dns primaire n’est pas une fatalité: le client dns windows consulte tous ses dns, dans l’ordre de déclaratiion, jusqu’à ce qu’il ait une réponse, ou qu’il ait épuisé tous ses serveurs.
Linux doit bien savoir faire ca.
Ma question s’affine donc: est il possible de configurer le resolver pour qu’il fasse des requètes successives, en cas d’échec, sur chacun de ses dns ? Si oui, bien sûr, comment ?
mon but est de pouvoir avoir la resolution de noms branchée sur mes dns distants pour résoudre les noms/adresses privés à partir du moment ou mes tunnels sont up.
Je pourrais configurer un dns sur la machine cliente et mettre a jour sa config pour déclarer les nouveaux serveurs comme relais (ou recursifs ? je me trompe tt le tps), lors de la levée des tunnels, mais ca me parait un peu barbare et couteux de faire recharger sa config à mon dns à chaque levée de tunnel.
L’autre solution, et de ttes les manières je vais avoir besoin de le faire, c’est de déclarer “en dur” ces dns distants (le but est de diffuser l’active directory).
En tout état de cause, j’ai un dns sur ma machine pour mes clients LAN (2) et je ne veux pas polluer leur résolution quand je lève des tunnels pour mon usage personnel (ma compagne n’a pas besoin de voir les réseaux de mes clients)… :wink:
Il doit y avoir plus simple…