C’est moi ça.^^ Je passe par l’adresse URL complète : https://www.suinot.org
Donc ca marche?
Je suis surpris!!!
Ça marche ça marche, c’est vite dit !^^ C’est le seul moyen que j’ai de joindre ton site, c’est pas très pratique quand même, et surtout pas très normal.
As-tu essayé de rajouter l’enregistrement que je te suggérais dans mon avant-dernier message ?
Bon, est ce qu’une nuit de sommeil ira mieux ?
Pour répondre à ta question, oui, j’ai ajouté ta suggestion.
Et toujours rien
Question: comment on peut debuger ça ?
Comment savoir si c’est un problème de configuration de zone, de configuration de bons ou autre ?
Il ne le serait pas plus avec la seconde forme. Pour cela il faut ajouter un enregistrement A spécifique pour suinot.org (@).
Chez moi ça marche.
De quoi parles-tu ? Qu’est-ce qui n’est pas pratique ni normal ?
Toujours rien quoi ?
Qu’est ce qui ne se passe pas ce comme tu veux exactement ?
Je ne parlais pas de ça, c’était deux messages décorrélés. On a abordé l’enregistrement dont tu parles dans les messages qui suivent.
Je ne parviens au site qu’avec l’URL explicitement détaillée. Les redirections du nom de domaine et des sous-domaines ne fonctionnent pas.
Après avoir testé sur d’autres machines et navigateurs, voici ce que je récolte :
Firefox renvoie une erreur de violation de protocole réseau et Chrome un ERR_INVALID_REDIRECT.
(Peut-être un lien avec ton TTL de 24h.)
Aussi, https://suinot.org/ me renvoie un “not found”, donc il doit aussi y avoir un souci dans ta config nginx.
Je remarque que je n’obtiens de réponses de ton serveur web qu’avec le “https” explicitement précisé et que je n’en obtiens pas “par défaut”, il peut peut-être y avoir un souci de ce côté-là en même temps.
Qu’appelles-tu “URL explicitement détaillée” et “redirections du nom de domaine et des sous-domaines” ? Il n’y a pas de redirections en DNS.
Pour le reste, cela relève du serveur web et/ou du navigateur, pas du DNS.
Tapée à la main.
Abus de langage de ma part. Je voulais dire des enregistrements qui font pointer les requêtes au bon endroit :
En fait, je (on) cherche sur le DNS, alors qu’en fait c’est la configuration de nginx qui merde?
Celle là , je n’y ai pas touché, sauf que je confirme, on ne peut pas accéder à http://suinot.org
Il faut que je m’en occupe, mais le temps n’est pas élastique hélas.
Ceci dit, c’est l’occasion.
Je vais donc ouvrir un nouveau sujet.
Pour le “not found”, y a un souci nginx mais pour l’absence de retours en contactant suinot.org ou www.suinot.org, je pencherais quand même pour un souci dns avec le protocole https mal renseigné.
(Mais sans avoir le tout sous la main et sous les yeux, c’est pas évident de deviner ce qu’il se passe chez toi.)
Cela ne m’éclaire pas des masses. Tu tapes quoi exactement ?
Tout ça c’est de la cuisine d’URL du navigateur et du serveur web, pas du DNS.
Non. Le nom de domaine pointe vers la bonne adresse IP donc DNS a fait sa partie. Le reste, je le répète, est entre le navigateur et le serveur web.
D’ailleurs, depuis chez moi ça a marche.
Non, si les zones DNS ne renseignent pas quoi faire des sous-domaines contactés, la requête ne sera pas transmise au serveur web.
Les erreurs que j’ai obtenues plus tôt semblaient montrer qu’au contraire, aucune adresse IP n’était contactée, à moins que ça ne soit un comportement opaque des navigateurs. En tous les cas, je n’avais aucun retour de serveur web.
EDIT : après avoir fouillé, il semble qu’il s’agissait en fait d’un comportement opaque des navigateurs et que le couac se situait côté serveur, sans doute au niveau de la config pour le protocole https.
Chez moi aussi, @rsuinux a dû faire le nécessaire ou bien des caches ont été mis à jour entre temps.
merci à tous pour votre aide.
Je viens de reconfigurer nginx pour pointer correctement vers http://suinot.org et le reste.
En local ça marche (depuis mon réseau wifi, ca fonctionne plutôt bien)
Si vous êtes d’accord, je passe en résolu.
j’en déduis qu’il faut attendre la propagation.
En tout cas, je vous remercie tous de votre aide précieuse, et toujours efficace ici.
Celui qui passe vers Limoges, j’offre une bière.
Amicalement.
Ça dépend de quoi on parle.
On parle de propagation du NS primaire vers le ou les NS secondaires. En l’absence de notification, le délai est défini par la valeur du “refresh” du SOA de la zone (3 heures dans ton cas), auquel il faut éventuellement ajouter le délai de “retry” du SOA (1 heure) en cas de perte de connectivité entre le primaire et le secondaire au moment où ce dernier va chercher à se synchroniser.
On parle plutôt d’expiration pour un NS cache récursif, qui ne va rechercher un enregistrement que s’il est absent de son cache au moment où il en a besoin, donc n’a jamais été recherché ou a expiré et été supprimé. Le délai d’expiration d’un enregistrement est défini par la durée de vie (TTL) spécifiée pour cet enregistrement (par défaut, la valeur définie par la directive $TTL du fichier de zone, 1 jour dans ton cas).
Donc si un client utilise un serveur DNS cache qui venait juste de rechercher l’enregistrement avant que sa valeur change et va interroger le serveur DNS secondaire qui ne reçoit pas de notification et venait juste de vérifier si le serial du NS primaire avait changé, il faudra additionner le délai de propagation et le délai d’expiration avant de faire une requête et recevoir la nouvelle valeur de l’enregistrement.
Note que lorsque tu prévois de faire des modifications dans une zone, il peut être pratique de raccourcir ces délais afin que les changements prennent effet plus rapidement. Mais comme rien n’est jamais simple, certains serveurs DNS secondaires ou caches peuvent appliquer leur propres valeurs minimales de refresh ou de TTL et ne pas tenir compte des valeurs inférieures spécifiées dans les enregistrements.
Et bien merci pour ces explications.
J’en apprends tous les jours 
C’est peut être pour ça que ma fille, à Paris , ne voit toujours rien.
“Nous ne parvenons pas à trouver ce site, impossible de se connecter” Maintenant, je vais pas lui demander de faire des tests poussé. Elle fait du dessin, pas de l’informatique…
Un dernier message pour dire que cette fois ci tout fonctionne:
pourquoi je dis ça: parce que sur le portable (smartphone), ou sur le réseau de free, par exemple, il n’y avait toujours pas d’accès à mon nom de domaine.
Solution: quand on met une clef dans l’interface de gandi, il ne faut pas faire de copier/coller depuis la console vers leur interface. Ca a mis des retour à la ligne 
J’ai corrigé ce matin, et cette fois ça, bingo, ca marche.
Je ne comprenais pas pourquoi certain arrivait bien sur mes sites et pas d’autre.
A présent, sujet clos définitivement.