Le 20 août 2024, j'ai découvert la coopérative LeBureau.coop.

Je disais :

Dans ma #todo-list :

• Transférer un de mes noms de domaine vers LeBureau.coop pour tester ;
• Acheter des parts pour devenir sociétaire soutien.

source

4 mois plus tard, le 3 janvier 2025, c'est chose faite : pour tester, j'ai transféré un domaine avec extension .xyz via le formulaire de la page https://lebureau.coop/creation-ou-transfert-de-noms-de-domaine/.

Pour le moment, l'expérience est bonne.

Voici ce que j'ai payé par virement :

• Souscription de 1 part sociale : 8 €
• Transfert du domaine en .xyz : 25,42 €
• Total : 33,42 € TTC

Après la réception du virement bancaire, j'ai reçu un e-mail qui ressemble à ceci :

Bonjour

Nous avons bien reçu ton virement pour le transfert de nom de domaine.

Pour avancer sur le transfert, il faut saisir le code d'autorisation de transfert et la zone DNS sur https://lebureau.coop/ventes/edf199....../tech/

Voici quelques éléments de documentation :

• désactiver le verrouillage de transfert : https://docs.gandi.net/fr/noms_domaine/transfert_sortant/transfert_lock.html
• récupérer le code : https://docs.gandi.net/fr/noms_domaine/transfert_sortant/auth_code.html
• récupérer la zone DNS : sur l'interface web de gandi, aller sur la page du domaine, puis sur "enregistrements dns" puis sur "vue avancée", et c'est le contenu de la zone de texte
• désactiver DNSSEC : https://docs.gandi.net/fr/noms_domaine/utilisateurs_avances/dnssec.html?highlight=dnssec#comment-installer-dnssec-sur-votre-nom-de-domaine-avec-livedns

Une fois que la zone a été saisie, nous pourrons faire le changement de serveur DNS pour éviter toute coupure pendant le transfert, une fois que c'est fait, le code d'autorisation servira à lancer le transfert à proprement parler.

Cordialement,
Arthur Vuillard

J'ai ensuite reçu un accès à https://zones.lebureau.coop qui est une instance PowerDNS-Admin qui permet de configurer ses DNS Record du domaine.

Pour le moment, les demandes de changement de serveurs DNS doivent se faire par e-mail.

Lors de ce transfert, j'ai reçu des e-mails du registrar BookMyName.

Cette situation est tout à fait normale. Comme expliqué dans la vidéo "Les noms de domaine pour se réapproprier Internet", la stratégie de LeBureau.coop est d'être revendeur (BookMyName pour les .xyz) de nom de domaine en attendant de générer suffisamment de revenus pour financer l'obtention d'accréditations directes auprès des différents registres (AFNIC, DotCoop, ICANN...).

Les échanges par e-mail avec Arthur Vuillard ont été à la fois rapide et précis 👌.

D'après la vidéo "Les noms de domaine pour se réapproprier Internet", en juin 2024, LeBureau.coop déclarait avoir 300 clients, 60 sociétaires et 65 000 € de financement.

J'aimerais bien savoir où en est le projet en mars 2025 🤔.

Certaines personnes vont me poser les questions suivantes « Pourquoi tu te compliques la vie avec LeBureau.coop ? Pourquoi ne pas acheter simplement tes domaines directement chez BookMyName ? ».

Ma réponse est la suivante. Depuis quelques années maintenant, je souhaite expérimenter d'autres modèles que le modèle Venture capital, grosses entreprises, etc. En partie à cause du phénomène "De la merdification des choses", comme ce fut, par exemple, le cas avec Gandi.

L'été dernier, j'ai testé social.coop et à présent, c'est au tour de LeBureau.coop.

Cette expérience sera peut-être un échec, mais pour le moment, je n'en sais rien. Je souhaite lui donner sa chance et continuer à explorer d'autres projets de coopératives.

En étudiant Pi-hole, je découvre le terme "DNS sinkhole" :

A DNS sinkhole, also known as a sinkhole server, Internet sinkhole, or Blackhole DNS is a Domain Name System (DNS) server that has been configured to hand out non-routable addresses for a certain set of domain names.

...

Another use is to block ad serving sites, either using a host's file-based sinkhole or by locally running a DNS server (e.g., using a Pi-hole). Local DNS servers effectively block ads for all devices on the network.

