happyDomain - On devrait tous avoir un nom de domaine

Posté par  (site web personnel) . Édité par Pierre Jarillon, patrick_g, Benoît Sibaud, Ysabeau 🧶 🧦 et palm123. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
44
24
mai
2022
Administration système

Acheter un nom est facile en quelques clics, très bon marché avec une poignée d’euros par an. Rien de plus simple. En revanche, paramétrer ces caractéristiques relève de compétences d’expert.

Notre projet est né d’une idée simple : si on simplifiait (enfin) l’usage des noms de domaine ? Parce qu’ils sont un élément clef pour assurer sa vie privée sur Internet et parce qu’il n’est pas toujours simple de se repérer dans les interfaces parfois obscures des fournisseurs, il nous semblait indispensable de créer un outil utilisable par tout le monde, de Monsieur et Madame Tout-le-Monde à l’administrateur système le plus aguerri.

happyDomain est un logiciel libre qui permet à chacun de surmonter cette complexité. Nous verrons ici tous les avantages de disposer de son ou ses noms de domaine et comment happyDomain fonctionne.

Sommaire

Le DNS, qu’est-ce que c’est ?

Le DNS est à la base de tous les échanges sur l’Internet.

Lorsque votre ordinateur dialogue avec un autre appareil, chacun dispose d’une adresse IP pour se connecter ensemble. C’est analogue de votre numéro de téléphone ou votre adresse postale.

Vous avez déjà vu ces adresses : elles sont sous la forme 123.123.123.123 pour l’ancienne version 4 et sous la forme 2001:1234:567::89 pour la nouvelle version 6.

Vous vous imaginez taper 2001:910:800::52 dans la barre d’adresse de votre navigateur pour afficher le site web de French Data Network ?

Non.

Nous non plus.

Transformez 20001:910:800::52 en fdn.fr et vous obtenez un nom humainement simple à retenir.

D’autre part, si FDN décide de changer de serveur (ou de prestataire) pour l’hébergement de son site, elle n’aura pas besoin d’informer ses utilisateurs de ce changement, ou de passer par une procédure de portabilité comme cela existe pour les numéros de téléphone lorsque l’on souhaite changer d’opérateur. Ainsi, même 20 ans après, chaque article de Wikipédia cité sur LinuxFr.org est toujours accessible, alors qu’ils ont changé plusieurs fois l’emplacement de leurs serveurs.

C’est donc à cela que sert le DNS : permettre la stabilité des liens et des adresses URL en général, sous un format évocateur (nom d’une marque, d’un lieu, d’un nom de famille…)

Un peu d’architecture

Les noms de domaines sont organisés de manière hiérarchique, que l’on peut se représenter sous la forme d’un arbre.

Quelle est l’organisation hiérarchique ?

L’ICANN régule aujourd’hui la « racine », que l’on note ..

Elle contient les informations sur les domaines dits de premier niveau, souvent appelés “tld” (Top Level Domain), comme .org, .fr, .com, .tv, etc. Ils sont gérés par d’autres organismes et d’autres serveurs. Par exemple, pour les domaines .fr relatifs à la France, l’organisme régulateur est l’AFNIC (Association Française pour le Nommage Internet en Coopération). Cette association est notamment chargée de centraliser la distribution des noms de domaines sous .fr.

Des bureaux d’enregistrements agréés comme OVH, Gandi, etc. revendent les domaines.

L’AFNIC, ou plutôt ses serveurs, indique, à qui lui demande, l’adresse à laquelle contacter le serveur de noms de domaines de l’entreprise ou du particulier à qui le domaine a été attribué. C’est en contactant ce serveur de noms, pas celui de l’AFNIC, mais celui de l’entreprise ou du particulier, que l’on obtiendra enfin l’adresse IP du service que l’on cherchait à contacter, compréhensible par les machines.

Exemple d’une résolution de nom

Le DNS est une structure arborescente décentralisée. Pour joindre le site www.fdn.fr depuis votre ordinateur, celui-ci doit interroger un serveur résolveur de noms de domaine. Chaque fournisseur d’accès à Internet en fournit un automatiquement.

