Journal Boursorama double fail

Posté par . Licence CC by-sa.
Tags : aucun
-6
27
août
2013

Pour les amateurs d'expressions régulières en Ruby…

Depuis Samedi Matin (donc un changement du vendredi soir non testé):

wget -O - http://boursorama.com
--2013-08-26 14:47:46--  http://boursorama.com/
Résolution de boursorama.com (boursorama.com)... 83.231.216.140
Connexion vers boursorama.com
(boursorama.com)|83.231.216.140|:80...connecté.
requête HTTP transmise, en attente de la réponse...301 Moved Permanently
Emplacement: http:///.boursorama.com\z// [suivant]
http:///.boursorama.com\z//: Nom de l'hôte non valide.

Bien sur, le www fonctionne normalement… certains n'ayant une vue du web que par le "www.", sans considérer que c'est une reliquat historique.
On mettra un pied au blâmera pour ne pas avoir d'unit testing sur le domaine.

De même, le rapport de problème technique traité par le service clientèle n'a été traité que le lundi et me demande de préciser. (apparemment une resolution web c'est pas dans leur vocabulaire).
Et qu'est ce qui revient aujourd'hui ??

This is the mail system at host smtpfb1-g21.free.fr.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<E1VDDNS-0001zH-52@mail.boursorama.fr>: connect to
    mail.boursorama.fr[62.23.145.195]:25: Connection timed out

!facepalm