source

Suite de ma note 2025-01-15_1350.

Je vais créer un ticket de support Scaleway pour savoir si c'est un bug ou si j'ai mal compris comment cela fonctionne.

source

Voici la réponse que j'ai reçu :

Notre équipe produit est revenue vers nous pour nous indiquer qu’en effet il y a un défaut de documentation.

Ce process alternatif ne fonctionne que sur la racine des domaines pas sur un sous domaine.

C’était pour les tlds qui ne donnent pas de DNS par défaut aux clients.

Suite de la note 2025-01-14_2152 au sujet de Scaleway Domains and DNS.

Dans l'e-mail « External domain name validation » que j'ai reçu, je lis :

Alternative validation process (if your current registrar doesn't offer basic DNS service):

Please set your nameservers at your registrar to:

• 9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns0.dom.scw.cloud
• 9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns1.dom.scw.cloud

J'ai essayé cette méthode alternative pour le sous-domaine scw.stephane-klein.info :

Voici les DNS Records correspondants :

scw.stephane-klein.info.	1	IN	NS	9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns1.dom.scw.cloud.
scw.stephane-klein.info.	1	IN	NS	9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns0.dom.scw.cloud.

J'ai vérifié ma configuration :

$ dig NS scw.stephane-klein.info @ali.ns.cloudflare.com
scw.stephane-klein.info. 300    IN      NS      9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns0.dom.scw.cloud.
scw.stephane-klein.info. 300    IN      NS      9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns1.dom.scw.cloud.

J'ai attendu plus d'une heure et cette méthode de validation n'a toujours pas fonctionné.

Je pense que cela ne fonctionne pas 🤔.

Je vais créer un ticket de support Scaleway pour savoir si c'est un bug ou si j'ai mal compris comment cela fonctionne.

---

2025-01-17 : réponse que j'ai reçu :

Notre équipe produit est revenue vers nous pour nous indiquer qu’en effet il y a un défaut de documentation.

Ce process alternatif ne fonctionne que sur la racine des domaines pas sur un sous domaine.

C’était pour les tlds qui ne donnent pas de DNS par défaut aux clients.

Conclusion : la documentation était imprécise, ce que j'ai essayé de réaliser ne peut pas fonctionner.

J'ai réalisé un test pour vérifier que la délégation DNS par le managed service de Scaleway nommé Domains and DNS (lien direct) fonctionne correctement pour un sous-domaine tel que testscaleway.stephane-klein.info.

Je commence par suivre les instructions du how to : How to add an external domain to Domains and DNS.

Sur la page https://console.scaleway.com/domains/internal/create :

Je sélectionne la dernière entrée « Manage as external ».

Ensuite :

J'ai ajouté le DNS Record suivant à mon serveur DNS géré par cloudflare :

_scaleway-challenge.testscaleway.stephane-klein.info.	1	IN	TXT	"dd7e7931-56d6-4e04-bcd7-e358821e63dd"

Vérification :

$ dig TXT _scaleway-challenge.testscaleway.stephane-klein.info +short
"dd7e7931-56d6-4e04-bcd7-e358821e63dd"

Je n'ai aucune idée de la fréquencede passage du job Scaleway qui effectue la vérification de l'entrée TXT :

J'ai ajouté mon domaine à 22h22 et il a été validé à 22h54 :

Ensuite, j'ai ajouté les DNS Records suivants :

testscaleway.stephane-klein.info.	1	IN	NS	ns1.dom.scw.cloud.
testscaleway.stephane-klein.info.	1	IN	NS	ns0.dom.scw.cloud.

Vérification :

$ dig NS testscaleway.stephane-klein.info +short
ns0.dom.scw.cloud.
ns1.dom.scw.cloud.

Ensuite, j'ai configuré dans la console Scaleway, le DNS Record :

test1   3600 IN A  8.8.8.8

Vérification :

$ dig test1.testscaleway.stephane-klein.info +short
8.8.8.8

Conclusion : la réponse est oui, le managed service Scaleway Domains and DNS permet la délégation de sous-domaines 🙂.

Comme mentionné dans la note 2024-12-28_1621, j'ai implémenté un playground nommé powerdns-playground.
J'ai fait le triste constat de découvrir encore un projet (PowerDNS-Admin) qui ne supporte pas une "automated and unattended installation" 🫤.

PowerDNS-Admin ne permet pas de créer automatiquement un utilisateur admin.

Pour contourner cette limitation, j'ai implémenté un script configure_powerdns_admin.py qui permet de créer un utilisateur basé sur les variables d'environnement POWERDNS_ADMIN_USERNAME, POWERDNS_ADMIN_PASSWORD, POWERDNS_ADMIN_EMAIL.

Le script ./scripts/setup-powerdns-admin.sh se charge de copier le script Python dans le container powerdns-admin et de l'exécuter.

J'ai partagé ce script sur :

• le SubReddit self hosted : https://old.reddit.com/r/selfhosted/comments/1hocrjm/powerdnsadmin_a_python_script_for_automating_the/?
• et le Discord de PowerDNS-Admin : https://discord.com/channels/1088963190693576784/1088963191574376601/1322661412882874418

Je viens de tomber dans un Yak! 🙂.

Je cherchais des alternatives Open source à ngrok et j'ai trouvé sish (https://docs.ssi.sh/).

Côté client, sish utilise exclusivement ssh pour exposer des services (lien la documentation).

Voici comment exposer sur l'URL http://hereiam.tuns.sh le service HTTP exposé localement sur le port 8080 :

$ ssh -R hereiam:80:localhost:8080 tuns.sh

Je trouve cela très astucieux 👍️.

Après cela, j'ai commencé à étudier comment déployer sish et j'ai lu cette partie :

This includes taking care of SSL via Let's Encrypt for you. This uses the adferrand/dnsrobocert container to handle issuing wildcard certifications over DNS.

source

Après cela, j'ai étudié dnsrobocert qui permet de générer des certificats SSL Let's Encrypt avec la méthode DNS challenges, mais pour cela, il a besoin d'insérer et de modifier des DNS Record sur un serveur DNS.

Je n'ai pas envie de donner accès à l'intégralité de mes zones DNS à un script.
Pour éviter cela, j'ai dans un premier temps envisagé d'utiliser un serveur DNS managé de Scaleway, mais j'ai constaté que le provider Scaleway n'est pas supporté par Lexicon (qui est utilisé par dnsrobocert).

Après cela, j'ai décidé d'utiliser PowerDNS et je viens de publier ce playground : powerdns-playground.

#JaiDécouvert DomainMOD :

DomainMOD is a self-hosted open source application used to manage your domains and other Internet assets in a central location.

#JaiLu le Thread Reddit : What dns do you use on your home router?.

J'y ai découvert Quad9.

En explorant la console de Scaleway, je viens de tomber sur la fonctionnalité suivante :

Scaleway Domains and DNS provides advanced features for traffic management using your DNS zone. It allows you to redirect users based on their geolocation, the load on your different servers, and more.

Je viens de réaliser que cela répond à une question que je me posais souvent entre 2000 et 2010 : comment les sites à portée mondiale parviennent-ils à répartir le trafic entre différents datacenters avec une URL unique, comme google.com ?

À l’époque, j’imaginais que ces acteurs utilisaient principalement le Round-robin DNS ou des algorithmes de répartition de charge avec HAProxy. mais je n'avais pas pensé à la possibilité que le serveur DNS puisse donner une réponse différente en fonction de l'IP de la personne qui fait la requête.
De plus, cette réponse peut dépendre de la localisation de l'IP (GeoIP).

Par exemple, depuis 2014, le serveur DNS Bind propose nativement la fonctionnalité "GeoIP Features".

J'ai lu aussi que les gros acteurs utilisent la méthode Anycast, mais cette méthode nécessite de gérer son propre Autonomous System.

Nouvelle #iteration du Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS.

Il y a quelques jours, j'ai migré de vagrant-hostmanger vers vagrant-dns. J'ai ensuite souhaité mettre en œuvre Grizzly, mais j'ai rencontré un problème.

J'ai installé une version binaire statiquement liée de Grizzly à l'aide de Mise. Dans cette version, Go ne fait pas appel à la fonction getaddrinfo pour la résolution des noms d'hôte. Au lieu de cela, Go se limite à lire les informations de configuration DNS dans /etc/resolv.conf (champ nameserver) et les entrées de /etc/hosts.

Cela signifie que les serveurs DNS gérés par systemd-resolved ne sont pas pris en compte 😭.

Pour régler ce problème, j'utilise en même temps vagrant-dns et Vagrant Host Manager : voici le commit.

J'active uniquement ici le paramètre config.hostmanager.manage_host = true et je laisse vagrant-dns résoudre les hostnames à l'intérieur des machines virtuelles et des containers Docker.

Nouvelle #iteration de Projet 14.

Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.

-- from

Résultat : j'ai migré de Vagrant Host Manager vers vagrant-dns avec succès 🙂.

Voici le commit : lien vers le commit.

Voici quelques explications de la configuration Vagrantfile.

Les lignes suivantes permettent d'utiliser la seconde IP des machines virtuelles pour identifier les identifier (renseignés par le serveur DNS).

  config.dns.ip = -> (vm, opts) do
    ip = nil
    vm.communicate.execute("hostname -I | cut -d ' ' -f 2") do |type, data|
      ip = data.strip if type == :stdout
    end
    ip
  end

La commande hostname retourne les deux IP de la machine virtuelle :

vagrant@server1:~$ hostname -I
10.0.2.15 192.168.56.22

La commande hostname -I | cut -d ' ' -f 2 capture la seconde IP, ici 192.168.56.22.

La configuration DNS qui retourne cette IP est consultable via :

$ vagrant dns -l
/server1.vagrant.test/ => 192.168.56.22
/server2.vagrant.test/ => 192.168.56.23
/grafana.vagrant.test/ => 192.168.56.23
/loki.vagrant.test/ => 192.168.56.23

Autre subtilité :

vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]

