Mise a jour 2026.9.2 home assistant

Alors, toujours si je ne dis pas de bêtise :
Home Assistant utilise Alpine Linux pour beaucoup de ses conteneurs, et Alpine suit strictement la RFC DNS : si la requête AAAA (IPv6) reçoit un statut d'erreur (au lieu d'un NOERROR avec zéro réponse), Alpine considère que le domaine entier ne peut être résolu, même si la requête A (IPv4) a parfaitement réussi

ça tombe bien puisque dans mon cas, j'ai désactivé l'ipV6 de ma config de box.

Sur vos box, avez vous l'ipV6 actif ou pas ???? Il est aussi possible de forcer l'utilisation du serveur dns pour l'ipv6, directement dans la box, ce qui permet de n'utiliser les dns externe que dans des cas précis et non systématiquement.

dig @192.168.1.1 _checkdns.home-assistant.io +noall +comments +answer AAAA
dig @192.168.1.1 files.pythonhosted.org +noall +comments +answer AAAA
dig @192.168.1.1 files.pythonhosted.org +noall +comments +answer A

bizarrement ce test donne une réponse qui montre que la freebox répond parfaitement aussi bien en ipV6 et en ipV4 (même si l'ipv6 est toujours désactivé dans mon cas).

alors oui, forcer un dns dans la config HA semble régler le problème, mais on ne sait toujours pas pourquoi, et surtout malgré ce que disent certains, la freebox ne semble pas être en cause

Le dns de la freebox est malheureusement bien en cause. Il repond donc les dns de secours ne se declanche pas.
Il est incapable de gèrer le retour volumineux du domaine. La reponse est tronquée il y a blocage.

On passe par un autre dns tout est bon ok. Et si free n'était pas en cause d'autre opérateur serait aussi concerné non ?

Tu sembles ne pas comprendre ce je dis depuis le début : pas la peine de mettre des dns public en premier choix comme des bourins les mettre après la box suffit au pire si le dns fai envoie un truc non exploitable les dns public seront interrogés

Donc pas besoin de mettre de dnd Public devant la box..

La planète nous remerciera (dns fai moins consommateur au final)

C'est la pratique à adopter et ça m'étonnerait pas qu'il soit interdit ou déprécié à des gros trucs comme ha de d'abord taper sur des dns public par leur politique d'usage...

Pour trancher la question faudrait que quelqu'un prenne la peine de récupérer un retour dns pour le comparer avec la norme

Le plus probable c'est qu'il y a effectivement un beug dans cette version de ha dans la gestion de redondance dns qui auparavant masqué le pb de dns free

Ça m'étonnerait que ha considère la réponse comme ok sinon le fait de paramétrer des dns derrière le premier choix de ma box ne résoudrait pas le pb

En quoi c'est moins consommateur au final ?

J'ai 2 intégrations cassées suite à la mise à jour 9.1 vers 9.2. ecoflow et dreame_vaccum. C'est la première fois que ça m'arrive.

Un grand MERCI, depuis hier j'étais en galère !!

pour plusieurs raisons, le routage est plus court, on fait appel a plus de cache à plusieurs niveaux au final...
en résumé on passe par un chemin réseau plus court et on sollicite moins de serveurs

Ouais on parle de DNS ... Cette conversation a au moins cramé les ressources nécessaires pour 12 mois d'appels DNS ... Bref ...

un système domotique a une grosse conso de dns, surtout quand y a pleins de modules cloud qui tournent... et c'est de toute façon une mauvaise pratique j'ai seulement donné l'exemple d'une bonne pratique

pour l'instant le pb est seulement contourné pas résolu, c'est pas normal de devoir manuellement mettre des dns alternatifs apres la maj

Bonjour, peut tu m'expliquer où et comment rentrer cette commande. Je débute sur HA. Merci

Bonjour,
Te complique pas la vie, vas dans paramètres/système / réseau.

ça fait tout de suite moins stylé en passant par l'ui que de taper une commande linux à rallonge :joy:

Le comportement de la FreeBox dans ce cas est, à première vue, normal :

L'interrogation porte sur le domaine pythonhosted.org, il n'y a pas d'enregistrement A ni AAAA pour ce domaine. Le serveur DNS se contente de retourner le CNAME.

C'est au résolveur DNS de poursuivre en interrogeant sur le CNAME.

Certains serveurs DNS effectuent ces requêtes récursives, mais ce n'est pas obligatoire.

Vérifications (192.168.xxx.xxx est l'IP de ma FreeBOX)

  • depuis Windows : nslookup files.pythonhosted.org 192.168.xxx.xxx retourne le CNAME, les 4 enregistrements A et les 4 enregistrements AAAA; l'analyse montre qu'après récupération du CNAME, une nouvelle requête est effectuée pour obtenir les adresses
  • depuis un Linux Debian : dig @192.168.xxx.xxx192.168.xxx.xxx files.pythonhosted.org retourne uniquement le CNAME alors que la requête par nslookup retourne bien le CNAME et les adresses comme sous Windows

Le problème est donc bien côté résolveur mais il ne se manifeste qu'avec les serveurs DNS qui retournent uniquement le CNAME (dont celui des FreeBOX qui n'est probablement pas le seul)

Peut-être que nous sommes tellement peu nombreux à avoir un dns comme celui de free qu'un potentiel pb de gestion de "redondance" dns dans ha depuis cette version passe inaperçu pour l'équipe de dev

Après il y a ce qui est obligatoire et la norme en pratique usuelle d'un bon serveur DNS complet pour usage en pratique...

Free semble fidèle à sa philosophi de strict minimum syndical dans ses infrastructures...

Bonjour,
retour de we, si je résume, je suis chez Free, si je passe de 2026.9.1 en 2026.9.2 et souci, j'ajoute à la mode @WarC0zes un DNS Google ou Cloudflare ?

Bob

Salut,
Je suis chez Orange et j'ai toujours mis les DNS de chez Cloudflare ou Google. :grin:
Jamais eu de soucis depuis 5 ans.

j'ai eu un soucis il y a qqes années suite a une panne de DNS chez free, et depuis que j'ai mis (grace à ce forum !) d'autres DNS en plus de celui de free RAS...

Passage en 26.9.2 sans soucis...

Apres pour la philo sur l'ordre des DNS... moi j'ai cloudflare en 1er... et ça marche donc j'y touche pas...