Après lecture de ton article, je continue de penser que ta justification de ce "reliquat" est un peu tirée par les cheveux...
Je développe ...
Tout d'abord, dans ton commentaire, tu écris:
mais il est, par ce point précis — les enregistrements DNS dédiés — bien plus modernes que HTTP
C'est comparé l'incomparable: d'un côté SMTP qui a effectivement été intrinsèquement lié à DNS pour une raison simple: la tolérance aux pannes (je ne vais pas rééxpliquer le concept de MX2 & co ...).
Ce lien fort entre ces deux protocoles permet aux infrastructures de courriers électroniques de livrer un mail dans une majeure partie des cas, même en cas de panne temporaire d'un des éléments de la chaine.
Toutefois, d'un point de vue utilisateur, cela n'a strictement aucun intérêt. Si mon serveur de mail sortant est mail.plop.com et que celui-ci est down temporairement, le mécanisme DNS ne changera strictement rien à l'expérience utilisateur: je n'arriverai pas à envoyer mon mail.
Dans l'absolu, ce principe est absolument inapplicable à un service web: un serveur lambda peut toujours stocker un mail en attendant que le serveur autoritaire revienne à la vie ... cela se fait tout seul sans qu'il n'y ai quoique ce soit à gérer d'un point de vue applicatif.
Pour le web c'est autre chose: tu dois t'assurer que ton WWW2 (l'équivalent du MX2) ai bien le contenu de ton WWW primaire répliqué.
Mais attention, le contenu c'est bien, mais il faut aussi, si tu veux bénéficier d'une expérience utilisateur fluide, synchroniser les "sessions" des utilisateurs.... résultat, énormément de taf d'un point de vue applicatif (filesystem partagé, réplication master/master sur les bdd, etc...).
Introduire au sein de DNS un système de load balancing/fail over sur HTTP à la façon de ce qui est fait sur MX aurait été plus une source d'erreur (oh bein j'ai rajouté un WWW2 ça veut dire que j'ai du load balancing ??) qu'un réel gain.
Maintenant dans ton article, tu justifies l'existence du 'www.' par plusieurs autres arguments:
- Lisibilité de la zone DNS
- Identification aisée de quel serveur héberge quel service.
Encore une fois, c'est deux arguments sont, à mes yeux, plutôt légers et serait irréfutables uniquement dans le cas dans réseau local
Rien en t'empêche de lier, au niveau DNS, tout tes services à une même adresse IP (celle par exemple d'un routeur/firewall) et de faire le dispatch de ces services aux niveau du routeur (ce que j'ai souvent vu faire chez des hébergeurs pros: routeur qui tient les IP et gère la sécu + frontaux/filer/db en réseau local pour les vrais services).
Par ailleurs, rien ne t'empêche d'avoir un enregistrement A pointant vers X.X.X.X pour le root de ta zone (plop.com) et d'autres pointant vers d'autres IP pour d'autres noms de ta zone.
Pour conclure, je dirai que je préfère comme toi avoir des FQDN clairs pour mes différents services (mail.xxxx pour le mail, www.xxxx pour le web, etc..) mais, qu'à mon humble avis (mais je crains qu'il n'existe pas de réponse "unique" à ce débat), il n'y plus aucune justification technique à cela...
[^] # Re: Préfixe utile
Posté par LaBienPensanceMaTuer . En réponse au journal Boursorama double fail. Évalué à 5.
Après lecture de ton article, je continue de penser que ta justification de ce "reliquat" est un peu tirée par les cheveux...
Je développe ...
Tout d'abord, dans ton commentaire, tu écris:
C'est comparé l'incomparable: d'un côté SMTP qui a effectivement été intrinsèquement lié à DNS pour une raison simple: la tolérance aux pannes (je ne vais pas rééxpliquer le concept de MX2 & co ...).
Ce lien fort entre ces deux protocoles permet aux infrastructures de courriers électroniques de livrer un mail dans une majeure partie des cas, même en cas de panne temporaire d'un des éléments de la chaine.
Toutefois, d'un point de vue utilisateur, cela n'a strictement aucun intérêt. Si mon serveur de mail sortant est mail.plop.com et que celui-ci est down temporairement, le mécanisme DNS ne changera strictement rien à l'expérience utilisateur: je n'arriverai pas à envoyer mon mail.
Dans l'absolu, ce principe est absolument inapplicable à un service web: un serveur lambda peut toujours stocker un mail en attendant que le serveur autoritaire revienne à la vie ... cela se fait tout seul sans qu'il n'y ai quoique ce soit à gérer d'un point de vue applicatif.
Pour le web c'est autre chose: tu dois t'assurer que ton WWW2 (l'équivalent du MX2) ai bien le contenu de ton WWW primaire répliqué.
Mais attention, le contenu c'est bien, mais il faut aussi, si tu veux bénéficier d'une expérience utilisateur fluide, synchroniser les "sessions" des utilisateurs.... résultat, énormément de taf d'un point de vue applicatif (filesystem partagé, réplication master/master sur les bdd, etc...).
Introduire au sein de DNS un système de load balancing/fail over sur HTTP à la façon de ce qui est fait sur MX aurait été plus une source d'erreur (oh bein j'ai rajouté un WWW2 ça veut dire que j'ai du load balancing ??) qu'un réel gain.
Maintenant dans ton article, tu justifies l'existence du 'www.' par plusieurs autres arguments:
- Lisibilité de la zone DNS
- Identification aisée de quel serveur héberge quel service.
Encore une fois, c'est deux arguments sont, à mes yeux, plutôt légers et serait irréfutables uniquement dans le cas dans réseau local
Rien en t'empêche de lier, au niveau DNS, tout tes services à une même adresse IP (celle par exemple d'un routeur/firewall) et de faire le dispatch de ces services aux niveau du routeur (ce que j'ai souvent vu faire chez des hébergeurs pros: routeur qui tient les IP et gère la sécu + frontaux/filer/db en réseau local pour les vrais services).
Par ailleurs, rien ne t'empêche d'avoir un enregistrement A pointant vers X.X.X.X pour le root de ta zone (plop.com) et d'autres pointant vers d'autres IP pour d'autres noms de ta zone.
Pour conclure, je dirai que je préfère comme toi avoir des FQDN clairs pour mes différents services (mail.xxxx pour le mail, www.xxxx pour le web, etc..) mais, qu'à mon humble avis (mais je crains qu'il n'existe pas de réponse "unique" à ce débat), il n'y plus aucune justification technique à cela...