Cette ligne configure la machine virtuelle pour qu'elle utilise le serveur DNS de vagrant-dns.
Cela permet de résoudre les noms des autres machines virtuelles. Exemple :

vagrant@server1:~$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23            -- link: eth0

-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

---

En mettant en place vagrant-dns sur ma workstation qui tourne sous Fedora, j'ai rencontré la difficulté suivante.

J'avais la configuration suivante installée :

$ cat /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd

Elle me permet de résoudre les hostnames des machines qui appartiennent à un réseau privé exposé via OpenVPN (voir cette note).

Voici ma configuration complète de systemd-resolved :

$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf

...

[Resolve]
...

# /etc/systemd/resolved.conf.d/1-vagrant-dns.conf
# This file is generated by vagrant-dns
[Resolve]
DNS=127.0.0.1:5300
Domains=~test

# /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd

Quand je lançais resolvectl query server2.vagrant.test pour la première fois après redémarrage de sudo systemctl restart systemd-resolved, tout fonctionnait correctement :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Mais, la seconde fois, j'avais l'erreur suivante :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: Name 'server2.vagrant.test' not found

Ce problème disparait si je supprime /etc/systemd/resolved.conf.d/csd.conf.

Je n'ai pas compris pourquoi. D'après la section "Protocols and routing" de systemd-resolved, le serveur 10.57.40.1 est utilisé seulement pour les hostnames qui se terminent par .csd.

