Lorsqu’un nom de domaine vient d’être acheté chez un bureau d’enregistrement (registrar) comme IONOS, OVH ou Gandi, le visiteur tombe généralement sur une page standard indiquant que l’adresse est réservée ou en attente d’attribution. Cette page d’attente (parking) signale simplement que le domaine existe dans le registre global mais qu’il n’est pas encore relié à un serveur web opérationnel ou que la configuration réseau locale n’est pas achevée.
1. Modifier la zone DNS du bureau d’enregistrement
Par défaut, le registrar fait pointer le domaine vers ses propres adresses IP afin d’afficher sa page publicitaire ou son panneau de bienvenue. Pour rediriger le trafic vers votre propre infrastructure, vous devez intervenir sur la console d’administration DNS :
- Enregistrement A : renseignez l’adresse IPv4 publique de votre serveur web pour le domaine racine (par exemple mondomaine.fr).
- Enregistrement AAAA : ajoutez l’adresse IPv6 si votre hébergement ou votre serveur dédié dispose d’une connectivité IPv6 active.
- Enregistrement CNAME : configurez les sous-domaines usuels, notamment www, pour qu’ils pointent vers le domaine racine ou un alias spécifique.
Une fois les modifications validées, les serveurs de noms faisant autorité diffusent les nouveaux enregistrements sur Internet.
2. Gérer le délai de propagation et le cache local
La mise à jour de la zone DNS n’est pas instantanée sur l’ensemble de la planète. La propagation dépend de la valeur TTL (Time To Live) définie sur vos enregistrements. Durant cet intervalle, de nombreux serveurs récursifs et résolveurs conservent les anciennes adresses en mémoire.
Si vous continuez de voir la page par défaut de votre hébergeur sur votre poste de travail alors que la zone DNS a été modifiée, votre cache local est probablement en cause. Il est alors utile d’afficher le cache DNS sous windows pour vérifier quelle adresse IP est encore résolue par votre système d’exploitation avant d’exécuter un classique ipconfig /flushdns.
3. Configurer l’hôte virtuel sur le serveur web
Avoir une résolution DNS fonctionnelle ne suffit pas. Lorsque la requête HTTP ou HTTPS atteint votre serveur (Apache, Nginx ou IIS), ce dernier doit identifier le site demandé grâce à l’en-tête d’hôte (Host Header). Si aucun hôte virtuel (VirtualHost ou bloc server) ne correspond au domaine, le serveur affichera sa propre page par défaut ou un code d’erreur.
Sur un serveur Nginx, assurez-vous que la directive server_name contient vos noms de domaine. Sur Apache, paramétrez correctement les directives ServerName et ServerAlias. Si votre application fait appel à des scripts applicatifs, surveillez également les chemins d’exécution pour éviter des blocages inattendus, comme une erreur include sur serveur php OVH ou des permissions de fichiers incorrectes lors du déploiement.
4. Tester la résolution en ligne de commande
Pour isoler un dysfonctionnement sans dépendre des caches agressifs des navigateurs modernes, passez par des utilitaires de diagnostic en console :
- nslookup mondomaine.fr 8.8.8.8 permet d’interroger directement un résolveur externe pour tester la propagation.
- ping mondomaine.fr confirme la cohérence de la résolution système.
- curl -I https://mondomaine.fr examine les en-têtes de réponse du serveur distant sans passer par un rendu graphique.
Pour aller plus loin dans la boîte à outils d’administration et dépanner vos connexions réseau, consultez notre sélection de ligne de commandes utiles windows pour diagnostiquer rapidement les problèmes d’accès et de routage.