Domaine inaccessible après le passage à CURIAWEB : causes et solutions

Vous avez connecté un domaine existant à votre hébergement CURIAWEB ou modifié les serveurs de noms vers CURIAWEB et votre site web est ensuite inaccessible ? Dans ce cas, il ne faut pas se contenter d'attendre la propagation DNS.

Après un changement de domaine, plusieurs composants doivent fonctionner ensemble : le domaine doit utiliser les serveurs de noms ou les enregistrements DNS corrects, la zone DNS doit être complète et le domaine doit être configuré correctement sur l'environnement d'hébergement CURIAWEB.

En bref : Si un domaine ne fonctionne pas après le passage à CURIAWEB, vérifiez d'abord les serveurs de noms et le DNS, puis l'attribution du domaine dans l'hébergement. Une mauvaise configuration ne se corrige pas automatiquement en attendant plus longtemps.

Qu'est-ce qui a été modifié sur le domaine au juste ? #

Avant de commencer le dépannage, vous devez savoir quel type de transition a été effectué.

Un nom de domaine existant peut en principe être relié à CURIAWEB de différentes manières :

• Les serveurs de noms ont été entièrement modifiés sur CURIAWEB.
• Les serveurs de noms actuels restent inchangés et seuls certains enregistrements DNS ont été modifiés sur CURIAWEB.
• Le nom de domaine a été transféré en plus de CURIAWEB.

Ces processus ne sont techniquement pas les mêmes.

Si vous souhaitez uniquement utiliser l'hébergement CURIAWEB, aucun transfert de domaine n'est par exemple nécessaire. Nous expliquons les différentes possibilités sous Laisser le domaine chez un autre fournisseur et le connecter à l'hébergement CURIAWEB.

Vérifie d'abord les serveurs de noms actuels #

Si l'ensemble de la gestion DNS doit être effectuée via CURIAWEB, les serveurs de noms CURIAWEB prévus à cet effet doivent être configurés pour le domaine :

ns1.curiaweb.ch
ns2.curiaweb.ch

Avec le Vérification DNS CURIAWEB peux-tu vérifier quelles informations DNS sont actuellement visibles publiquement pour ton domaine.

Tu trouveras plus d'informations sur les serveurs de noms sur Trouver et utiliser correctement les serveurs de noms CURIAWEB.

Que signifie l'affichage des anciens serveurs de noms ? #

Si les serveurs de noms viennent d'être modifiés, la mise en place peut ne pas encore être visible partout.

Cependant, si les serveurs de noms du fournisseur précédent s'affichent de manière permanente, tu dois vérifier auprès du bureau d'enregistrement (registrar) si la modification a effectivement été enregistrée ou effectuée.

Les serveurs de noms sont enregistrés lors de l'enregistrement du domaine ou auprès du registrar compétent. Une modification au sein de l'hébergement CURIAWEB seule ne remplace pas cette délégation.

Important : Si vous n'avez pas modifié les serveurs de noms chez le registrar, c'est l'ancienne zone DNS qui reste autoritative. Les modifications apportées à une autre zone DNS non autoritative n'auront alors aucun effet sur les requêtes DNS publiques.

Les serveurs de noms CURIAWEB sont actifs, mais le site web ne fonctionne toujours pas #

Les seuls bons serveurs de noms ne suffisent pas.

La zone DNS fournie par ces serveurs de noms doit également contenir les enregistrements corrects. Pour un site Web, ce sont particulièrement les enregistrements A, AAAA ou CNAME qui sont pertinents.

Le domaine doit pointer vers l'infrastructure prévue pour votre compte d'hébergement.

Nous expliquons la fonction de chaque type d'enregistrement DNS sur Enregistrements DNS expliqués : A, AAAA, CNAME, MX, TXT et CAA.

Pourquoi l'ancienne zone DNS est-elle si importante ? #

Lors du changement de serveurs de noms, la zone DNS de l'ancien fournisseur n'est pas automatiquement transférée vers CURIAWEB.

C'est l'une des sources d'erreur possibles les plus importantes lors d'un changement de serveur de noms.

La zone DNS existante peut contenir, en plus de l'enregistrement pour le site web, par exemple :

• Enregistrements MX pour les e-mails,
• enregistrements SPF, DKIM et DMARC,
• Sous-domaines,
• Enregistrements TXT de vérification,
• Enregistrements CNAME pour les services externes,
• ou d'autres configurations DNS personnalisées.

Si de telles entrées manquent dans la nouvelle zone DNS, les services correspondants risquent de tomber en panne après le changement de serveur de noms.

Conseil pratique : Avant un changement de serveur de noms, la configuration DNS existante doit être documentée et la nouvelle zone préparée. Ne modifiez les serveurs de noms que lorsque les enregistrements DNS requis sont présents sur la nouvelle cible.

Comment puis-je vérifier les enregistrements DNS actuels ? #

Avec le Vérification DNS CURIAWEB peux-tu vérifier la configuration DNS visible publiquement.

Vous trouverez une explication plus détaillée sur Vérifier les enregistrements DNS : Afficher la configuration DNS actuelle d'un domaine.

Compare non seulement les serveurs de noms, mais aussi les enregistrements A, AAAA, CNAME, MX et TXT pertinents pour tes services.

Le domaine pointe vers CURIAWEB – est-il également configuré dans l'hébergement ? #

Le DNS veille à ce qu'une requête parvienne à la bonne infrastructure de serveur. Le serveur Web doit ensuite savoir quel site Web doit être délivré pour le domaine demandé.

Même si le domaine pointe vers le bon serveur, s'il n'est pas correctement configuré dans le compte d'hébergement, le site Web ne pourra toujours pas fonctionner comme prévu.

En bref : Le DNS répond à la question „ Vers quel serveur la requête doit-elle aller ? “. L'hébergement doit ensuite pouvoir répondre à : „ Quel site web appartient à ce domaine ? “

Vérifie aussi la version www du domaine #

Le domaine principal et ses www-Les variantes sont des noms d'hôtes techniquement différents :

example.ch
www.example.ch

Si une seule des deux variantes fonctionne, tu dois vérifier la configuration DNS et l'hébergement pour la variante qui ne fonctionne pas.

Selon la configuration www par exemple relié au domaine principal via un CNAME.

L'ancien site Web continue de s'afficher #

Si, après le changement, le site web de l'ancien hébergeur s'affiche toujours, il se peut que le domaine ou un nom d'hôte utilisé pointe encore vers l'ancienne infrastructure.

De plus, en raison d'une modification récente du DNS, il est possible que différents répulseurs fournissent encore temporairement des réponses différentes.

Vérifiez par conséquent d'abord les enregistrements DNS actuellement visibles et comparez-les avec la configuration CURIAWEB prévue.

Si les données DNS publiques pointent déjà clairement vers la nouvelle infrastructure, un cache de navigateur, de proxy ou de site web peut également être impliqué.

Pourquoi le domaine ne fonctionne-t-il pas pour moi, mais fonctionne pour quelqu'un d'autre ? #

Après une modification du DNS, différents résolveurs DNS peuvent utiliser temporairement des informations mises en cache différentes.

C'est pourquoi il peut arriver que le domaine fonctionne déjà avec la nouvelle configuration sur une connexion Internet, tandis qu'une autre connexion utilise encore d'anciennes informations DNS.

Nous expliquons les aspects techniques sous Qu'est-ce que la propagation DNS et pourquoi une modification DNS prend-elle du temps ?.

Important : Si le domaine renvoie partout la même mauvaise configuration DNS, la „ propagation “ n'est probablement pas la solution. Vérifiez alors les valeurs réellement enregistrées.

Le site Web fonctionne en HTTP, mais pas en HTTPS #

Il est donc possible que la résolution de domaine de base fonctionne déjà, alors que la configuration HTTPS n'est pas encore correcte.

Pour HTTPS, un certificat SSL/TLS valide pour le nom de domaine utilisé doit être présent sur l'environnement d'hébergement.

Si le domaine pointait auparavant vers un autre serveur, l'émission ou la validation d'un certificat sur le nouvel environnement ne pourra fonctionner qu'après que le domaine pointera correctement vers cette infrastructure.

Vérifiez également à la fois le domaine principal et celui utilisé www-Variante.

Le navigateur affiche un avertissement de certificat #

Un avertissement de certificat ne signifie pas automatiquement que le DNS ne fonctionne pas.

Si le navigateur parvient déjà à joindre un serveur Web, mais que son certificat ne correspond pas au nom de domaine appelé, le problème relève plutôt de la configuration SSL/TLS ou de l'hébergement.

Le DNS, le serveur Web et le SSL doivent par conséquent être vérifiés séparément.

Le site web fonctionne, mais plus les e-mails #

Il s'agit d'un cas d'erreur particulièrement important après un changement de serveur de noms.

Si le site Web est accessible, cela signifie seulement que la configuration requise pour le site fonctionne. Le courrier électronique utilise ses propres enregistrements DNS.

Pour la réception, les enregistrements MX sont particulièrement pertinents. De plus, SPF, DKIM et DMARC peuvent être nécessaires pour l'envoi et l'authentification.

Si des services de messagerie externe étaient utilisés avant le changement de serveur de noms et que leurs enregistrements DNS n'ont pas été repris dans la nouvelle zone, le site Web peut fonctionner tandis que les e-mails cessent de fonctionner.

Que dois-je prendre en compte avec SpamExperts ? #