J'ai activé les logs de systemd-resolved au niveau debug avec

$ sudo resolvectl log-level debug
$ journalctl -u systemd-resolved -f

Voici le contenu des logs lors de la première exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/506a9fc7d740dc4892e88bfc590bee98.

Voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/956befc280ef9738bfe48cdf7f5ef930.

J'ai l'impression que la ligne 13 indique que le cache de systemd-resolved a été utilisé et qu'il n'a pas trouvé de réponse pour server2.vagrant.test. Pourquoi ? Je ne sais pas.

Ligne 13 : NXDOMAIN cache hit for server2.vagrant.test IN A

Ensuite, je supprime /etc/systemd/resolved.conf.d/csd.conf :

$ sudo rm /etc/systemd/resolved.conf.d/csd.conf

Je relance systemd-resolved et voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/9f87050524048ecf9766f9c97b789123#file-systemd-resolved-log-L11

Je constate que cette fois, la ligne 11 contient : Cache miss for server2.vagrant.test IN A.

Pourquoi avec .csd le cache retourne NXDOMAIN et sans .csd, le cache retourne Cache miss et systemd-resolved continue son algorithme de résosultion du hostname ?

Je soupçonne systemd-resolved de stocker en cache la résolution de server2.vagrant.test par le serveur DNS 10.57.40.1. Si c'est le cas, je me demande pourquoi il fait cela alors qu'il est configuré pour les hostnames qui se terminent par .csd 🤔.

