Re: PPP et DNS: argh!
On Thu, 2 Nov 2000 15:11:43 +0100,
Charles Goyard <charles.goyard@laposte.net> wrote :
> Salut,
>
> J'utilise chez moi un modem pour me connecter à Internet, soit via wanadoo,
> soit via free.
Indice #1
>
> Avant, tout marchait bien.
> Maintenant (je sais pas ce que j'ai touché...):
[...DNS KO...]
Tiens, tiens... je suis surpris que personne n'ait signalé une
hypothèse très plausible !
A mon avis, c'est presque à coup sûr un problème dû au fait de changer
en vol le resolv.conf (et donc indirectement au fait d'utiliser deux
FAI).
Le problème est qu'un programme demandant une résolution de nom ne
regarde en tout et pour tout qu'une seule fois le contenu de
resolv.conf, et est donc aveugle aux changements ultérieurs. Or,
beaucoup de FAI n'acceptent les requêtes DNS que si elles proviennent
de leur propre domaine.
Donc si je démarre le programme prog, alors que resolv.conf ->
dns.fai1.fr, et que je passe plus tard à FAI2, prog va essayer de
consulter dns.fai1.fr depuis fai2.fr et boum ! : accès refusé. Il me
semble bien que free se comporte ainsi (je jongle avec des accès fac,
free et libertysurf).
C'est idiot, mais c'est comme ça. La solution : ne jamais changer le
resolv.conf.
Le problème, c'est la configuration dynamique avec l'option usepeerdns
qui réécrit le resolv.conf en y mettant les adresses récupérées lors
de la connexion. Debian le fait. Red Hat le fait. Sur ce coup, aucune
n'est meilleure que l'autre : toutes les deux sont idiotes.
Sur ma Red Hat (j'ai une potato sur une partition, en test pour
l'instant), j'avais un temps mis bind en serveur cache, mais c'était
lourd et pas toujours adapté...Ensuite, j'avais bricolé l'équivalent
du /etc/ppp/ip-up.d de la Debian [je l'avais fait sur le modèle du
/etc/profile.d de la RH, qui par contre, n'existe pas sur la Debian.
Surprenant, car c'est exactement le même concept que ip-up.d ???],
où je relançais tous les démons dépendant du réseau à chaque
connexion et après la mise à jour du DNS. Pas forcément très élégant,
mais ça marchait.
Jusqu'à ce que je décortique les fichiers de conf de la Debian pour
voir un peu comment un certain nombres de problèmes liés à PPP sont
traités et que je tombe dans /etc/ppp/ip-up.d/1wwwoffle sur une
référence sur les problèmes liés au fait de relancer wwwoffle. Or si
il y a une raison de relancer wwwoffle, c'est bien suite à un
changement de DNS [J'adore les fichiers de configuration commentés de
Debian. Cela vaut tous les outils de configuration graphique]. Je me
précipite sur /usr/doc/wwwoffle/README.Debian qui m'apprend
l'existence d'un truc génial et tout à fait adapté à cette
utilisation :
dnrd (Domain Name Relay Daemon)!
qui se contente de faire le relais avec les DNS du FAI, sachant que
pour la machine, il tient lieu de DNS à 127.0.0.1.
On a donc le même bénéfice qu'avec bind, sauf que c'est beaucoup plus
simple lorsque l'on change de FAI. Avec bind, il faudrait changer les
forwarders dans le fichier de conf à cause des problèmes mentionnés
plus haut. Avec dnrd, il suffit de lancer une commande du type
dnrd -s IP.NOUVEAU.FAI.1 -s IP.NOUVEAU.FAI.2
lors de l'établissement de la connexion pour se connecter au démon
dnrd en fonctionnement et lui faire changer de DNS cible. J'ai bricolé
ça sur ma Red Hat et ça marche impeccablement.
Je n'ai pas encore testé sur la potato, mais il me semble a priori
qu'il y a un problème dans le paquetage dnrd.
Non seulement, le /etc/ppp/ip-up.d/0dnrd ne marche pas "out of the
box" (lignes à décommenter) mais surtout, le 0dns-up qui est éxécuté
juste derrière entre en conflit puisqu'il s'empresse de faire valser
le resolv.conf : si on installe dnrd, c'est justement pour éviter
cela...
En fait il suffirait (je pense...) de rajouter une ligne du genre
test -f /usr/sbin/dnrd && exit 0 au début de /etc/ppp/ip-up.d/0dns-up
Un rapport de bug à faire ? [C'est marrant, mais je dirais que j'ai
rencontré autant de ces petits bugs pas très graves, mais ennuyants
dans mes tests de la potato que sur ma RH...]
Voilà, j'espère que le message n'a pas été trop long...
Marc
Reply to: