Bonjour,
J’ai deux serveurs de noms 192.168.1.18 (primaire) et 192.168.1.19 (secondaire).
Lorsque je coupe le primaire, Jeedom ne semble pas utiliser le secondaire alors qu’en SSH il répond bien.
Avec dig:
;; ANSWER SECTION:
cxx.yyyyyy.fr. 604800 IN A 192.168.1.84
;; Query time: 0 msec
;; SERVER: 192.168.1.19#53(192.168.1.19)
;; WHEN: Fri Apr 17 13:49:03 CEST 2026
;; MSG SIZE rcvd: 94
Bonjour
Il me semble que jeedom utilise le DNS IP public de ta box, et pas les les serveur dns local.
Mais je me trompe peut d’être.
Lorsque le primaire est en service, Jeedom l’utilise bien puisque la résolution des noms locaux est bien effectuée.
C’est bizarre par ce que je ne vois pas comment le nom domaine de jeedom voir ip dns en 192.168.x.x
A chacun nos soucis de DNS. Pour moi, c’est le contraire, Jeedom utilise parfois le secondaire même quand le primaire est up.
Chez toi, tu veux dire que debian utilise bien le second NS quand il n’y a pas le premier, mais pas Jeedom ou certains plugins?
Attention, on parle ici de serveurs DNS et non pas des « DNS de Jeedom » qui est sémantiquement une drôle d’expression.
Oui, c’est ce que je constate avec le plugin-proxmox.
Cela dépend du routeur ou box, pas de Jeedom.
Par défaut, la carte réseau d’un Jeedom est en DHCP. Elle prend ce que lui offre le routeur.
Certains routeurs transmettent les DNS qu’ils ont eux mêmes reçu du FAI, d’autre transmettent leur propre adresse locale comme NS et d’autres permettent de choisir.
Par exemple, le mien permet de choisir :
Je n’ai pas compris ce que tu as voulu dire.
Curieux que le plugin ne laisse pas faire Debian pour le réseau.
Probablement un truc en dur dans le plugin qui force l’utilisation du premier NS?
Il n’y a rien ni dans le core, ni dans un plugin, qui force l’utilisation d’un ns, évidement !
c’est l’os qui gère.
curieux de d’abord supposer le contraire d’abord avant de se demander où est le problème alors que la logique voudrait que ca soit bien l’os
Je veux bien ton analyse du soucis.
L’OS gère et selon que c’est Jeedom ou SSH qui demande, il ne gère pas pareil?
Du coup ça veut dire le second dns 192.168.1.19 ne connais pas le nom domaine de jeedom.
Non c’est bon je viens de comprendre. Mais moi par exemple les serveur dns fai free est 212.27.40.240 / 212.27.40.241 alors je ne comprend pas le serveur dns en local.
En ssh regarde si tu a bien les deux dns:
cat /etc/resolv.conf
cat /etc/resolv.conf
domain xxx.fr
search xxx.fr
nameserver 192.168.1.18
nameserver 192.168.1.19
Salut,
Sous Linux, si le 1er serveur DNS de /etc/resolv.conf est disponible, il est utilisé. Le 2eme ne l’ai que si le 1er arrive en timeout.
Mais pour Jeedom, à mon avis c’est lié au fait que les processus PHP sont démarrés et traitent énormément de requêtes avant d’être potentiellement tués et restart.
Je dirais bien que c’est lors du démarrage du processus que le DNS est vérifié et utilisé. Tant que le processus PHP ne redémarre pas je pense qu’il utilise le serveur DNS qui avait bien répondu lors de son démarrage et il reste là dessus.
Tu devrais pouvoir le constater si tu reboot Jeedom après avoir éteint ton DNS1 => ça doit basculer sur le DNS2
A mon avis il n’y a pas grand chose à faire sauf à utiliser un serveur DNS local (donc 127.0.0.1) qui se charge de faire du cache et qui interroge lui même les DNS1 & DNS2.
Pour info, l’Atlas est configuré comme cela de base.
cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search .
resolvectl status
Global
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.5
DNS Servers: 192.168.1.5 192.168.1.1
Link 3 (wlan0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.5
DNS Servers: 192.168.1.5 192.168.1.1
Merci pour cette piste, mais le reboot de Jeedom avec le primaire éteint donne le même résultat.
Si le comportement est différent, c’est que Jeedom n’utilise pas le même NS que dig.
Non?
Dig fall back sur le 2 alors que Jeedom demande à l’os (quel système?) et reste coincé sur le 1.