Je poste ici car je sais qu'apparemment des devs de chez eux traînent dans le coin…

  • # Préfixe utile

    Posté par (page perso) . Évalué à 10.

    Le préfixe www n'est pas seulement un reliquat historique, il peut être tout à fait utile, pour pallier l'absence d'enregistrements DNS dédiés au Web comme c'est le cas pour les protocoles modernes comme SMTP ou XMPP, et permettre malgré ce manque de gagner en logique et en flexibilité sur le contenu d'une zone DNS.

    • [^] # Re: Préfixe utile

      Posté par . Évalué à -6.

      Tu peux développer un peu ton propos car je n'y comprend absolument rien ….
      Et sinon …

      protocoles modernes comme SMTP

      Looll … il est plutôt vieux ce protocole (http://tools.ietf.org/html/rfc821 / Aout 1982) et c'est d'ailleurs pour cette raison que le spam est toujours d'actualité de nos jours: ce vieux protocole fait une confiance aveugle à l'expéditeur de l'email chose qui de nos jours, serait impensable…

      C'est cette confiance aveugle et idiote qu'on cherche aujourd'hui à contourner avec les DNS-BL, SPF et autres mécanismes de lutte antispam.

      • [^] # Re: Préfixe utile

        Posté par (page perso) . Évalué à 5.

        Tu peux développer un peu ton propos car je n'y comprend absolument rien ….

        http://tanguy.ortolo.eu/blog/article47/why-www

        Looll … il est plutôt vieux ce protocole (http://tools.ietf.org/html/rfc821 / Aout 1982)

        Je sais, mais il est, par ce point précis — les enregistrements DNS dédiés — bien plus modernes que HTTP, qui est complètement fossilisé.

        • [^] # Re: Préfixe utile

          Posté par . É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:

          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 (page perso) . Évalué à 7.

            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

            Ce n’est pas l’objet. L’idée c’est plutôt du distribuer la charge des différents services à différentes machines, ça ne change rien au « load balancing » par service. C’est facile de le faire pour HTTP et SMTP grâce au champ MX, mais si tu offres des services IMAP et HTTP (exemple donné par Tanguy) tu n’as plus cette option. C’est donc bien pratique de pouvoir identifier les services à partir du DNS, mais pour ça il faut utiliser des sous-domaines. Un type de chez Mozilla te dirait d’utiliser le domaine générique pour le Web et des sous-domaines pour le reste, mais de la part de Tanguy qui lutte de façon très visible sur ce site pour ne pas réduire Internet au web, il n’y aucune raison de traiter le web plus favorablement qu’IMAP, IRC ou NNTP.

            Sans les sous-domaines, il reste la seule solution que tu proposes, une machine frontale pour tout et qui redistribue le boulot. Bien que ça puisse très bien marcher comme ça, c’est un choix qui a peu de chance d’être optimal à tous les coups.

            Par ailleurs, rien ne t'empêche d'avoir un enregistrement A pointant vers X.X.X.X pour le root de ta zone

            Oui, mais pourquoi l’adresse devrait alors être celle du service web ? Ne pourrait-on pas trouver plus utile un autre service par défaut (pas STMP et XMPP, le problème ne se pose pas pour eux).

            je préfère comme toi avoir des FQDN clairs […] mais […] à mon humble avis […], il n'y plus aucune justification technique à cela…

            Avoir pour seul choix d’utiliser un serveur frontal me paraît bien limitant. Cette solution marche mais il en a d’autres pour peu que les services puissent être distingués via le DNS.

            • [^] # Re: Préfixe utile

              Posté par . Évalué à 1.

              Ce n’est pas l’objet. L’idée c’est plutôt du distribuer la charge des différents services à différentes machines, ça ne change rien au « load balancing » par service.

              Effectivement … c'est un peu la base du service DNS que de faire pointer des noms vers des serveurs, qu'ils soient différents ou non… à aucun moment je ne remet ça en cause.
              Je ne vois pas en quoi l'emploi du sous domaine vide (plop.com) nuirait à la distribution de services …

              Sans les sous-domaines, il reste la seule solution que tu proposes, une machine frontale pour tout et qui redistribue le boulot. Bien que ça puisse très bien marcher comme ça, c’est un choix qui a peu de chance d’être optimal à tous les coups.

              C'est pourtant un choix qui, comme je le disais plus haut, a été adopté par des hébergeurs professionnels.
              Cette solution technique représente quelques intérêts non négligeable:

              _ Moins de machines accessibles via les adresses IP publiques réduit d'autant les vecteurs d'attaque
              _ Une facilité de gestion des machines/services accrues: tu veux modifier complètement la façon dont ta plate-forme est construite ? Aucun problème, le retour frontal et les enregistrements DNS publics restent inchangés…
              _ Economie d'IP (loin d'être négligeable en v4).

              Par ailleurs, encore une fois je ne remet pas en cause l'utilisation de DNS et des sous domaines mais surtout les justifications de Tanguy pour le cas particulier du sous domaine www que je trouve juste légère …

              Oui, mais pourquoi l’adresse devrait alors être celle du service web ? Ne pourrait-on pas trouver plus utile un autre service par défaut (pas STMP et XMPP, le problème ne se pose pas pour eux).

              Encore une fois, c'est qu'une question de point de vue, d'esthétique … mais en rien une obligation/limitation technique… Si effectivement j'ai envie de faire pointer mon plop.com vers un serveur FTP libre à moi.

              Avoir pour seul choix d’utiliser un serveur frontal me paraît bien limitant. Cette solution marche mais il en a d’autres pour peu que les services puissent être distingués via le DNS.

              Comme je le disais plus haut, cette solution présente des avantages indéniables et est parfaitement adaptée au hébergement de type "3 tiers" ou seuls les frontaux web doivent être accessible par le commun des mortels.

              Par ailleurs, beaucoup de structures (PME hébergeant leur infra, PME disposant d'un dédié avec des VM, Geeks auto-hébergés, etc…) disposent généralement que d'une IP publique: dans ce cas, tout les services sont rattachés à la même IP et la différenciation de ces derniers se fait au niveau du routeur et des règles de NAT.

              • [^] # Re: Préfixe utile

                Posté par (page perso) . Évalué à 10.

                Je ne vois pas en quoi l'emploi du sous domaine vide (plop.com) nuirait à la distribution de services …

                Simple : tu ne peux pas y définir de CNAME, or le CNAME est la seule façon de définir un mappage humain et facile à gérer entre serveurs et services, et d'éviter une duplication d'information — répéter plusieurs fois l'adresse IP d'un serveur dans un fichier de zone — qui nuit à la clarté et peut être source d'erreur.

                Exemple pratique : j'héberge mon service web principal et mon service de boîtes aux lettres IMAP sur une machine nommée Pinard, et un service Git sur une machine nommée Jaja.

                www  CNAME  pinard
                imap CNAME pinard
                git  CNAME jaja

                Un jour, je m'aperçois que Pinard est trop chargée, alors que Jaja ne fout rien. Du coup, j'y déplace mon site web principal et je modifie cela :

                www  CNAME jaja
                imap CNAME pinard
                git  CNAME jaja

                Simple, rapide, efficace. Sans CNAME, je serais parti de ça :

                www  AAAA 2001:db8::1e6f:65ff:fe52:2b1a
                imap AAAA 2001:db8::1e6f:65ff:fe52:2b1a
                git  AAAA 2001:db8::3b8:a2ff:fe07:2b8c

                À ça, avec une étape « Quelle est l'adresse du second serveur déjà ? Ah, il sert au dépôt Git, donc je peux copier depuis cet enregistrement-là. » :

                www  AAAA 2001:db8::3b8:a2ff:fe07:2b8c
                imap AAAA 2001:db8::1e6f:65ff:fe52:2b1a
                git  AAAA 2001:db8::3b8:a2ff:fe07:2b8c

                Je ne sais pas ce que vous en pensez, mais moi je ne suis pas une machine, et je ne supporte pas de travailler ainsi. Il me faut une couche d'indirection plus humaine que ça.

          • [^] # Re: Préfixe utile

            Posté par . Évalué à 4.

            il n'y plus aucune justification technique à cela…

            Tout à fait. A moins que l'utilisateur n'hésite encore entre gopher.boursorama.com ou www.boursorama.com

            A l'heure ou les domaines ne pointent que sur des machines principalement destinées au web et ne réfèrent plus à des "réseaux" qui de tant en temps proposent le service, il n'y a plus nécessité d'identifier la machine qui porte le service web. Le www n'est plus là que pour des raisons de compatibilité (avec ceux qui le saisissent encore).

            Y'en a qui taperaient encore www.Linuxfr.org ??

            • [^] # Re: Préfixe utile

              Posté par . Évalué à 2.

              C'est un argument circulaire que tu emploies : "Faisons comme ça car les autres font comme ça."

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Préfixe utile

          Posté par . Évalué à 10.

          ahum

          Un article pour dire que "www", c'est bien:

          http://tanguy.ortolo.eu/blog/article47/why-www
          pointe vers l'article

          http://www.tanguy.ortolo.eu/
          ne fonctionne pas…

          ou comment promouvoir les bonnes habitudes chez les internautes…

          • [^] # Re: Préfixe utile

            Posté par (page perso) . Évalué à 2.

            http://www.tanguy.ortolo.eu/
            ne fonctionne pas…

            J'explique pourquoi le préfixe www est utile, réfutant ceux qui souhaitent sa disparition, mais je ne défends absolument pas qu'il doive exister à tout prix. Dans ce cas précis, j'ai déjà un préfixe tanguy devant le nom de ma zone, préfixe utilisé exclusivement pour un site Web, donc pas besoin d'en ajouter un puisque je peux déjà utiliser des CNAME à ma guise.

            • [^] # Re: Préfixe utile

              Posté par . Évalué à 0. Dernière modification le 29/08/13 à 12:47.

              Je suis tout à fait d'accord avec toi.
              Mais question bête: techniquement, comment on fait? Un enregistrement comme ca:

              example.com  CNAME  www.exemple.com.
              

              ou bien

              example.com  A  x.x.x.x
              

              fonctionneraient? (jamais essayé…) Et Apache ne bronche pas si on lui dit que le ServerName est juste le nom de domaine?

              • [^] # Re: Préfixe utile

                Posté par (page perso) . Évalué à 2.

                Tu peux pas avoir @ qui pointe vers un CNAME.

                • [^] # Re: Préfixe utile

                  Posté par (page perso) . Évalué à 7.

                  Pour être plus précis, il est interdit de définir un CNAME avec un nom qui porte déjà d'autres enregistrements, et pour une excellente raison : CNAME est un alias total, utilisé indépendamment de l'enregistrement demandé, donc avoir un CNAME et un autre enregistrement serait incohérent.

                  En effet, imagine :

                  example.com. CNAME example.net.
                  example.com. MX 10 beurre.example.com.
                  
                  example.net. MX 10 creme.example.net.

                  Maintenant, mets-toi à la place de quelqu'un avec un message pour yannick.le_kerantec@example.net. Tu cherches donc le MX de example.com, et tu tombes sur ça. Que faut-il croire :

                  • l'alias, qui indique qu'example.com a pour vrai nom example.net, qui a pour MX creme.example.net ;
                  • l'enregistrement MX direct, qui indique qu'example.com a pour MX beurre.example.com ?

                  Dans ton exemple donc, example.com porte déjà au moins deux enregistrements : un SOA et au moins un NS. Il est donc interdit d'y définir un CNAME.

                  Ce qu'il faudrait, ce serait un équivalent du CNAME spécifique au protocole demandé. Ça tombe bien, ça existe : MX pour le courrier électronique, et SRV pour tous les protocoles modernes. Mais HTTP est trop fossilisé pour permettre d'utiliser des trucs aussi modernes, d'où l'intérêt du préfixe www qui contourne ce problème, en le déplaçant en fait sur l'utilisateur d'une façon pas trop pénible à mon avis.

                  • [^] # Re: Préfixe utile

                    Posté par . Évalué à 1.

                    Ok, merci pour ta réponse.
                    Je dois être très fatigué ou très bête (ce qui expliquerait la note de mon commentaire précédent…) mais du coup je ne vois pas comment faire l'enregistrement DNS pour que http://example.com pointe vers mon serveur web…

                    • [^] # Re: Préfixe utile

                      Posté par (page perso) . Évalué à 4.

                      Je dois être très fatigué ou très bête (ce qui expliquerait la note de mon commentaire précédent…) mais du coup je ne vois pas comment faire l'enregistrement DNS pour que http://example.com pointe vers mon serveur web…

                      Deux solutions :

                      1. introduire une nouvelle version d'HTTP utilisant des enregistrements de service, et attendre que les navigateurs la prennent en charge, comme ça a été fait il y a bien longtemps avec le courrier électronique lors de l'introduction des enregistrements MX ;
                      2. mettre l'IP directement.

                      Pas d'autre solution.

          • [^] # Re: Préfixe utile

            Posté par (page perso) . Évalué à 3.

            http://www.tanguy.ortolo.eu/
            ne fonctionne pas…

            Mais http://www.ortolo.eu/ si, c’est écrit.

            • [^] # Re: Préfixe utile

              Posté par (page perso) . Évalué à 3. Dernière modification le 28/08/13 à 12:02.

              :-)

              D'ailleurs c'est idiot, il faut que je retire ce nom www.ortolo.eu puisque je n'ai pas de site Web principal associé à ce nom.

    • [^] # Re: Préfixe utile

      Posté par . Évalué à 2.

      Question bête : qu'est-ce qui empêcherait d'utiliser un enregistrement SRV de la forme _http._tcp.example.com. ?

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Préfixe utile

        Posté par (page perso) . Évalué à 4.

        La fossilisation du web. Le courrier électronique a su évoluer en introduisant les enregistrements MX, mais le web, ou plutôt les navigateurs web, sont beaucoup, beaucoup moins capables de s'adapter ainsi.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.