Depuis Buster, je n'ai plus de résolution DNS sur le serveur DHCP/DNS
lui même et uniquement pour les adresses du réseau local. Depuis les
clients, tout est ok.
# 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.1.1
nameserver 192.168.0.2
search home homeg.lan
192.168.1.1 est ma box et 192.168.0.2 est mon serveur DNS/DHCP
# ping skeleton
ping: skeleton: Nom ou service inconnu
;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: mar. août 20 00:42:34 CEST 2019
;; MSG SIZE rcvd: 26
Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec
de la résolution ne passe pas la main au serveur DNS local ?
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel Huhardeaux
Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :
Le 20/08/19 à 00:47, Migrec a écrit :
Ça peut paraître logique car la box n'a pas connaissance de mon réseau local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec de la résolution ne passe pas la main au serveur DNS local ?
Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne répond pas. Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.
Ou alors les nameserver sont interrogés en même temps et la réponse du 1er répondant est utilisée.
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
C'est donc tout à fait logique ;-) Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera plus efficace (celui des box laissant parfois à désirer…)
+1 -- Daniel
Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :
Le 20/08/19 à 00:47, Migrec <mic.grentz@online.fr> a écrit :
Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec
de la résolution ne passe pas la main au serveur DNS local ?
Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne répond pas.
Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.
Ou alors les nameserver sont interrogés en même temps et la réponse du
1er répondant est utilisée.
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
C'est donc tout à fait logique ;-)
Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera plus efficace
(celui des box laissant parfois à désirer…)
Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :
Le 20/08/19 à 00:47, Migrec a écrit :
Ça peut paraître logique car la box n'a pas connaissance de mon réseau local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec de la résolution ne passe pas la main au serveur DNS local ?
Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne répond pas. Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.
Ou alors les nameserver sont interrogés en même temps et la réponse du 1er répondant est utilisée.
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
C'est donc tout à fait logique ;-) Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera plus efficace (celui des box laissant parfois à désirer…)
+1 -- Daniel
Migrec
Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :
Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :
Le 20/08/19 à 00:47, Migrec a écrit :
Ça peut paraître logique car la box n'a pas connaissance de mon réseau local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec de la résolution ne passe pas la main au serveur DNS local ?
Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne répond pas. Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.
Ou alors les nameserver sont interrogés en même temps et la réponse du 1er répondant est utilisée.
Visiblement, le premier répond que le nom n'existe pas.
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
C'est donc tout à fait logique ;-) Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera plus efficace (celui des box laissant parfois à désirer…)
Quand je dis celui de la box, c'est celui de mon FAI en fait. Mon serveur obtient son IP en DHCP depuis la box et le DNS est fournit avec. Avant la mise à jour, ça fonctionnait bien, j'ai du modifier un paramètre DHCP/DNS mais je ne sais pas lequel. PS : désolé de ne pas avoir répondu aux autres messages, je ne les ai pas tous eu (bounce). -- Migrec
Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :
Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :
Le 20/08/19 à 00:47, Migrec <mic.grentz@online.fr> a écrit :
Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi
l'échec
de la résolution ne passe pas la main au serveur DNS local ?
Parce qu'il me semble que la résolution n'utilise le 2e dns que si le
1er ne répond pas.
Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.
Ou alors les nameserver sont interrogés en même temps et la réponse du
1er répondant est utilisée.
Visiblement, le premier répond que le nom n'existe pas.
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
C'est donc tout à fait logique ;-)
Mais si tu as un resolver local, tu ne devrais utiliser que celui-là,
ce sera plus efficace
(celui des box laissant parfois à désirer…)
Quand je dis celui de la box, c'est celui de mon FAI en fait. Mon
serveur obtient son IP en DHCP depuis la box et le DNS est fournit avec.
Avant la mise à jour, ça fonctionnait bien, j'ai du modifier un
paramètre DHCP/DNS mais je ne sais pas lequel.
PS : désolé de ne pas avoir répondu aux autres messages, je ne les ai
pas tous eu (bounce).
--
Migrec
Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :
Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :
Le 20/08/19 à 00:47, Migrec a écrit :
Ça peut paraître logique car la box n'a pas connaissance de mon réseau local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec de la résolution ne passe pas la main au serveur DNS local ?
Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne répond pas. Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.
Ou alors les nameserver sont interrogés en même temps et la réponse du 1er répondant est utilisée.
Visiblement, le premier répond que le nom n'existe pas.
Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.
C'est donc tout à fait logique ;-) Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera plus efficace (celui des box laissant parfois à désirer…)
Quand je dis celui de la box, c'est celui de mon FAI en fait. Mon serveur obtient son IP en DHCP depuis la box et le DNS est fournit avec. Avant la mise à jour, ça fonctionnait bien, j'ai du modifier un paramètre DHCP/DNS mais je ne sais pas lequel. PS : désolé de ne pas avoir répondu aux autres messages, je ne les ai pas tous eu (bounce). -- Migrec
Pascal Hambourg
Le 21/08/2019 à 13:05, Daniel Huhardeaux a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :
Ou alors les nameserver sont interrogés en même temps et la réponse du 1er répondant est utilisée.
Non.
Si. Exemple avec dnsmasq: si on ne met pas strict-order celui ci interroge tous les serveurs qui sont up et prend la réponse du 1er serveur qui a répondu.
Je parlais du résolveur de la libc utilisé par les programmes, pas d'un serveur DNS récursif.
Le 21/08/2019 à 13:05, Daniel Huhardeaux a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :
Ou alors les nameserver sont interrogés en même temps et la réponse
du 1er répondant est utilisée.
Non.
Si. Exemple avec dnsmasq: si on ne met pas strict-order celui ci
interroge tous les serveurs qui sont up et prend la réponse du 1er
serveur qui a répondu.
Je parlais du résolveur de la libc utilisé par les programmes, pas d'un
serveur DNS récursif.
Le 21/08/2019 à 13:05, Daniel Huhardeaux a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :
Ou alors les nameserver sont interrogés en même temps et la réponse du 1er répondant est utilisée.
Non.
Si. Exemple avec dnsmasq: si on ne met pas strict-order celui ci interroge tous les serveurs qui sont up et prend la réponse du 1er serveur qui a répondu.
Je parlais du résolveur de la libc utilisé par les programmes, pas d'un serveur DNS récursif.
Pascal Hambourg
Le 21/08/2019 à 10:00, Migrec a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Conclusion : tous les DNS mentionnés dans resolv.conf doivent être équivalents.
Merci pour ces précisions. Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf.
Non. Ton problème est lié au fait que resolv.conf contient l'adresse d'un serveur DNS qui ne fournit pas les bonnes réponses. Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf sont censés être équivalents et fournir les mêmes réponses, donc l'ordre ne devrait pas avoir d'importance.
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier l'ordre. Ça semble lié au montage des interfaces réseau. Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 (et vice-versa). De cette façon, c'est ok.
Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne fournit pas les bonnes réponses, il ne doit pas être inscrit dans resolv.conf. dhclient (request, supersede, prepend) et NetworkManager (méthode : "adresses automatiques uniquement") ont des options pour l'empêcher.
Le 21/08/2019 à 10:00, Migrec a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Conclusion : tous les DNS mentionnés dans resolv.conf doivent être
équivalents.
Merci pour ces précisions.
Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf.
Non. Ton problème est lié au fait que resolv.conf contient l'adresse
d'un serveur DNS qui ne fournit pas les bonnes réponses.
Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf
sont censés être équivalents et fournir les mêmes réponses, donc l'ordre
ne devrait pas avoir d'importance.
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier
l'ordre. Ça semble lié au montage des interfaces réseau.
Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0
(et vice-versa). De cette façon, c'est ok.
Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne
fournit pas les bonnes réponses, il ne doit pas être inscrit dans
resolv.conf. dhclient (request, supersede, prepend) et NetworkManager
(méthode : "adresses automatiques uniquement") ont des options pour
l'empêcher.
Conclusion : tous les DNS mentionnés dans resolv.conf doivent être équivalents.
Merci pour ces précisions. Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf.
Non. Ton problème est lié au fait que resolv.conf contient l'adresse d'un serveur DNS qui ne fournit pas les bonnes réponses. Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf sont censés être équivalents et fournir les mêmes réponses, donc l'ordre ne devrait pas avoir d'importance.
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier l'ordre. Ça semble lié au montage des interfaces réseau. Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 (et vice-versa). De cette façon, c'est ok.
Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne fournit pas les bonnes réponses, il ne doit pas être inscrit dans resolv.conf. dhclient (request, supersede, prepend) et NetworkManager (méthode : "adresses automatiques uniquement") ont des options pour l'empêcher.
Migrec
Le 21/08/2019 à 20:42, Pascal Hambourg a écrit :
Le 21/08/2019 à 10:00, Migrec a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Conclusion : tous les DNS mentionnés dans resolv.conf doivent être équivalents.
Merci pour ces précisions. Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf.
Non. Ton problème est lié au fait que resolv.conf contient l'adresse d'un serveur DNS qui ne fournit pas les bonnes réponses. Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf sont censés être équivalents et fournir les mêmes réponses, donc l'ordre ne devrait pas avoir d'importance.
En fait j'ai ceci : INTERNET <-----> LIVEBOX <-------> (enp3s0) SERVEUR (enp2s0) <-------> ROUTEUR <----------------> POINT D'ACCES WIFI La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit son bail DHCP. Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans le resolv.conf. Ça me paraissait pas mal car si mon serveur DNS est down, celui de la box fait au moins la résolution "externe", non ?
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier l'ordre. Ça semble lié au montage des interfaces réseau. Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 (et vice-versa). De cette façon, c'est ok.
Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne fournit pas les bonnes réponses, il ne doit pas être inscrit dans resolv.conf. dhclient (request, supersede, prepend) et NetworkManager (méthode : "adresses automatiques uniquement") ont des options pour l'empêcher.
Entendu mais ça dépasse ce que je peux mettre en œuvre. -- Migrec
Le 21/08/2019 à 20:42, Pascal Hambourg a écrit :
Le 21/08/2019 à 10:00, Migrec a écrit :
Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :
Conclusion : tous les DNS mentionnés dans resolv.conf doivent être
équivalents.
Merci pour ces précisions.
Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf.
Non. Ton problème est lié au fait que resolv.conf contient l'adresse
d'un serveur DNS qui ne fournit pas les bonnes réponses.
Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf
sont censés être équivalents et fournir les mêmes réponses, donc
l'ordre ne devrait pas avoir d'importance.
En fait j'ai ceci :
INTERNET <-----> LIVEBOX <-------> (enp3s0) SERVEUR (enp2s0) <------->
ROUTEUR <----------------> POINT D'ACCES WIFI
La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle
indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit
son bail DHCP.
Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans
le resolv.conf.
Ça me paraissait pas mal car si mon serveur DNS est down, celui de la
box fait au moins la résolution "externe", non ?
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier
l'ordre. Ça semble lié au montage des interfaces réseau.
Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en
enp3s0 (et vice-versa). De cette façon, c'est ok.
Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il
ne fournit pas les bonnes réponses, il ne doit pas être inscrit dans
resolv.conf. dhclient (request, supersede, prepend) et NetworkManager
(méthode : "adresses automatiques uniquement") ont des options pour
l'empêcher.
Entendu mais ça dépasse ce que je peux mettre en œuvre.
Conclusion : tous les DNS mentionnés dans resolv.conf doivent être équivalents.
Merci pour ces précisions. Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf.
Non. Ton problème est lié au fait que resolv.conf contient l'adresse d'un serveur DNS qui ne fournit pas les bonnes réponses. Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf sont censés être équivalents et fournir les mêmes réponses, donc l'ordre ne devrait pas avoir d'importance.
En fait j'ai ceci : INTERNET <-----> LIVEBOX <-------> (enp3s0) SERVEUR (enp2s0) <-------> ROUTEUR <----------------> POINT D'ACCES WIFI La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit son bail DHCP. Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans le resolv.conf. Ça me paraissait pas mal car si mon serveur DNS est down, celui de la box fait au moins la résolution "externe", non ?
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier l'ordre. Ça semble lié au montage des interfaces réseau. Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 (et vice-versa). De cette façon, c'est ok.
Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne fournit pas les bonnes réponses, il ne doit pas être inscrit dans resolv.conf. dhclient (request, supersede, prepend) et NetworkManager (méthode : "adresses automatiques uniquement") ont des options pour l'empêcher.
Entendu mais ça dépasse ce que je peux mettre en œuvre. -- Migrec
Pascal Hambourg
Le 21/08/2019 à 23:17, Migrec a écrit :
La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit son bail DHCP. Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans le resolv.conf. Ça me paraissait pas mal car si mon serveur DNS est down, celui de la box fait au moins la résolution "externe", non ?
Dans ce cas il faut faire en sorte que le DNS de la box soit positionné après le DNS local dans resolv.conf, et ce de façon fiable (donc pas en réordonnant les interfaces). Il me semble que resolvconf qui gère ton resolv.conf a des possibilités dans ce sens.
Le 21/08/2019 à 23:17, Migrec a écrit :
La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle
indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit
son bail DHCP.
Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans
le resolv.conf.
Ça me paraissait pas mal car si mon serveur DNS est down, celui de la
box fait au moins la résolution "externe", non ?
Dans ce cas il faut faire en sorte que le DNS de la box soit positionné
après le DNS local dans resolv.conf, et ce de façon fiable (donc pas en
réordonnant les interfaces). Il me semble que resolvconf qui gère ton
resolv.conf a des possibilités dans ce sens.
La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit son bail DHCP. Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans le resolv.conf. Ça me paraissait pas mal car si mon serveur DNS est down, celui de la box fait au moins la résolution "externe", non ?
Dans ce cas il faut faire en sorte que le DNS de la box soit positionné après le DNS local dans resolv.conf, et ce de façon fiable (donc pas en réordonnant les interfaces). Il me semble que resolvconf qui gère ton resolv.conf a des possibilités dans ce sens.