Si votre domaine utilise le filtrage entrant SpamExperts, les enregistrements MX prévus doivent être correctement configurés.

SpamExperts reçoit d'abord les messages entrants, les filtre et les transfère ensuite vers le serveur de messagerie cible final.

Nous expliquons la configuration MX sous Filtrage des e-mails entrants SpamExperts et configuration MX.

Important : Les serveurs MX de SpamExperts ne sont pas des serveurs IMAP ou POP3. Pour accéder à votre boîte aux lettres, vous continuez d'utiliser les paramètres du serveur de messagerie prévus pour votre compte de messagerie.

Qu'en est-il de SPF, DKIM et DMARC ? #

Lors d'un changement complet de serveur de noms, il faut également vérifier si les enregistrements d'authentification des e-mails requis sont présents dans la nouvelle zone DNS.

L'absence d'un enregistrement SPF, DKIM ou DMARC ne rend pas nécessairement le site Web inaccessible. Elle peut toutefois nuire à la délivrabilité des e-mails ou à l'authentification des messages.

Tu trouveras plus d'informations sur SPF, DKIM et DMARC en hébergement.

Je n'ai changé que l'enregistrement A – est-ce que j'ai besoin des serveurs de noms CURIAWEB ? #

Non.

Si tu conserves sciemment les serveurs de noms existants et que tu connectes simplement le site web à CURIAWEB via un enregistrement DNS, il n'est pas nécessaire d'entrer les serveurs de noms CURIAWEB.

Dans ce cas, le fournisseur DNS actuel reste autoritaire et vous y modifiez par exemple l'enregistrement A, AAAA ou CNAME requis.

Utilisez exclusivement pour cela les valeurs cibles concrètes de votre compte d'hébergement CURIAWEB.

Pourquoi ne puis-je pas modifier en même temps les serveurs de noms et les enregistrements DNS individuels chez l'ancien fournisseur ? #

Si vous modifiez complètement les serveurs de noms vers CURIAWEB, après une délégation effective, la zone DNS de CURIAWEB deviendra autoritaire.

Les enregistrements DNS que vous modifierez ensuite exclusivement dans l'ancienne zone DNS n'affecteront plus fondamentalement la résolution publique du domaine.

À l'inverse, tant que les anciens serveurs de noms font autorité, les modifications apportées à une future zone DNS CURIAWEB n'ont pas encore d'effet public.

Remarque : Ce qui est toujours déterminant, c'est la zone DNS sur les serveurs de noms actuellement autoritaires.

Le DNSSEC peut-il causer des problèmes après un changement de serveur de noms ? #

Oui.

Lorsque DNSSEC est activé pour un domaine, les informations enregistrées auprès de la zone parente doivent correspondre à la configuration DNSSEC réellement utilisée.

Si les serveurs de noms sont modifiés sans tenir correctement compte d'une configuration DNSSEC existante, les résolveurs validant DNSSEC peuvent considérer les réponses du domaine comme invalides.

Cela peut faire en sorte que le domaine semble totalement injoignable pour une partie des utilisateurs.

Attention : Si un domaine utilisait DNSSEC avant le changement de serveur de noms, la configuration DNSSEC doit être expressément vérifiée. Ne modifiez pas les données DS ou DNSSEC au pif.

Comment puis-je identifier un problème potentiel de DNSSEC ? #

Un indice possible est lorsqu'un domaine ne se résout pas sur certains résolveurs, bien que les serveurs de noms autoritaires soient fondamentalement accessibles et que les enregistrements DNS semblent corrects.

Cependant, pour un diagnostic précis, il faut vérifier la chaîne DNSSEC. Une simple erreur de navigateur ne prouve pas à elle seule un problème DNSSEC.

Que se passe-t-il après un transfert de domaine vers CURIAWEB ? #

Un transfert de domaine et un changement de serveur de noms sont des opérations distinctes.

Le transfert de la gestion des domaines ne signifie pas automatiquement que les fichiers du site Web, les bases de données ou les boîtes aux lettres e-mail ont été transférés.

La configuration DNS doit également être vérifiée séparément lors d'un changement de bureau d'enregistrement.

Nous expliquons le déroulement général sous Transfert de domaine vers CURIAWEB : voici comment fonctionne le déménagement.

Puis-je remettre le domaine sur les anciens serveurs de noms ? #

Techniquement, une nouvelle modification des serveurs de noms peut être possible tant que l'ancienne infrastructure DNS est encore disponible et correctement configurée.

Cela ne devrait cependant pas être pris réflexe comme première mesure.

Plusieurs modifications de serveurs de noms en peu de temps compliquent le diagnostic, car les résolveurs peuvent utiliser différentes délégations mises en cache ou réponses DNS.