Ce serveur résolveur, qui ne connaît que les 13 serveurs racines à son lancement, va interroger l’un d’eux, lequel va lui envoyer l’adresse IP des serveurs faisant autorité pour .fr.

Les serveurs de l’AFNIC faisant autorité pour .fr vont à leur tour indiquer au résolveur l’adresse IP des serveurs faisant autorité pour fdn.fr.

Pour terminer, c’est ce dernier serveur de noms qui va fournir l’adresse IP du serveur web www.fdn.fr. Pfiou !

Vous comprenez maintenant l’importance de ce système et des serveurs de noms de domaines, en anglais Domain Name System (DNS) ?

Sans cette organisation invisible, pas d’adresse simple à taper dans votre navigateur.

Les heurts du DNS

Vous avez trouvé ça compliqué ?

Nous aussi.

Ajoutez que les interfaces des hébergeurs de noms de domaine sont à la fois truffées de mots techniques obscurs pour un débutant et limitées pour les utilisateurs avancés. Double peine.

C’est pour y remédier que nous avons créé happyDomain !

En effet, comprendre cette organisation des coulisses d’Internet et savoir gérer votre zone DNS sont pourtant essentiels pour acquérir votre indépendance sur le web.

Comment vous assurer de la maîtrise de votre expression par vos blogs ou vos sites web ? Comment vous prémunir de changements indésirables ?

Saviez-vous par exemple que les adresses @orange.fr ou @wanadoo.fr expirent 6 mois après la résiliation de l’abonnement ? Toute votre production et toutes vos archives sont détruites.

Qu’adviendra-t-il de votre adresse @gmail.com lorsque l’usage des données personnelles sera régulé par des lois contraignantes (SafeHarbor invalidé en 2015, Bouclier de protection des données UE-États-Unis invalidé en 2020, un potentiel futur nouvel accord pour 2022, Digital Services Act, Digital Market Act, etc.) et que Google aura coupé brutalement votre service, par manque de rentabilité (voir KilledByGoogle.com) ?

Si vous disposez de votre nom de domaine, comme www.example.com, vous pouvez changer de prestataire à volonté. Inutile d’avertir tous vos contacts que l’adresse de votre site ou que votre adresse électronique a changé.

Utiliser vos noms de domaine paraît donc primordial pour vous rendre indépendant de vos prestataires.

Le principal obstacle de votre liberté est la simplicité apparente des grands prestataires comme Google qui vous préservent de la complexité du système.

En rendant simple les coulisses du DNS, nous vous offrons votre liberté.

Dans le même temps, nous offrons aussi aux administrateurs aguerris un logiciel qui soulagera leurs efforts en réunissant toutes les fonctionnalités nécessaires à la bonne gestion d’une zone DNS.

À quoi sert happyDomain ?

happyDomain est une interface web moderne, faite par des experts des noms de domaines. Vous pouvez l’utiliser en ligne ou l’installer chez vous. Un minuscule serveur comme une Raspberry Pi est suffisant !

Vous pouvez gérer vos domaines hébergés chez des hébergeurs standards ou administrer votre propre serveur faisant autorité comme bind, knot ou PowerDNS.

En outre, happyDomain est construit sur une API REST, permettant aux DevOps d’automatiser toutes les tâches liées aux domaines !

Il s’agit d’un projet libre, sous licence CeCILL 2.1, une licence compatible et comparable à l’AGPL 3.0. Elle garantit son application dans le droit français et international.

Où en est le projet en 2022 ?

Toute personne ayant déjà eu affaire aux interfaces rustiques des hébergeurs peut aujourd’hui utiliser le logiciel happyDomain.

