URL, domaine, port et chemin : quelle partie donner à un outil réseau ?
Vous copiez un lien complet dans un outil DNS et le résultat ne correspond pas à votre attente. Le DNS recherche un nom, pas la page ni les paramètres de connexion contenus dans l’URL.
Décomposer un exemple
Dans https://service.example.org:8443/aide?lang=fr#contact, le protocole est HTTPS, le nom d’hôte service.example.org, le port explicite 8443 et le chemin /aide. La requête et le fragment ont encore d’autres rôles.
Le DNS traite le nom d’hôte. Il ne recherche pas séparément l’adresse d’une page /aide ni une IP pour le paramètre lang.
Le sous-domaine fait partie du nom
Service.example.org et example.org peuvent avoir des réponses différentes. Retirer systématiquement le sous-domaine peut tester le mauvais service.
Pour RDAP, l’outil peut devoir identifier le domaine enregistrable selon l’extension. Il ne faut pas supposer que les deux derniers éléments suffisent toujours à ce calcul.
Le port ne change pas la réponse A
Un service peut utiliser une autre valeur que le port par défaut. Cela modifie la connexion à établir, pas nécessairement l’adresse obtenue pour le nom. Une résolution correcte ne garantit pas qu’un serveur écoute sur ce port.
Les IP littérales et les IPv6 entre crochets demandent aussi une lecture adaptée. Notre guide des ports réseau explique cette autre dimension.
Copier sans divulguer un accès
Un lien peut contenir un jeton, un identifiant de partage ou des paramètres personnels. Retirez ce qui n’est pas utile au diagnostic avant de le publier. Un fragment n’est pas transmis comme le chemin d’une requête HTTP ordinaire, mais peut être utilisé par l’application dans le navigateur.
Les outils Vite Mon IP acceptent certains liens et normalisent les saisies selon leur fonction. Vérifiez le nom finalement affiché ; une normalisation pratique ne remplace pas la lecture du lien reçu.