Domaine yhn.fr régulièrement inaccessible

[Guygoye]

Bonjour à tous,

Mon serveur YunoHost:
Mon serveur est un RPi 3B+ qui tourne sur un disque dure externe de 256Go
Ma version de Younohost est là 3.6.4.6
J’ai accès à mon serveur : En SSH et Par la webadmin

Comme expliqué, il arrive de manière récurrente que mon serveur ne soit pas accessible depuis sont adresse en ynh.fr. Et puis d’un coup tout fonctonne à nouveau. En passant par son IP tout fonctionne bien (en SSH ou Interface webadmin)
Je voulais savoir si c’était des problèmes d’infrastructure ou si il y avait quelque chose de mal configuré?
Pour ma part je pencherais pour un problème d’infrastructure mais quand c’est le cas histoire de me rassurer où trouver l’information?

Merci d’avance de vos réponses

Guillaume

[metyun]

Bonjour,
J’ai également des problèmes d’accès en ce moment même avec la même configuration que toi, je penche comme toi pour un problème d’infrastructure. Je n’y connais pas grand chose, aussi si il y a une explication sur ce type de problème. Comme j’ai migré l’ensemble de mes mails dessus le serveur et je fais tourner Nextcloud dessus, c’est un peu embêtant ces pertes d’accès. Est-ce qu’en achetant un NDD ça serait plus fiable?

[tsgps]

Bonjour
J’ai la même problématique, assez récurrente, avec un Raspberry Pi 4, le système installé sur une carte 64Go, et les données sur un SSD externe. Et de temps à autres , je reçois un paquet de mails (67 à l’instant) sur mon adresse perso qui me dises:
This is the mail system at host XXXX.ynh.fr.

I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can delete your own text from the attached returned message.

The mail system

<monmail@perso.fr> (expanded from ): host

mail-fr.securemail.pro[81.88.48.101] said: 550 5.1.0 <root@XXXX.ynh.fr>

sender rejected (in reply to MAIL FROM command)

Traceback (most recent call last):
File “/usr/bin/yunohost”, line 214, in
timeout=opts.timeout,
File “/usr/lib/python2.7/dist-packages/moulinette/init.py”, line 136, in cli
moulinette.run(args, output_as=output_as, password=password, timeout=timeout)
File “/usr/lib/python2.7/dist-packages/moulinette/interfaces/cli.py”, line 425, in run
ret = self.actionsmap.process(args, timeout=timeout)
File “/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py”, line 523, in process
return func(**arguments)
File “/usr/lib/moulinette/yunohost/log.py”, line 284, in func_wrapper
result = func(*args, **kwargs)
File “/usr/lib/moulinette/yunohost/dyndns.py”, line 235, in dyndns_update
old_ipv4 = check_output(“dig @%s +short %s” % (dyn_host, domain)).strip() or None
File “/usr/lib/python2.7/dist-packages/moulinette/utils/process.py”, line 29, in check_output
return subprocess.check_output(args, stderr=stderr, shell=shell, **kwargs)
File “/usr/lib/python2.7/subprocess.py”, line 219, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command ‘dig @dyndns.yunohost.org +short bdcb.ynh.fr’ returned non-zero exit status 9

[jbd]

Bonjour,

J’ai exactement le même problème (en ce moment même et assez régulièrement aussi) avec un domaine en noho.st.
Un test avec dnschecker.org me confirme que mon serveur n’est plus référencé.
Si je lance “yunohost dyndns update” manuellement, j’obtiens la même erreur que tsgps (dig … returned non-zero exit status 9).
Je suis aussi curieux de savoir si c’est lié à un problème de config sur mon serveur ou un souci du côté du service de dyndns de yunohost.

Merci,

JB

[ljf]

I have checked our infra and you was right, there was an issue with bind9. It’s normally fixed now.

[jbd]

Yes, it is working again for me.
Thanks a lot.

JB

[Guygoye]

Thank you. It’s working now.

[metyun]

Thanks a lot ljf .

Could you explain us, with simple words, how does it work the resolution of Domain name with Yunohost ynh.fr and other like nohost.me, compared to other domain name. I know that bind9 is a dns resolver but i thought it resolve by the dns of the internet provider or dns change by user on the client computer.
I’m not familiar with english langage, so if it can be in french please. I made the effort to write in english, so if i made mistake, excuse me, it is not so easy for me.
Would the problem go away with my own domain name instead of using a yunohost subdomain xxx.ynh.fr?

[ljf]

En matière de DNS il faut distinguer les serveurs de résolutions et les serveurs d’autorités.

Pour résoudre les noms de domaines (faire l’opération NOM -> IP) les systèmes utilisent en général le DNS fournit par la box via DHCP (le protocole qui affecte également l’ip à utiliser pour se connecter au réseau). Parfois, un autre DNS est configuré (d’ailleurs je le conseille). Dans le cas de YunoHost, nous utilisons une liste de plusieurs résolveurs (FFDN et autres assos du même genre à l’étranger). Mais là je parle de résolution.

Dans le cas des noms de domaines dynamiques noho.st, nohost.me et ynh.fr, yunohost utilise un serveur DNS qui fait autorité, c’est à dire que c’est ce serveur qui est chargé de définir les associations NOM -> IP pour ces “zones” DNS. Donc quand on interroge un résolveur celui-ci, si il n’a pas déjà enregistré la réponse, va demander au serveur qui fait autorité la réponse.

La commande “yunohost dyndns update” permet donc de mettre à jour les informations sur le serveur qui fait autorité. Elle est lancé automatiquement et régulièrement quand on utilise ce genre de domaine (toutes les 2 minutes je crois).

Le serveur qui fait autorité est accompagné d’un serveur esclave qui réplique la config et qui peut répondre en cas de non réponse du premier serveur.

Sauf que dans la présente panne, le serveur qui faisait autorité était dans un état qui était considéré comme fonctionnel par les serveurs de résolution. Du coup, le slave ne servait à rien.

---

In terms of DNS, a distinction must be made between resolution servers and authority servers.

To resolve domain names (do the operation NAME -> IP) systems generally use the DNS provided by the box via DHCP (the protocol that also affects the ip to be used to connect to the network). Sometimes, another DNS is configured (I recommend it). In the case of YunoHost, we use a list of several resolvers (FFDN and other similar associations abroad). But this is about resolution.

In the case of dynamic domain names noho.st, nohost.me and ynh.fr, yunohost uses an authoritative DNS server, i. e. this server is responsible for defining the NAME -> IP associations for these DNS “zones”. So when we ask a resolver, if he has not already recorded the answer, he will ask the authoritative server for the answer.

The “yunohost dyndns update” command therefore makes it possible to update the information on the authoritative server. It is launched automatically and regularly when this type of domain is used (every 2 minutes I think).

The authoritative server is accompanied by a slave server that replicates the configuration and can respond if the first server does not respond.

Except that in the present failure, the authoritative server was in a state that was considered functional by the resolution servers. As a result, the Slave was useless.

[Guygoye]

Merci pour toutes ces explications que je vais prendre le temps de lire à tête reposée pour être sûr d’avoir bien compris.