En termes de fonctionnalités :

  • L’administration des zones DNS chez près de 15 bureaux d’enregistrement, dont OVH, Gandi…
  • L’administration depuis un serveur DNS implémentant le Dynamic DNS (RFC 2136) : bind, knot, PowerDNS, etc.
  • Un résolveur pour tester ou déboguer.
  • L’historique (encore rudimentaire) pour pouvoir revenir en arrière facilement en cas d’erreur.
  • L’affichage avant application des changements qui seront effectués sur la zone pour limiter vos erreurs.
  • Une visualisation « abstraite » de la zone, où les éléments sont regroupés astucieusement : voir le paragraphe Abstraction du domaine.

À quoi ça ressemble ?

Après vous être inscrit, avec un identifiant et un mot de passe, vous désignez les domaines que vous souhaitez voir gérés par happyDomain.

connection_page.png
L’utilisation d’OVH comme fournisseur ne demande d’ailleurs aucune action compliquée : il suffit de se connecter !

Création du fournisseur de domaine

providers_list.png

Exemple avec OVH

provider_ovh_select.png

provider_ovh_connect.png

Vous possédez des domaines chez plusieurs fournisseurs ? Ils sont regroupés sur la page d’accueil.

domains-list.png

La simplicité est désormais au bout des doigts : vous pouvez modifier les enregistrements de la zone DNS via l’interface, quels que soient leur type et leur valeur.

domain-abstract.png

Lorsque vous êtes prêt à publier vos modifications, une fenêtre vous montre auparavant les différences :

zone-diff.png

Abstraction du domaine

L’élément clef est l’abstraction créée à la volée par happyDomain : il regroupe les services de manière efficace.

Par exemple, pour déclarer un serveur Matrix au domaine example.com, il faut ajouter dans l’idéal l’enregistrement SRV suivant :

_matrix._tcp.example.com.  SRV 10 0 8448 matrix.example.com.

Outre les divers champs dont on oublie l’ordre et la signification, on voit ici que l’enregistrement est ajouté sur un sous-domaine spécial d’example.com. Dans happyDomain, ce service est référencé sous example.com, comme on peut s’y attendre, et non pas sous _matrix._tcp.example.com.

L’origine de la zone, les différents enregistrements nécessaires pour opérer un serveur de courrier électronique ou bien encore les délégations de noms, tout cela est regroupé et trié. Vous obtenez ainsi une vision plus claire de la zone, moins sujette aux erreurs.

Simplifier les services

La vie d’une zone DNS est ponctuée par l’ajout de services : ajouter un blog, un serveur de messagerie, un site web, etc, en utilisant la plupart du temps un prestataire comme Google, Over-blog, OVH, Wordpress, Ionos.

C’est là qu’il est parfois compliqué de s’y retrouver : les documentations sont très disparates et les interfaces rustiques des hébergeurs de noms de domaines n’aident pas à faire des documentations faciles d’accès pour le grand public.

Nous réglons cet inconvénient grâce à un formulaire pour chaque prestataire qui :

  • récupère automatiquement les informations techniques en accédant au compte de l’utilisateur,
  • à défaut, guide l’utilisateur pour récupérer les informations dont il a besoin.

Bien sûr, nous sommes loin d’avoir fait le tour des centaines de services existant sur Internet, mais on y travaille !

Comment l’essayer ?

Au choix :

  1. En ligne : créez votre compte utilisateur sur https://happydomain.org/.
  2. Sur votre serveur : téléchargez les fichiers binaires ici : https://get.happydomain.org/master/. Vous en trouverez pour Linux, aussi bien pour les machines et serveurs classiques (amd64), que pour les Raspberry Pi récentes telles armv7 ou arm64 et plus anciennes comme armhf.
  3. Vous pouvez aussi lancer notre image Docker :
docker container run -e HAPPYDOMAIN_NO_AUTH=1 -p 8081:8081 happydomain/happydomain

L’option NO_AUTH contourne la création de compte utilisateur, ce qui est idéal pour tester. Bien sûr, bannissez-la dans la vie courante.

Rendez-vous ensuite sur http://localhost:8081/ pour commencer à gérer vos domaines !

Et après ?

happyDomain progresse et nous avons besoin de vos talents pour le rendre encore plus simple et plus utile.

