IP d'un sous-domaine
ip sous-domaine · verifier ip sous domaine · lookup sous-domaine
Comment consulter l'IP de api, mail, www ou autres sous-domaines sans les confondre avec le domaine principal.
Par DN01 Network Team
Un sous-domaine peut résoudre vers une IP totalement différente du domaine principal. api.example.com peut vivre chez un fournisseur cloud, www derrière un CDN et mail sur une infrastructure de messagerie. Lors d'un incident, interrogez donc le hostname exact, pas seulement l'apex.
Ouvrez /find-ip-address avec le sous-domaine complet. Utilisez ensuite Vérificateur DNS pour savoir si la réponse vient de A, AAAA ou CNAME. Si le sous-domaine expose un service web, Vérificateur d'en-têtes HTTP confirme redirections, en-têtes et état du host.
Cette méthode réduit les tickets où l'on dit “le domaine pointe bien” alors que le problème concerne un sous-domaine précis.
Apex, www et sous-domaines diffèrent
L'apex example.com, www.example.com et api.example.com sont des noms distincts. Ils peuvent partager une destination, mais DNS ne le garantit pas. Chaque label a ses propres enregistrements ou hérite via CNAME.
Les certificats et en-têtes peuvent aussi changer. Un sous-domaine peut résoudre correctement mais servir un certificat sans SAN correct, ou rediriger vers un autre host. L'IP n'est donc que le premier indice.
Flux de diagnostic
Interrogez le sous-domaine dans /find-ip-address et copiez toutes les IP. Ouvrez ensuite Vérificateur DNS pour vérifier enregistrements et TTL. S'il y a CNAME, inspectez la cible canonique.
Pour les hosts HTTP, lancez Vérificateur d'en-têtes HTTP. Si l'URL redirige vers un autre domaine, enquêtez aussi sur cette destination. Utilisez WHOIS pour comprendre registrar, serveurs de noms ou fournisseur de l'IP.
Cas courants
Dans les applications SaaS, un sous-domaine pointe souvent vers un CNAME du fournisseur. Pour les APIs, il peut pointer vers des load balancers cloud. Pour le mail, mail ou smtp peuvent résoudre vers des serveurs distincts de MX.
Pendant la décommission, cherchez les sous-domaines oubliés qui pointent encore vers d'anciens fournisseurs. Ces restes peuvent créer un risque de takeover ou des erreurs de marque.
Ce qu'il faut garder
Incluez hostname complet, IPs, type d'enregistrement, TTL et CNAME intermédiaires. Si un service web répond, ajoutez statut HTTP, redirection finale et en-têtes utiles.
Ajoutez aussi l'environnement attendu et le propriétaire interne du sous-domaine. Cette information évite de traiter un ancien host de staging comme une panne production ou de laisser un sous-domaine sans responsable clair.
Avec ces preuves, infrastructure, sécurité et support parlent de la même entité technique au lieu de discuter d'un “domaine” abstrait.
Questions fréquentes
- www est-il un sous-domaine ?
Oui. www.example.com est distinct de l'apex example.com et peut avoir une IP différente.
- Faut-il inclure le protocole ?
Pour l'IP, utilisez seulement le host. Pour les en-têtes HTTP, utilisez l'URL complète avec https://.
- Que faire avec un CNAME ?
Suivez le CNAME jusqu'à la cible et vérifiez les IP publiées par ce nom.