Conseil pratique : Si, après une modification, quelque chose ne fonctionne pas, ne rétablissez pas immédiatement plusieurs paramètres pour les modifier à nouveau ensuite. Déterminez d'abord quels serveurs de noms font actuellement autorité et quelles réponses DNS ils fournissent réellement.

Et si une seule sous-domaine ne fonctionne pas ? #

Si le domaine principal fonctionne mais pas un sous-domaine, il n'y a probablement pas de problème fondamental d'enregistrement du domaine.

Vérifiez ensuite l'enregistrement DNS du sous-domaine concerné et assurez-vous qu'il a été correctement configuré sur le système cible.

Par exemple, ce sont

exemple.ch
boutique.exemple.ch
mail.exemple.ch

différents noms d'hôtes et peuvent pointer vers des destinations techniques différentes.

Et si seulement « www » ne fonctionne pas ? #

Auch www.example.ch est un nom d'hôte propre.

Vérifie par conséquent si pour www qu'un enregistrement DNS approprié est présent et si la configuration de l'hébergement prend en compte cette variante.

Le fait que le domaine principal fonctionne ne garantit pas automatiquement un fonctionnement correct wwwConfiguration.

Comment puis-je savoir si le problème vient du DNS ou du serveur web ? #

Vérifiez d'abord si le domaine ou le nom d'hôte concerné se résout vers la destination attendue.

Si la résolution DNS échoue déjà ou pointe vers une mauvaise destination, tu devrais d'abord examiner le DNS ou les serveurs de noms.

Si, en revanche, le DNS fournit la destination attendue, mais que le service web ne fonctionne toujours pas, la poursuite du dépannage relève plutôt de l'hébergement, du serveur web, du SSL, du pare-feu ou de l'application.

Un test de ping peut fournir des informations supplémentaires, mais ce n'est pas un test complet pour un site web. Nous expliquons la bonne interprétation sur Effectuer un test de ping : vérifier la connexion à un domaine ou à un serveur.

Quel est l'ordre logique pour la recherche de pannes ? #

Après un passage à CURIAWEB, vous pouvez effectuer le diagnostic dans cet ordre :

Quels serveurs de noms font actuellement autorité ?
        ↓
La zone DNS correcte est-elle active ?
        ↓
Les enregistrements A / AAAA / CNAME sont-ils corrects ?
        ↓
Le domaine pointe-t-il vers l'infrastructure d'hébergement prévue ?
        ↓
Le domaine est-il configuré dans l'hébergement ?
        ↓
HTTP et HTTPS fonctionnent-ils ?
        ↓
MX et la configuration des e-mails sont-ils corrects ?
        ↓
Les sous-domaines et les services externes sont-ils complets ?

Si DNSSEC est utilisé, sa configuration correcte doit également faire partie de l'audit.

Quand dois-je contacter le support de CURIAWEB ? #

Si le domaine ne fonctionne pas après le changement et que vous ne pouvez pas en déterminer la cause exacte, des informations techniques concrètes aideront au diagnostic.

Veuillez partager si possible :

• quel domaine est concerné,
• ce qui a été changé,
• quand la modification a été effectuée,
• qu'il s'agisse du site Web, de l'e-mail ou des deux,
• quel message d'erreur apparaît,
• et si le problème survient sur plusieurs appareils ou connexions Internet.

Plus la situation initiale est précisément décrite, plus vite il est possible de déterminer si l'enregistrement, le DNS, l'hébergement, le SSL ou l'e-mail est concerné.

Résumé #

Si un domaine existant n'est pas accessible après la migration vers CURIAWEB, vous ne devez pas vous contenter d'attendre automatiquement la propagation DNS.

Vérifiez d'abord quels serveurs de noms sont réellement autoritaires. Si l'ensemble de la gestion DNS doit être effectué via CURIAWEB, les serveurs de noms CURIAWEB prévus doivent être actifs et la nouvelle zone DNS doit contenir toutes les entrées nécessaires.

Si les serveurs de noms précédents sont conservés, les enregistrements DNS requis pour CURIAWEB doivent en revanche être modifiés auprès du fournisseur DNS qui reste autoritatif.

Si le DNS pointe déjà vers la bonne destination, vous devez ensuite vérifier l'attribution du domaine dans l'hébergement, le HTTPS et, le cas échéant, la configuration des e-mails.

Lors d'un changement de serveur de noms, une attention particulière est requise pour les configurations existantes de MX, SPF, DKIM, DMARC, sous-domaines et DNSSEC.

Vérifiez la migration de manière systématique, de la délégation des noms de domaine (nameservers) au DNS, en passant par l'hébergement et les e-mails. Cela permet d'identifier la cause de manière beaucoup plus fiable qu'en modifiant sans cesse différents paramètres.