Utilisateurs, administrateurs, néophytes, donnez votre avis pour orienter les prochaines fonctionnalités en répondant à ce sondage au plus tard le 5 juin 2022.

Développeurs, traducteurs, rédacteurs, concepteurs d’écrans, testeurs, rejoignez l’équipe des joyeuxDNS ! Vous trouverez notre dépôt Framagit ici :
➡️ https://framagit.org/happyDomain/happyDomain

Aller plus loin

  • # Auto hébergement

    Posté par  . Évalué à 3.

    On est d'accord, ça a l'air bien pratique.
    Mais ça en solutionne en rien le problème de reverse DNS qui fait penser à beaucoup de serveurs que mes mais sont des spams ?
    En auto hébergement s'entend.
    J'ai beau faire tout ce que je peux pour montrer patte blanche (DKIM, DMARC et je ne sais plus quoi encore), dès que le MTA en face tente un reverse sur mon IP, il tombe sur x-y-z-t.subs.proxad.net et non pas sur mon domaine.
    On est d'accord qu'il n'existe pas de solution à ce problème, sauf à louer un "vrai" serveur "dans le cloud" ?

    • [^] # Re: Auto hébergement

      Posté par  . Évalué à 3.

      http://www.actusfree.fr/reverse-dns.htm

      • [^] # Re: Auto hébergement

        Posté par  . Évalué à 7. Dernière modification le 24 mai 2022 à 14:08.

        C'est globalement non fonctionnel chez free depuis qq années en fonction de votre mode d'accès: ipv4 partagée, fibre …

        Reverse dns

    • [^] # Re: Auto hébergement

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 24 mai 2022 à 15:12.

      La solution intermédiaire avant de louer un serveur c'est de prendre un VPN chez un FAI associatif et de faire sortir son trafic SMTP par là. FDN propose ce genre de service et permet de personnaliser son reverse IPv4, et ils permettent aussi de déléguer la zone de reverse IPv6. (On peut aussi prendre un abonnement directement chez un FAI associatif)

  • # 24/05/2022 > 30/04/2022 !

    Posté par  (site web personnel) . Évalué à 3.

    Utilisateurs, administrateurs, néophytes, donnez votre avis pour orienter les prochaines fonctionnalités en répondant à ce sondage avant le 30 avril 2022.

    Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

  • # Le retour de happydns :-)

    Posté par  . Évalué à 2. Dernière modification le 24 mai 2022 à 10:09.

    Hey,
    c'est cool c'est le retour de happydns que j'ai testé il y a quelques temps … le hic c'est que quand j'ai eu des bugs je n'ai pas réussi à trouver le code source.

    Il me semble que https://framagit.org/happyDNS est toujours vide ?

    Pas plus de chance sur https://github.com/happyDNS …

    Et donc du coup c'était passé d'une manière assez violente de cool-libre à pas-libre du tout.

    Et donc, vous en êtes où du code ?

    eric.linuxfr@sud-ouest.org

  • # ça manque d'une démo

    Posté par  . Évalué à 4.

    Pour essayer on doit créer un compte, c'est dommage. J'aimerai découvrir le sérieux et l'ergonomie avant de m'enregistrer. Bref, il manque une démo avec un domaine bidon pour voir ce qu'on peut faire avec les zones.

    • [^] # Re: ça manque d'une démo

      Posté par  . Évalué à -1.

      Je sais pas si ça aide, mais dans l'article il y a ce passage :

      "L’option NO_AUTH contourne la création de compte utilisateur, ce qui est idéal pour tester. Bien sûr, bannissez-la dans la vie courante."

      :)

  • # Magnifique!

    Posté par  (site web personnel) . Évalué à 5.

    C'est magnifique comme projet.

    Du coups, peut être que je pourrai m'en servir, plutôt que de devoir gérer et apprendre plusieurs interfaces chez plusieurs prestataires.

    Le choix de passer par un gros prestataire connu pour les emails, par exemple, c'est un peu le côté anonymat, ce qui est bien plus difficile avec un nom de domaine personnel.

    Sinon, beaucoup de gens utilisent des services "gratuits", et même quand il y a des soucis ou des lenteurs. Par exemple, Gmail, c'est très lent, et avec des pièces jointes de quelques Mo, ça n'est pas problématique, mais quand il faut déplacer ou migrer des milliers d'emails, et que ça fait plusieurs centaines de Mo, alors là… il faut faut être patient… très patient… mais c'est gratos.

    J'ai eu un client "pro", pour qui l'utilisation des emails était vital, mais il a préféré rester chez ses fournisseurs "gratuits" malgré les déboires. Plus tard, Gmail à restreint son compte quand il a dépassé les 15Go. Il ne pouvait plus recevoir des emails de plus d'une centaine de Ko… et chercher les emails volumineux dans un premier temps pour les purger etc…(galère, vu que c'est lent, même en IMAPs)…

    Ce client avait bien un nom de domaine à lui, mais avec redirection d'email vers Gmail… et il a refusé de prendre une option messagerie chez un prestataire… même pour une poignée d'Euros… (je ne sais plus à combien est le plan MX chez OVH, mais ça reste très raisonnable).

    Chacun ses priorités.
    Merci pour ce projet.

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Pas convaincu…

      Posté par  . Évalué à 2.

      on peut ajouter :
      - pas de numéro de version sur l'espace téléchargement : https://get.happydomain.org/master/
      - on constate un décalage dans le temps important des dernière publications sur Docker : https://hub.docker.com/r/happydns/happydomain/tags ; pas ne tags non plus ; pas de code source associé ; un lien vers le dépot framagit/docker me semble indispensable.
      - nombreux liens happyDNS rémanents sur de nombreux espaces de documentation.

      Cependant, la description du projet donne envie de l'expérimenter. Bravo pour cette initiative.

      • [^] # Re: Pas convaincu…

        Posté par  (site web personnel) . Évalué à 8.

        Attention les images sont hébergées sur https://hub.docker.com/r/happydomain/happydomain et non happydns/happydomain. Je viens de mettre à jour le readme pour l'indiquer ! (et le site qui pointait au mauvais endroit)

        Et on a corrigé le soucis avec le serveur qui distribuait la documentation https://help.happydomain.org/ est maintenant bien accessible.

        Le projet est encore jeune, on cherche avant tout à savoir s'il présente un intérêt et si oui, ce qu'il faut améliorer pour qu'il soit utile. Tous vos retours sont bons à prendre, merci !

  • # surcouche

    Posté par  (Mastodon) . Évalué à 10.

    Je n'ai pas bien compris en quoi installer une surcouche supplémentaire va rendre l'aquisition et la gestion de son DNS plus facile. Il me semble que la plupart des registrars ont une interface pour changer les entrées DNS de façon simplifiée.

    • [^] # Re: surcouche

      Posté par  . Évalué à 4.

      J'ai pas encore regardé dans le détail mais si j'ai bien compris, quand il parle de simplification il parle surtout d'une interface plus jolie, plus clair et unique, là où chaque hébergeur a sa propre interface.

      J'ai pas compris non plus le fait de mettre en avant que c'est plus simple via cette app avec l'argument "En outre, happyDomain est construit sur une API REST, permettant aux DevOps d’automatiser toutes les tâches liées aux domaines !".

      Si le devops veut passer par les api, en quoi cest plus simple d'ajouter un serveur intermédiaire pour atteindre les api de Gandi par exemple ?

      Le côté user freindly pour mr tout le monde, je suis ok. Pour une utilisation avancé, j'ai l'impression que c'est empiler des services sur des serveurs, alors que l'on parle régulièrement de sobriété énergétique (le chacun gère son truc sur son serveur, même si cest un raspberry, me pause question quand même. Surtout si doublon avec l'hébergeur).

      Je crache pas sur le projet, mais la description éveil en moi plus d'inquiétude que de soulagement (pourtant je suis le premier a trouver que les interfaces de gandi ou ovh sont pas tjrs très intuitive).

      Cest un sujet intéressant, mais peut être mal présenté : quel est le cas d'usage de départ ?

      :)

      • [^] # Re: surcouche

        Posté par  (site web personnel) . Évalué à 2.

        Lorsque l'on cherche à automatiser le déploiement de services (par exemple on va pousser sur une nouvelle branche de notre dépôt une fonctionnalité à tester), il faut créer des domaines à la volée. Idéalement on évite de faire ça sur Internet, mais on fait plutôt ça sur un serveur interne dont le nom de domaine et l'IP ne sont résolvable et accessible qu'au sein de l'entreprise.

        Généralement dans une entreprise les noms de domaine internes sont gérés par un bête serveur bind, dont seule la DSI a l'accès. L'idée est donc de mettre à disposition tout ou partie du domaine interne, via une API, avec des permissions que la DSI pourra gérer.

        Il y a bien d'autres solutions possibles pour les DevOps, ce n'est pas notre cible initiale ; mais ça peut rendre service dans certaines situations.

  • # petit bug

    Posté par  . Évalué à 4.

    à la création du compte sur happydomain on reçoit un courriel pour le valider sur happydns. Firefox n'y retrouve pas ses petits.

    • [^] # Re: petit bug

      Posté par  (site web personnel) . Évalué à 1.

      Qu'est-ce qu'il se passe dans Firefox ?

      • [^] # Re: petit bug

        Posté par  . Évalué à 3.

        le compte et son mot de passe sont associés à l'autre domaine, donc Firefox ne les propose pas.

        • [^] # Re: petit bug

          Posté par  (site web personnel) . Évalué à 3.

          Ah oui ! tous les liens des mails pointaient encore sur happydns.org. On vient de le corriger. Merci pour le signalement orfenor !

  • # Liens pas clair pour les mail

    Posté par  . Évalué à 7. Dernière modification le 25 mai 2022 à 18:46.

    Dans l'article il est fait la démonstration que les boite mail @orange ou autre peuvent avoir une durée de vie assez courte diront nous

    Et que donc avec cet app, les gens sont sauvés car ils ont leur propre nom de domaine.

    Je comprends pas trop le lien entre les 2.
    Si j'ai mon propre nom de domaine, il me faut soit gérer mon serveur de mail soit passer par un prestataire, non ?
    Et donc rien me garanti que mon prestataire sera plus réglo que orange and co.

    Le fait d'avoir mon propre nom de domaine, me garanti seulement de pouvoir garder le nom, pas de garder les mails. Et encore, je ne sais pas dans quelle mesure je suis protégé pour garder mon nom de domaine. Il y a des cas en France, de particulier qui on perdu leur nom de domaine (alors que propriétaire depuis longtemps) suite a une action en justice de l'état (donc le coup du "tu achètes ton nom de domaine donc tu est protégé des lois, me semble pas être d'une grande garantie)

    Je trouve le sujet intéressant mais je suis pas convaincu par les argument mis en avant dans l'article.

    Si l'app permet de déployer son propre serveur de mail avec toutes les config qui vont bien, je vois l'intérêt, mais si cest juste sur la gestion des nom et dns, tous les arguments sur les risque de perte des mails me semble inutile.

    Ajouter + de machine individuelle me semble être un bon point pour une souveraineté maximal, mais cela est fait au détriment de la planète. Je ne sais donc pas bien si la démarche collective ne devrait elle pas plutôt être de trouver un moyen de centraliser les services en augmentant le niveau de sécurité et les garanties de disponibilité (je dis pas que cest simple, mais empiler des services me semble pas augmenter forcément les garanties et la sécurité).

    • [^] # Re: Liens pas clair pour les mail

      Posté par  (site web personnel) . Évalué à 3.

      La remarque ci-dessus rappelle très justement certaines réquisitions comme celles du france.com ou du milka.fr.

      La réservation d'un nom de domaine n'offre effectivement aucune garantie de pouvoir l'utiliser. Pour le réquisitionner il suffit d'avoir les moyens de s'offrir les services d'une armée d'avocats spécialisés en droit de propriété à l'international.
      Dans la dépêche je ne vois aucune mention sur de possibles protections contre de telles réquisitions.

      Je n'y vois pas non plus le fait qu'il soit possible d' "acheter" un nom de domaine puisqu'une réservation n'implique pas la propriété mais seulement un droit d'usage limité.

      Je lis seulement que la réservation d'un nom de domaine est une condition qui permet de rester indépendant des prestataires.

    • [^] # Re: Liens pas clair pour les mail

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 27 mai 2022 à 10:54.

      On explique dans la dépêche que le fait de disposer d'un nom de domaine permet d'avoir de la portabilité d'un prestataire à l'autre. Le heurt principal est qu'en utilisant l'adresse d'un prestataire, on est pied et poings liés à lui s'il s'agit de notre adresse principale car cela prend des mois, voire des années, de faire basculer tout son carnet d'adresse vers l'adresse d'un nouveau prestataire.

      Lorsque l'on dispose de son propre nom de domaine, le basculement d'un prestataire à l'autre se fait seulement avec des contraintes techniques : il n'y a pas besoin de contacter tout son carnet d'adresse pour l'informer de l'emplacement du nouveau prestataire.

      Lorsque l'on change d'opérateur téléphonique mobile, on est bien content de pouvoir conserver son numéro, pour ne pas avoir à prévenir chacun de nos contacts (y compris ceux que l'on a oublié d'inscrire dans notre carnet d'adresse, ou à qui l'on a distribué notre carte de visite avec notre ancien numéro dessus). C'est le même principe qui empêche de nombreux particuliers et professionnels de changer de fournisseur d'accès internet : demandez autour de vous à des personnes qui ont des adresses @orange.fr floquées sur leur camion…

      Il ne s'agit donc pas d'ajouter des machines individuelles (bien que cela soit possible), mais d'avoir la tranquillité d'esprit de pouvoir quitter son prestataire actuel si celui-ci ne correspond plus à nos attentes. Cette liberté passe par le DNS, que l'on cherche donc à rendre plus accessible.

      • [^] # Re: Liens pas clair pour les mail

        Posté par  . Évalué à 1.

        Merci pour l'explication qui me semble plus clair maintenant.je pense que j'avais mal compris le chapitre sur le DNS qui a un bloc qui sous entendait des chose à mes yeux sur la pérennité des données.

        Bonne continuation pour votre projet en tout cas :)

  • # infra as code (IaC) - Ansible

    Posté par  . Évalué à 5.

    Je suis pas fan des GUI et donc pas le bon public pour ce type de projet.
    Mais merci pour l'initiative et le partage.

    Je pense que quand on a un ou deux registrars, passer par leurs différentes consoles web n'ai pas bien compliqué. Et avoir beaucoup plus que deux registrars est probablement pas une bonne pratique. Donc le gain à avoir une WebGUI pour tout unifier, au risque de ne pas avoir certaines fonctionnalités, je suis pas convaincu.

    Je préfère l'infra as code et mettre la description de mon infra sous gestionnaire de version.

    Pour cela j'utilise Ansible et le plugin ansible-ovh-dns. J'imagine qu'il en existe pour d'autres registrars.

    C'est plutôt simple à utiliser : dans un playbook :

    - name: ensure DNS
  hosts: localhost
  tasks:
    - ovh_dns: state=present domain=mydomain.tld name=www type=A value=A.B.C.D
    - ovh_dns: state=present domain=mydomain.tld name=site type=CNAME value=www
    - ...

    Ensuite, dans un shell :

    ansible-playbook -M modules dns-playbook.yml

    et Ansible va s'assurer que la configuration chez OVH est conforme à la déclaration dans le playbook.

    localhost : ok=32   changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

    Ça s'appuie sur le wrapper python pour les API OVH.

    Le seul petit inconvénient est que la durée de traitement s'allonge avec le nombre d'entrées car chacune est revérifiée à chaque run ; compter environ 1seconde par entrée.

    À l'usage, c'est très serein en tout cas ; plus besoins d'ouvrir un navigateur.

Suivre le flux des commentaires

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