bien sûr que c'est possible! J'en parle même dans mon article!
Je cite un organisme qui propose ce service (payant): Google avec les Google Apps.
Beaucoup plus proche des libristes, l'Apinc (Association pour la Promotion de l'Internet Non Commercial) aussi propose le même service gratuitement:
http://jabber.apinc.org/.
Je suis un peu bête d'avoir oublié de parler de leur service (n'hésitez pas à ajouter ce lien à la dépêche!). Ce genre de service se démocratise de plus en plus et leur sécurisation est un de nos gros sujets du moment (cf. l'article et je détaille plus bas dans ce post).
L'un comme l'autre te permettrait d'avoir ton jid comme toi@tondomaine.fr, et ce sans que tondomaine.fr redirige vers quoi que ce soit d'autre que ton site web dans un navigateur.
J'explique même comment ça marche dans l'article (même si c'est vrai que je n'ai pas détaillé, car si je détaille tout, l'article est trop long, un reproche qu'on me fait souvent): on utilise les DNS SRV records.
Les ancêtres
La vieille méthode que http utilise encore, c'est effectivement juste de rediriger un domaine vers l'adresse principale qui lui est dédiée (ce qu'on appelle un enregistrement A pour IPv4 et AAAA pour IPv6. Il existe chez Mozilla un rapport de bug depuis 11 ans et demi pour utiliser les SRV et ne passer aux A/AAAA qu'en fallback, auquel je suis abonné moi-même depuis quelques années et qui a beaucoup de votes, d'abonnés, et a même eu des patchs envoyés par certains, mais Mozilla ne semble pas intéressé alors que le service http a déjà été enregistré par l'IANA).
Mais ça c'est la méthode antique, aucune flexibilité.
La relêve (actuelle)
Les enregistrements de service, c'est bcp plus subtil. On fait un enregistrement DNS qui dit quelles IPs regarder pour tel "service". Nous, on a deux enregistrement de service principaux: xmpp-client ou xmpp-server (selon qu'on parle au client ou serveur).
Une entité fait donc une requête DNS pour le domaine concerné du service désiré, et ça retourne une liste de couples (IP, port) à utiliser. Ça permet de préciser quelles IPs hébergent ton service Jabber et sur quel port (je connais au moins 2 serveurs qui n'utilisent pas le port par défaut sans aucun problème de fonctionnement alors que les services web doivent utiliser un truc moche à la example.com:8888 pour faire pareil), qui peut tout à fait être différent de ton serveur web.
Note que pour les petits organismes avec plusieurs serveurs mais sans beaucoup d'argent, ou sans tout une équipe d'administrateurs dédiés à l'infrastructure, SRV permet aussi un répartition de charges statique (donc basique mais suffisante pour beaucoup de petites et moyennes structures). Les enregistrements possèdent en effet un système de priorité et poids à utiliser conjointement pour se connecter aléatoirement (avec préférence) sur des machines différentes d'une utilisation à l'autre.
Un enregistrement normal (A/AAAA) n'a pas d'équivalent de ce système de répartition de charges car au mieux, on mélange les enregistrements A/AAAA aléatoirement (ils ont donc tous le même poids, on ne peut préciser les probabilités de connexion souhaités selon la machine, ce que fait SRV).
Donc oui, c'est possible, c'est même facile à faire. Ça demande des compétences très basique pour quiconque a les compétences de base pour avoir son propre domaine (c'est presque pas de l'administration info tellement c'est facile).
1/ tu t'inscris sur le service qui va héberger ton serveur.
2/ tu ajoutes un enregistrement DNS (pour ceux qui n'hébergent pas leurs propre serveur DNS, c'est en général simplement dans l'interface web de ton registrar) et tu ajoutes un (ou plusieurs si le service qui t'héberge a plusieurs machines) enregistrement de service xmpp-client et xmpp-server.
Et... c'est fini! XMPP fait ça depuis des années. En fait c'était déjà standard dans la RFC3920, comme je le dis dans l'article, donc on fait tous ça depuis au moins... 7 ans!
Google ne se gêne pas pour utiliser tout cela pour ses 5 machines XMPP client (et il a 5 machines xmpp-server différentes pour le même domaine):
$ ring -t SRV _xmpp-client._tcp.gmail.com
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk4.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 5
weight= 0
port= 5222
target= talk.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk1.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk2.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk3.l.google.com.
Bien sûr certains font encore la vieille méthode avec un enregistrement A et/ou AAAA sur un sous domaine de leur domaine principal. Genre im.example.com. Perso j'ai jamais compris pourquoi! Je ne connais pas un client ni un serveur de nos jours qui ne gère pas les SRV records. Et au final c'est plus compliqué car on doit créer et gérer un nouveau sous-domaine.
Le futur
Enfin la seule problématique avec cette solution est la sécurisation par certificats X509 (TLS). Les possesseurs d'un domaine n'aime pas toujours donner un certificats pour leur domaine principal à un service tier, et ça peut se comprendre (le service tier, si malveillant, aurait alors le pouvoir — presque officiel — pour se faire passer pour le domaine principal pour d'autres types de service, comme le web).
Il est en réalité possible d'associer un certificat à un enregistrement de service (il y a au moins un CA qui propose ce genre de certificat), mais malheureusement à ce que j'ai compris les navigateurs web (encore eux!) ne regardent pas vraiment ce champs et donc cette sécurité passe à la trappe à l'heure actuelle. C'est pourquoi (encore comme je le dis dans l'article! J'explique trop mal?) pas mal de gens réfléchissent à une solution pour rendre ce passage de pouvoir à la fois aussi sécurisé que si on le faisait nous-même mais sans donner les pleins pouvoirs sur tout le domaine. Y a au moins un brouillon de RFC proposé sur le sujet (mais je l'ai pas encore lu, je ne connais pas sa pertinence).
Et après j'en lis plus haut que XMPP est une vieux truc alors qu'on est parmi le top de la technologie Internet (on est parmi les premiers à utiliser les technologies les plus récentes. SCRAM par exemple, XMPP est LA technologie qui fait vraiment démarrer ça et comparé aux vieux mécanismes SASL, c'est vraiment génial. SRV aussi, nous sommes parmi ceux qui ont créé une adoption massive; bien que sur le coup, je crois que SIP était avant nous) et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres. Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'intéropérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 10.
Salut,
bien sûr que c'est possible! J'en parle même dans mon article!
Je cite un organisme qui propose ce service (payant): Google avec les Google Apps.
Beaucoup plus proche des libristes, l'Apinc (Association pour la Promotion de l'Internet Non Commercial) aussi propose le même service gratuitement: http://jabber.apinc.org/. Je suis un peu bête d'avoir oublié de parler de leur service (n'hésitez pas à ajouter ce lien à la dépêche!). Ce genre de service se démocratise de plus en plus et leur sécurisation est un de nos gros sujets du moment (cf. l'article et je détaille plus bas dans ce post).
L'un comme l'autre te permettrait d'avoir ton jid comme toi@tondomaine.fr, et ce sans que tondomaine.fr redirige vers quoi que ce soit d'autre que ton site web dans un navigateur.
J'explique même comment ça marche dans l'article (même si c'est vrai que je n'ai pas détaillé, car si je détaille tout, l'article est trop long, un reproche qu'on me fait souvent): on utilise les DNS SRV records.
Les ancêtres
La vieille méthode que http utilise encore, c'est effectivement juste de rediriger un domaine vers l'adresse principale qui lui est dédiée (ce qu'on appelle un enregistrement A pour IPv4 et AAAA pour IPv6. Il existe chez Mozilla un rapport de bug depuis 11 ans et demi pour utiliser les SRV et ne passer aux A/AAAA qu'en fallback, auquel je suis abonné moi-même depuis quelques années et qui a beaucoup de votes, d'abonnés, et a même eu des patchs envoyés par certains, mais Mozilla ne semble pas intéressé alors que le service http a déjà été enregistré par l'IANA).
Mais ça c'est la méthode antique, aucune flexibilité.
La relêve (actuelle)
Les enregistrements de service, c'est bcp plus subtil. On fait un enregistrement DNS qui dit quelles IPs regarder pour tel "service". Nous, on a deux enregistrement de service principaux: xmpp-client ou xmpp-server (selon qu'on parle au client ou serveur).
Une entité fait donc une requête DNS pour le domaine concerné du service désiré, et ça retourne une liste de couples (IP, port) à utiliser. Ça permet de préciser quelles IPs hébergent ton service Jabber et sur quel port (je connais au moins 2 serveurs qui n'utilisent pas le port par défaut sans aucun problème de fonctionnement alors que les services web doivent utiliser un truc moche à la example.com:8888 pour faire pareil), qui peut tout à fait être différent de ton serveur web.
Note que pour les petits organismes avec plusieurs serveurs mais sans beaucoup d'argent, ou sans tout une équipe d'administrateurs dédiés à l'infrastructure, SRV permet aussi un répartition de charges statique (donc basique mais suffisante pour beaucoup de petites et moyennes structures). Les enregistrements possèdent en effet un système de priorité et poids à utiliser conjointement pour se connecter aléatoirement (avec préférence) sur des machines différentes d'une utilisation à l'autre.
Un enregistrement normal (A/AAAA) n'a pas d'équivalent de ce système de répartition de charges car au mieux, on mélange les enregistrements A/AAAA aléatoirement (ils ont donc tous le même poids, on ne peut préciser les probabilités de connexion souhaités selon la machine, ce que fait SRV).
Donc oui, c'est possible, c'est même facile à faire. Ça demande des compétences très basique pour quiconque a les compétences de base pour avoir son propre domaine (c'est presque pas de l'administration info tellement c'est facile).
1/ tu t'inscris sur le service qui va héberger ton serveur.
2/ tu ajoutes un enregistrement DNS (pour ceux qui n'hébergent pas leurs propre serveur DNS, c'est en général simplement dans l'interface web de ton registrar) et tu ajoutes un (ou plusieurs si le service qui t'héberge a plusieurs machines) enregistrement de service xmpp-client et xmpp-server.
Et... c'est fini! XMPP fait ça depuis des années. En fait c'était déjà standard dans la RFC3920, comme je le dis dans l'article, donc on fait tous ça depuis au moins... 7 ans!
Google ne se gêne pas pour utiliser tout cela pour ses 5 machines XMPP client (et il a 5 machines xmpp-server différentes pour le même domaine):
Bien sûr certains font encore la vieille méthode avec un enregistrement A et/ou AAAA sur un sous domaine de leur domaine principal. Genre im.example.com. Perso j'ai jamais compris pourquoi! Je ne connais pas un client ni un serveur de nos jours qui ne gère pas les SRV records. Et au final c'est plus compliqué car on doit créer et gérer un nouveau sous-domaine.
Le futur
Enfin la seule problématique avec cette solution est la sécurisation par certificats X509 (TLS). Les possesseurs d'un domaine n'aime pas toujours donner un certificats pour leur domaine principal à un service tier, et ça peut se comprendre (le service tier, si malveillant, aurait alors le pouvoir — presque officiel — pour se faire passer pour le domaine principal pour d'autres types de service, comme le web).
Il est en réalité possible d'associer un certificat à un enregistrement de service (il y a au moins un CA qui propose ce genre de certificat), mais malheureusement à ce que j'ai compris les navigateurs web (encore eux!) ne regardent pas vraiment ce champs et donc cette sécurité passe à la trappe à l'heure actuelle. C'est pourquoi (encore comme je le dis dans l'article! J'explique trop mal?) pas mal de gens réfléchissent à une solution pour rendre ce passage de pouvoir à la fois aussi sécurisé que si on le faisait nous-même mais sans donner les pleins pouvoirs sur tout le domaine. Y a au moins un brouillon de RFC proposé sur le sujet (mais je l'ai pas encore lu, je ne connais pas sa pertinence).
Et après j'en lis plus haut que XMPP est une vieux truc alors qu'on est parmi le top de la technologie Internet (on est parmi les premiers à utiliser les technologies les plus récentes. SCRAM par exemple, XMPP est LA technologie qui fait vraiment démarrer ça et comparé aux vieux mécanismes SASL, c'est vraiment génial. SRV aussi, nous sommes parmi ceux qui ont créé une adoption massive; bien que sur le coup, je crois que SIP était avant nous) et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres. Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'intéropérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]