---

Autre problème rencontré, la latence de réponse :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

La réponse est retournée en 7 secondes, ce qui ne me semble pas normal.

J'ai découvert que je n'ai plus aucune latence si je passe le paramètre DNSStubListener à no :

$ sudo cat <<EOF > /etc/systemd/resolved.conf.d/0-vagrant-dns.conf
[Resolve]
DNSStubListener=no
EOF
$ sudo systemctl restart systemd-resolved
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 2.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Le temps de réponse passe de 7.5s à 2.9ms. Je n'ai pas compris la signification de ma modification.

---

Je récapitule, pour faire fonctionner correctement vagrant-dns sur ma workstation Fedora j'ai dû :

• supprimer /etc/systemd/resolved.conf.d/csd.conf
• et paramétrer DNSStubListener à no

Dans le cadre du Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS, j'utilise Vagrant avec le plugin Vagrant Host Manager pour gérer les hostnames des machines virtuelles.

Vagrant Host Manager met correctement à jour les fichiers /etc/hosts sur ma machine hôte, c'est-à-dire, ma workstation, et dans les machines virtuels.
Cependant, ces noms d'hôtes ne sont pas accessibles à l'intérieur des containers Docker.
Par exemple, ici, http://grafana.example.com:3100/ n'est pas accessible à l'intérieur du container Promtail.

Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.

vagrant-dns semble exposer un serveur DNS qui sera accessible et utilisé par les containers Docker.

D'autre part, vagrant-dns (page contributors) semble un peu plus actif que Vagrant Host Manager (page contributors).

Dans ce thread Fediverse #JaiDécouvert LeBureau.coop.

Une société coopérative de gestion de noms de domaine (registrar).

La vidéo "Les noms de domaine pour se réapproprier Internet" de Arthur Vuillard à Pas Sage en Seine (à partir de 25min) contient une présentation de ce projet.

J'y ai au passage découvert la coopérative Hasshbang.

Dans ma #todo-list :

• [ ] Transférer un de mes noms de domaine vers LeBureau.coop pour tester ;
• [ ] Acheter des parts pour devenir sociétaire soutien.

Cela fait 25 ans que je travaille dans le domaine du web, et je viens seulement de prendre conscience de la différence entre un Domain name registrar et un Domain name registry 🙈.
Jusqu'à présent, j'avais tendance à les considérer comme synonymes.

Par exemple, des entreprises comme Gandi ou BookMyName sont exclusivement des Domain name registrar. Elles ne jouent pas le rôle de Domain name registry.

En revanche, certaines entreprises cumulent les deux fonctions, à savoir être à la fois registrar et registry.
C'est le cas de https://www.identity.digital/, qui est à la fois un registrar et registry pour des gTLDs comme le .systems.
Un autre exemple est Team Internet, qui non seulement opère en tant que registry pour le domaine ".xyz", mais agit également en tant que registrar.

#JaiDécouvert l'existence du gTLDs .systems, qui est disponible depuis 2014.

Son Domain name registry est https://www.identity.digital/.

Article Wikipedia : https://fr.wikipedia.org/wiki/GeoIP

Article Wikipedia : https://fr.wikipedia.org/wiki/Fully_qualified_domain_name

https://domainmod.org/

DomainMOD is a self hosted open-source application used to manage your domain name and other Internet assets in a central location.

Article Wikipedia : https://en.wikipedia.org/wiki/DNS_sinkhole

Commandes valables sous Fedora mais aussi plus généralement sous Linux.

Affiche la configuration DNS actuelle :

$ resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 127.0.0.1:5300
       DNS Servers: 127.0.0.1:5300
        DNS Domain: ~test

Link 2 (wlp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.31.1
       DNS Servers: 192.168.31.1

Intéroge directement un serveur DNS :

$ dig @127.0.0.1 -p 5300 server2.vagrant.test +short
192.168.56.21

Résolution d'un hostname avec resolvectl :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 4.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

La commande suivante affiche toutes la configuration de resolved.conf :

$ systemd-analyze cat-config systemd/resolved.conf

Article wikipedia : https://en.wikipedia.org/wiki/Round-robin_DNS

Article Wikipedia : https://en.wikipedia.org/wiki/Pi-hole

https://lebureau.coop/

https://nip.io/