J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu.
En effet, dig (et nslookup) marchent très bien en indicant un serveur en
127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx)
pédalent dans la semoule et n'arrivent pas à résoudre les noms.
Alors que se passe-t-il ?
Je pensais pour pallier au problème (pas sûr que ça marche non plus)
"remettre" les DNS de free et là question
- où mettre ces IP (je ne me souviens plus
- comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les
DNS ont changé ?
J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu. En effet, dig (et nslookup) marchent très bien en indicant un serveur en 127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx) pédalent dans la semoule et n'arrivent pas à résoudre les noms. Alors que se passe-t-il ?
Y'a pas de raison. Si un dig fonctionne bien, je ne vois pas pourquoi ça ne marcherait pas avec le navigateur. Faut quand même se méfier des caches etc. Par exemple j'ai eu des cas où le changement d'une entrée dans /etc/hosts n'était prise en compte qu'une fois le cache vidé. Trêve de bavardages inutiles, parlons peu, parlons bien, parlons ligne de commandes. Que donne tout ça ? (merci de faire juste des copier/coller ;)). cat /etc/resolv.conf dig www.google.fr curl --head https://www.google.fr # Attention, bien vérifier qu'il n'y a _aucune_ instance firefox en cours d'exécution. firefox https://www.google.fr
Je pensais pour pallier au problème (pas sûr que ça marche non plus) "remettre" les DNS de free
Nenni, nenni. ;) Si t'as un bind qui fonctionne avec dig, y'a pas de raison que tu puisses pas l'utiliser pour tout le système. -- François Lafont
Bonjour,
On 12/14/2016 11:25 AM, Jo Engo wrote:
J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu.
En effet, dig (et nslookup) marchent très bien en indicant un serveur en 127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx) pédalent dans la semoule et n'arrivent pas à résoudre les noms.
Alors que se passe-t-il ?
Y'a pas de raison. Si un dig fonctionne bien, je ne vois pas pourquoi ça ne
marcherait pas avec le navigateur. Faut quand même se méfier des caches etc.
Par exemple j'ai eu des cas où le changement d'une entrée dans /etc/hosts
n'était prise en compte qu'une fois le cache vidé.
Trêve de bavardages inutiles, parlons peu, parlons bien, parlons ligne de
commandes. Que donne tout ça ? (merci de faire juste des copier/coller ;)).
J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu. En effet, dig (et nslookup) marchent très bien en indicant un serveur en 127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx) pédalent dans la semoule et n'arrivent pas à résoudre les noms. Alors que se passe-t-il ?
Y'a pas de raison. Si un dig fonctionne bien, je ne vois pas pourquoi ça ne marcherait pas avec le navigateur. Faut quand même se méfier des caches etc. Par exemple j'ai eu des cas où le changement d'une entrée dans /etc/hosts n'était prise en compte qu'une fois le cache vidé. Trêve de bavardages inutiles, parlons peu, parlons bien, parlons ligne de commandes. Que donne tout ça ? (merci de faire juste des copier/coller ;)). cat /etc/resolv.conf dig www.google.fr curl --head https://www.google.fr # Attention, bien vérifier qu'il n'y a _aucune_ instance firefox en cours d'exécution. firefox https://www.google.fr
Je pensais pour pallier au problème (pas sûr que ça marche non plus) "remettre" les DNS de free
Nenni, nenni. ;) Si t'as un bind qui fonctionne avec dig, y'a pas de raison que tu puisses pas l'utiliser pour tout le système. -- François Lafont
Jo Engo
On 12/14/2016 10:25 AM, Jo Engo wrote:
Je pensais pour pallier au problème (pas sûr que ça marche non plus) "remettre" les DNS de free et là question - où mettre ces IP (je ne me souviens plus.
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
- comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les DNS ont changé ?
Je suppose qu'il est inutile de prévenir le noyau, si ? Que va-t-il se passer si je remplace le fichier /etc/resolv.conf par celui de ma cuisine ?
On 12/14/2016 10:25 AM, Jo Engo wrote:
Je pensais pour pallier au problème (pas sûr que ça marche non plus)
"remettre" les DNS de free et là question
- où mettre ces IP (je ne me souviens plus.
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers
/run/resolvconf/resolv.conf
- comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les
DNS ont changé ?
Je suppose qu'il est inutile de prévenir le noyau, si ?
Que va-t-il se passer si je remplace le fichier /etc/resolv.conf par
celui de ma cuisine ?
Je pensais pour pallier au problème (pas sûr que ça marche non plus) "remettre" les DNS de free et là question - où mettre ces IP (je ne me souviens plus.
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
- comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les DNS ont changé ?
Je suppose qu'il est inutile de prévenir le noyau, si ? Que va-t-il se passer si je remplace le fichier /etc/resolv.conf par celui de ma cuisine ?
Francois Lafont
On 12/14/2016 02:07 PM, Jo Engo wrote:
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
Ah ok, t'as cette merdasse de paquet resolvconf d'installé alors. Bon, je dis merdasse mais en fait j'avoue que je ne connais pas trop, ça a peut-être des avantages... perso je le vire systématiquement. Ah, et ta machine est en DHCP aussi ? J'avais pas pigé. Dans ce cas, c'est au niveau, je crois, de /etc/dhcp/dhclient.conf. Qu'on me rectifie si je dis une bêtise mais hélas il n'y a pas de « conf.d/ » ce qui est toujours un peu naze. Il faut que tu modifies ce fichier en ajoutant une ligne du genre : supersede domain-name-servers 127.0.0.1; Puis relancer le dhcp sur ton client. Attention, non testé. -- François Lafont
On 12/14/2016 02:07 PM, Jo Engo wrote:
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
Ah ok, t'as cette merdasse de paquet resolvconf d'installé alors.
Bon, je dis merdasse mais en fait j'avoue que je ne connais pas trop,
ça a peut-être des avantages... perso je le vire systématiquement.
Ah, et ta machine est en DHCP aussi ? J'avais pas pigé.
Dans ce cas, c'est au niveau, je crois, de /etc/dhcp/dhclient.conf.
Qu'on me rectifie si je dis une bêtise mais hélas il n'y a pas
de « conf.d/ » ce qui est toujours un peu naze. Il faut que tu
modifies ce fichier en ajoutant une ligne du genre :
supersede domain-name-servers 127.0.0.1;
Puis relancer le dhcp sur ton client. Attention, non testé.
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
Ah ok, t'as cette merdasse de paquet resolvconf d'installé alors. Bon, je dis merdasse mais en fait j'avoue que je ne connais pas trop, ça a peut-être des avantages... perso je le vire systématiquement. Ah, et ta machine est en DHCP aussi ? J'avais pas pigé. Dans ce cas, c'est au niveau, je crois, de /etc/dhcp/dhclient.conf. Qu'on me rectifie si je dis une bêtise mais hélas il n'y a pas de « conf.d/ » ce qui est toujours un peu naze. Il faut que tu modifies ce fichier en ajoutant une ligne du genre : supersede domain-name-servers 127.0.0.1; Puis relancer le dhcp sur ton client. Attention, non testé. -- François Lafont
ça va être chaud pour faire le copier-coller : linuxmint ne "voit" pas sa propre clé aussi c'est coton pour se passer les copiers/collers. J'ai trouvé un truc : /media/mint/98UUID64 $ cd tmp /media/mint/98UUID64/tmp $ vi commandes /media/mint/98UUID64/tmp $ ls co* commandes config-err-nfCEKZ /media/mint/98UUID64/tmp $ ls -l commandes-rw-r--r-- 1 mint mint 82 Dec 14 13:31 commandes /media/mint/98UUID64/tmp $ cat /etc/passwd|grep mint mint:x:999:999:Live session user,,,:/home/mint:/bin/bash /media/mint/98UUID64/tmp $ sudo chown 1000:1000 commandes et ça resservira dans l'autre sens (en mettant le cas échéant l'owner à 999.
ça va être chaud pour faire le copier-coller : linuxmint ne "voit" pas
sa propre clé aussi c'est coton pour se passer les copiers/collers. J'ai
trouvé un truc :
mint@mint /media/mint/98UUID64 $ cd tmp
mint@mint /media/mint/98UUID64/tmp $ vi commandes
mint@mint /media/mint/98UUID64/tmp $ ls co*
commandes config-err-nfCEKZ
mint@mint /media/mint/98UUID64/tmp $ ls -l commandes-rw-r--r-- 1 mint
mint 82 Dec 14 13:31 commandes
mint@mint /media/mint/98UUID64/tmp $ cat /etc/passwd|grep mint
mint:x:999:999:Live session user,,,:/home/mint:/bin/bash
mint@mint /media/mint/98UUID64/tmp $ sudo chown 1000:1000 commandes
et ça resservira dans l'autre sens (en mettant le cas échéant l'owner à 999.
ça va être chaud pour faire le copier-coller : linuxmint ne "voit" pas sa propre clé aussi c'est coton pour se passer les copiers/collers. J'ai trouvé un truc : /media/mint/98UUID64 $ cd tmp /media/mint/98UUID64/tmp $ vi commandes /media/mint/98UUID64/tmp $ ls co* commandes config-err-nfCEKZ /media/mint/98UUID64/tmp $ ls -l commandes-rw-r--r-- 1 mint mint 82 Dec 14 13:31 commandes /media/mint/98UUID64/tmp $ cat /etc/passwd|grep mint mint:x:999:999:Live session user,,,:/home/mint:/bin/bash /media/mint/98UUID64/tmp $ sudo chown 1000:1000 commandes et ça resservira dans l'autre sens (en mettant le cas échéant l'owner à 999.
Francois Lafont
On 12/14/2016 02:44 PM, Jo Engo wrote:
ça va être chaud pour faire le copier-coller : linuxmint ne "voit" pas sa propre clé aussi c'est coton pour se passer les copiers/collers. J'ai trouvé un truc : /media/mint/98UUID64 $ cd tmp /media/mint/98UUID64/tmp $ vi commandes /media/mint/98UUID64/tmp $ ls co* commandes config-err-nfCEKZ /media/mint/98UUID64/tmp $ ls -l commandes-rw-r--r-- 1 mint mint 82 Dec 14 13:31 commandes /media/mint/98UUID64/tmp $ cat /etc/passwd|grep mint mint:x:999:999:Live session user,,,:/home/mint:/bin/bash /media/mint/98UUID64/tmp $ sudo chown 1000:1000 commandes et ça resservira dans l'autre sens (en mettant le cas échéant l'owner à 999.
Mince alors ! J'ai juste _rien_ compris de A à Z ? Je ne vois pas une once de rapport entre ce que j'avais demandé et toutes ces commandes ci-dessus... Par ailleurs il est question de linuxmint alors que je croyais que c'était Ubuntu dont il était question dans le premier message. Quant à « ne "voit" pas sa propre clé », je ne vois pas ce que ça signifie et encore moins le rapport avec le fait de juste copier d'une console une commande shell et son résultat puis de le coller dans un message sur ce fil de discussion... -- François Lafont
On 12/14/2016 02:44 PM, Jo Engo wrote:
ça va être chaud pour faire le copier-coller : linuxmint ne "voit" pas sa propre clé aussi c'est coton pour se passer les copiers/collers. J'ai trouvé un truc :
mint@mint /media/mint/98UUID64 $ cd tmp
mint@mint /media/mint/98UUID64/tmp $ vi commandes
mint@mint /media/mint/98UUID64/tmp $ ls co*
commandes config-err-nfCEKZ
mint@mint /media/mint/98UUID64/tmp $ ls -l commandes-rw-r--r-- 1 mint mint 82 Dec 14 13:31 commandes
mint@mint /media/mint/98UUID64/tmp $ cat /etc/passwd|grep mint
mint:x:999:999:Live session user,,,:/home/mint:/bin/bash
mint@mint /media/mint/98UUID64/tmp $ sudo chown 1000:1000 commandes
et ça resservira dans l'autre sens (en mettant le cas échéant l'owner à 999.
Mince alors ! J'ai juste _rien_ compris de A à Z ?
Je ne vois pas une once de rapport entre ce que j'avais demandé
et toutes ces commandes ci-dessus... Par ailleurs il est question
de linuxmint alors que je croyais que c'était Ubuntu dont il était
question dans le premier message. Quant à « ne "voit" pas sa propre
clé », je ne vois pas ce que ça signifie et encore moins le rapport
avec le fait de juste copier d'une console une commande shell et son
résultat puis de le coller dans un message sur ce fil de discussion...
ça va être chaud pour faire le copier-coller : linuxmint ne "voit" pas sa propre clé aussi c'est coton pour se passer les copiers/collers. J'ai trouvé un truc : /media/mint/98UUID64 $ cd tmp /media/mint/98UUID64/tmp $ vi commandes /media/mint/98UUID64/tmp $ ls co* commandes config-err-nfCEKZ /media/mint/98UUID64/tmp $ ls -l commandes-rw-r--r-- 1 mint mint 82 Dec 14 13:31 commandes /media/mint/98UUID64/tmp $ cat /etc/passwd|grep mint mint:x:999:999:Live session user,,,:/home/mint:/bin/bash /media/mint/98UUID64/tmp $ sudo chown 1000:1000 commandes et ça resservira dans l'autre sens (en mettant le cas échéant l'owner à 999.
Mince alors ! J'ai juste _rien_ compris de A à Z ? Je ne vois pas une once de rapport entre ce que j'avais demandé et toutes ces commandes ci-dessus... Par ailleurs il est question de linuxmint alors que je croyais que c'était Ubuntu dont il était question dans le premier message. Quant à « ne "voit" pas sa propre clé », je ne vois pas ce que ça signifie et encore moins le rapport avec le fait de juste copier d'une console une commande shell et son résultat puis de le coller dans un message sur ce fil de discussion... -- François Lafont
Jo Engo
Le Wed, 14 Dec 2016 15:04:46 +0100, Francois Lafont a écrit :
juste copier d'une console une commande shell et son résultat puis de le coller dans un message sur ce fil de discussion...
Pour ça, il fallait avoir un résolveur, j'ai maintenant mais je n'ai rien fait, il est tombé en marche comme il était tombé en panne... Donc dis-je ça remarche du coup je n'ai rien à transmettre (et je n'ai plus besoin de linux-mint) -- Le plus court chemin entre deux vérités dans le domaine réel passe par le domaine complexe. -+- Jacques Hadamard -+-
Le Wed, 14 Dec 2016 15:04:46 +0100, Francois Lafont a écrit :
juste copier d'une console une commande shell et son résultat puis de le
coller dans un message sur ce fil de discussion...
Pour ça, il fallait avoir un résolveur, j'ai maintenant mais je n'ai rien
fait, il est tombé en marche comme il était tombé en panne...
Donc dis-je ça remarche du coup je n'ai rien à transmettre (et je n'ai
plus besoin de linux-mint)
--
Le plus court chemin entre deux vérités dans le domaine réel passe par
le domaine complexe.
-+- Jacques Hadamard -+-
Le Wed, 14 Dec 2016 15:04:46 +0100, Francois Lafont a écrit :
juste copier d'une console une commande shell et son résultat puis de le coller dans un message sur ce fil de discussion...
Pour ça, il fallait avoir un résolveur, j'ai maintenant mais je n'ai rien fait, il est tombé en marche comme il était tombé en panne... Donc dis-je ça remarche du coup je n'ai rien à transmettre (et je n'ai plus besoin de linux-mint) -- Le plus court chemin entre deux vérités dans le domaine réel passe par le domaine complexe. -+- Jacques Hadamard -+-
Jean-Baptiste Faure
Le 14/12/2016 à 11:25, Jo Engo a écrit :
[...] Je pensais pour pallier au problème (pas sûr que ça marche non plus) "remettre" les DNS de free et là question - où mettre ces IP (je ne me souviens plus - comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les DNS ont changé ?
Tu peux toujours essayer de faire pareil que si tu voulais remplacer le DNS menteur de ton FAI par un DNS dans lequel tu as confiance. Par exemple : https://www.opennicproject.org/configure-your-dns/how-to-set-up-dns-servers-in-ubuntu-linux/ -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Le 14/12/2016 à 11:25, Jo Engo a écrit :
[...]
Je pensais pour pallier au problème (pas sûr que ça marche non plus)
"remettre" les DNS de free et là question
- où mettre ces IP (je ne me souviens plus
- comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les
DNS ont changé ?
Tu peux toujours essayer de faire pareil que si tu voulais remplacer le
DNS menteur de ton FAI par un DNS dans lequel tu as confiance.
Par exemple :
https://www.opennicproject.org/configure-your-dns/how-to-set-up-dns-servers-in-ubuntu-linux/
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents
[...] Je pensais pour pallier au problème (pas sûr que ça marche non plus) "remettre" les DNS de free et là question - où mettre ces IP (je ne me souviens plus - comment prévenir le noyau (c'est lui le fautif j'en suis sûr) que les DNS ont changé ?
Tu peux toujours essayer de faire pareil que si tu voulais remplacer le DNS menteur de ton FAI par un DNS dans lequel tu as confiance. Par exemple : https://www.opennicproject.org/configure-your-dns/how-to-set-up-dns-servers-in-ubuntu-linux/ -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents
denis.paris
Le 14/12/2016 à 14:07, Jo Engo a écrit :
Je suppose qu'il est inutile de prévenir le noyau, si ?
??? Si tu connais son 06 tu peux tout de même tenter de lui envoyer un SMS ;)
Le 14/12/2016 à 14:07, Jo Engo a écrit :
Je suppose qu'il est inutile de prévenir le noyau, si ?
???
Si tu connais son 06 tu peux tout de même tenter de lui envoyer un SMS ;)
Je suppose qu'il est inutile de prévenir le noyau, si ?
??? Si tu connais son 06 tu peux tout de même tenter de lui envoyer un SMS ;)
Pascal Hambourg
Le 14/12/2016 à 14:30, Francois Lafont a écrit :
On 12/14/2016 02:07 PM, Jo Engo wrote:
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
Ah ok, t'as cette merdasse de paquet resolvconf d'installé alors. Bon, je dis merdasse mais en fait j'avoue que je ne connais pas trop, ça a peut-être des avantages... perso je le vire systématiquement.
Resolvconf se limite à gérer le contenu de /etc/resolv.conf. C'est très utile quand on il y a plusieurs programmes qui configurent des DNS (dhclient, rdnssd, openvpn...) sans quoi chacun écraserait le contenu de /etc/resolv.conf sans se soucier des autres. Mais à part ça, resolvconf n'intervient pas dans le processus de résolution de nom donc n'explique pas la différence observée.
Le 14/12/2016 à 14:30, Francois Lafont a écrit :
On 12/14/2016 02:07 PM, Jo Engo wrote:
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
Ah ok, t'as cette merdasse de paquet resolvconf d'installé alors.
Bon, je dis merdasse mais en fait j'avoue que je ne connais pas trop,
ça a peut-être des avantages... perso je le vire systématiquement.
Resolvconf se limite à gérer le contenu de /etc/resolv.conf. C'est très
utile quand on il y a plusieurs programmes qui configurent des DNS
(dhclient, rdnssd, openvpn...) sans quoi chacun écraserait le contenu de
/etc/resolv.conf sans se soucier des autres.
Mais à part ça, resolvconf n'intervient pas dans le processus de
résolution de nom donc n'explique pas la différence observée.
pfff /etc/resolv.conf mais ça ne m'aide pas : c'est un lien vers /run/resolvconf/resolv.conf
Ah ok, t'as cette merdasse de paquet resolvconf d'installé alors. Bon, je dis merdasse mais en fait j'avoue que je ne connais pas trop, ça a peut-être des avantages... perso je le vire systématiquement.
Resolvconf se limite à gérer le contenu de /etc/resolv.conf. C'est très utile quand on il y a plusieurs programmes qui configurent des DNS (dhclient, rdnssd, openvpn...) sans quoi chacun écraserait le contenu de /etc/resolv.conf sans se soucier des autres. Mais à part ça, resolvconf n'intervient pas dans le processus de résolution de nom donc n'explique pas la différence observée.
Pascal Hambourg
Le 14/12/2016 à 12:51, Francois Lafont a écrit :
On 12/14/2016 11:25 AM, Jo Engo wrote:
J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu.
Quel "bind light" ? Tu parles de lwresd, le "lightweight resolver daemon" de BIND ?
En effet, dig (et nslookup) marchent très bien en indicant un serveur en 127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx) pédalent dans la semoule et n'arrivent pas à résoudre les noms. Alors que se passe-t-il ?
Y'a pas de raison. Si un dig fonctionne bien, je ne vois pas pourquoi ça ne marcherait pas avec le navigateur.
Ben si, il y a une raison : dig, nslookup ou host communiquent directement avec les serveurs DNS figurant dans /etc/resolv.conf (ou spécifié explicitement dans la commande), alors que les programmes normaux font appel au résolveur de la glibc pour la résolution de noms, qui ne se limite pas au DNS mais consulte /etc/hosts et peut notamment utiliser mDNS (multicast DNS de Zeroconf) et la résolution de nom Windows Netbios/WINS avec les modules NSS qui vont bien. C'est configuré dans /etc/nsswitch.conf. Et devinez quoi ? lwres a un module NSS pour le résolveur de la glibc.
Le 14/12/2016 à 12:51, Francois Lafont a écrit :
On 12/14/2016 11:25 AM, Jo Engo wrote:
J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu.
Quel "bind light" ? Tu parles de lwresd, le "lightweight resolver
daemon" de BIND ?
En effet, dig (et nslookup) marchent très bien en indicant un serveur en 127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx) pédalent dans la semoule et n'arrivent pas à résoudre les noms.
Alors que se passe-t-il ?
Y'a pas de raison. Si un dig fonctionne bien, je ne vois pas pourquoi ça ne
marcherait pas avec le navigateur.
Ben si, il y a une raison : dig, nslookup ou host communiquent
directement avec les serveurs DNS figurant dans /etc/resolv.conf (ou
spécifié explicitement dans la commande), alors que les programmes
normaux font appel au résolveur de la glibc pour la résolution de noms,
qui ne se limite pas au DNS mais consulte /etc/hosts et peut notamment
utiliser mDNS (multicast DNS de Zeroconf) et la résolution de nom
Windows Netbios/WINS avec les modules NSS qui vont bien. C'est configuré
dans /etc/nsswitch.conf.
Et devinez quoi ? lwres a un module NSS pour le résolveur de la glibc.
J'ai un souci bizarre avec le bind light qu'il y a avec ubuntu.
Quel "bind light" ? Tu parles de lwresd, le "lightweight resolver daemon" de BIND ?
En effet, dig (et nslookup) marchent très bien en indicant un serveur en 127.0.0.1 tandis que les applis (firefox, thunderbird, pan, lynx) pédalent dans la semoule et n'arrivent pas à résoudre les noms. Alors que se passe-t-il ?
Y'a pas de raison. Si un dig fonctionne bien, je ne vois pas pourquoi ça ne marcherait pas avec le navigateur.
Ben si, il y a une raison : dig, nslookup ou host communiquent directement avec les serveurs DNS figurant dans /etc/resolv.conf (ou spécifié explicitement dans la commande), alors que les programmes normaux font appel au résolveur de la glibc pour la résolution de noms, qui ne se limite pas au DNS mais consulte /etc/hosts et peut notamment utiliser mDNS (multicast DNS de Zeroconf) et la résolution de nom Windows Netbios/WINS avec les modules NSS qui vont bien. C'est configuré dans /etc/nsswitch.conf. Et devinez quoi ? lwres a un module NSS pour le résolveur de la glibc.
