Redirection d’URL DNS : ce qui fonctionne et ce qui ne fonctionne pas

Publié le 12 mai 2026

Si vous avez besoin d’une redirection d’URL DNS, la première chose à clarifier est simple : le DNS ne redirige pas le trafic web. Le DNS répond uniquement avec des enregistrements comme A, AAAA ou CNAME. La redirection réelle se produit sur un serveur web, un proxy inverse ou une fonctionnalité de registrar placée devant le domaine.

C’est là que de nombreuses configurations commencent à légèrement déraper. Le propriétaire d’un domaine pointe un enregistrement et s’attend à ce que example.com soit transféré vers www.example.com ou vers un nouveau chemin du site, mais rien ne bouge. Le DNS a fait son travail. Il a traduit le nom en adresse IP. Il n’a pas indiqué au navigateur d’aller ailleurs.

Redirection d’URL DNS vs enregistrements DNS

Si vous voulez que les visiteurs soient envoyés d’une URL à une autre, vous avez besoin d’une redirection HTTP — généralement 301 pour les déplacements permanents ou 302 pour les temporaires. Cette redirection est renvoyée par un service capable de parler HTTP ou HTTPS. Le DNS ne peut pas faire cela à lui seul, car il fonctionne avant que le navigateur ne demande la page web.

Quelques fournisseurs étiquettent cette fonctionnalité comme un transfert de domaine, ce qui crée une certaine confusion. En coulisses, ils ne font pas de magie DNS. Ils exploitent un service de transfert qui écoute la requête et répond avec une redirection.

Que faut-il utiliser à la place du DNS pour les redirections

Les options propres sont une redirection de serveur web, une fonctionnalité de redirection du control panel, ou la redirection du registrar si vous n’hébergez pas le site vous-même. Pour une utilisation en production, les redirections server-side sont généralement les meilleures, car vous contrôlez les codes d’état, le comportement HTTPS et les cas limites comme la préservation des chemins et des chaînes de requête.

Si l’objectif est simplement de faire en sorte que le domaine racine et www se comportent correctement, un modèle courant consiste à faire pointer les deux noms d’hôte vers le même serveur et à forcer une version canonique dans Nginx ou Apache. Si l’objectif est de déplacer un site entier, configurez une redirection 301 et gardez l’ancien domaine actif assez longtemps pour que les navigateurs et les moteurs de recherche se mettent à jour. Ce n’est parfois pas la plus belle situation DNS, mais elle reste sous contrôle.

Vérifications courantes avant de modifier quoi que ce soit

Vérifiez où le domaine se résout actuellement, si un serveur web répond sur les ports 80 et 443, et si le SSL est déjà valide pour les deux noms. Les redirections HTTPS échouent de manière très visible si le certificat ne correspond pas. Vérifiez également les valeurs TTL, car le cache DNS peut faire paraître une configuration corrigée comme défaillante pendant un certain temps.

Si vous exploitez une infrastructure pour des clients ou des boutiques, testez avec et sans www, en HTTP et en HTTPS, et avec un exemple d’URL profonde. Une redirection qui ne fonctionne que sur la page d’accueil est un petit gremlin, pas un travail terminé.

Chez kodu.cloud, cela est généralement géré au niveau du serveur ou du panel, où le comportement est prévisible et facile à surveiller.

Andres Saar Ingénieur du service client