Cette semaine : une fonctionnalité Freebox attendue depuis 15 ans, un saut technique pour le scale-to-zero Kubernetes, et des outils auto-hébergés qui méritent le détour.
Freebox 4.11.1 : le DNS local enfin disponible#
Si vous utilisez une Freebox en routeur principal, vous connaissez la frustration : vos équipements LAN ont une IP qui change avec le bail DHCP, et pour joindre votre NAS ou votre Raspberry Pi par nom, il fallait ou bien figer des baux statiques, ou bien déployer un Pi-hole/AdGuard Home rien que pour la résolution locale.
C’est corrigé depuis la mise à jour 4.11.1 (20 mai 2026). Free a implémenté le couplage DHCP/DNS réclamé depuis 2011 sur le bug tracker : FS#4079.
Le fonctionnement :
- L’appareil demande un bail DHCP et annonce son hostname (option DHCP 12)
- Le Freebox Server enregistre le couple
hostname ↔ IPdans sa table DNS locale - Les requêtes vers
monnas.homeouraspberrypi.homesont résolues localement. Sinon, relais vers les DNS externes
Le suffixe retenu est .home. Pas .local (réservé mDNS/Bonjour, RFC 6762), ni .home.arpa (RFC 8375) : c’est un choix pragmatique, largement utilisé par ailleurs, même si l’absence de réservation officielle IETF laisse une petite ambiguïté théorique.
Ce qu’il faut savoir :
- Un appareil en IP statique configurée manuellement ne sera pas résolu
- Les équipements derrière un routeur secondaire sont exclus
- Si vos clients pointent directement vers Cloudflare, Quad9 ou NextDNS, le DNS local est court-circuité
Si vous faites tourner AdGuard Home ou Unbound, configurez la Freebox comme upstream DNS : vous gardez votre filtre maison et récupérez la résolution
.home.
Une fonctionnalité qui simplifie vraiment la vie en LAN. Pour ceux qui ont déjà un routeur dédié (OPNsense, OpenWrt), ça ne change rien. Pour les autres, ça retire un motif de déployer un cache DNS rien que pour ça.
zeropod v0.12.0 : le scale-to-zero container tient ses promesses#
Vous connaissez le concept : un shim containerd qui checkpointe les pods au bout d’un délai d’inactivité, les freeze sur disque, et les restaure à la première connexion. L’idée : libérer de la RAM et du CPU sur votre cluster pendant les creux de trafic.
zeropod en est à la v0.12.0, et le retour d’expérience de zwindler est bien plus positif qu’il y a un an.
Le point qui bloquait tout : les probes Kubernetes. En v0.6.x, zeropod était incompatible avec les liveness/readiness probes : le kubelet réveillait constamment le container empêchant tout scale-down. C’est corrigé :
- L’activator eBPF intercepte les probes en état
SCALED_DOWNet répond 200 sans restore - Le socket tracker filtre les connexions du kubelet en phase
RUNNING
Côté perf :
| Métrique | v0.6.x | v0.12.0 |
|---|---|---|
| Checkpoint nginx | ~400ms | ~185ms |
| Restauration nginx | ~92ms | ~99ms |
| CRIU | v3.x | v4.2 |
| Cascade WordPress+MySQL | plantage | ~220ms |
Le test de la cascade WordPress + MySQL (les deux pods checkpointés, réveil en chaîne) fonctionne désormais sur kubeadm, avec une première requête servie en environ 220ms. Sur k3s en revanche, ça reste flaky : le flag probe binary semble mal propagé.
Limitation à retenir : depuis la PR qui a retiré --tcp-established, les connexions TCP sortantes actives (vers la BDD par exemple) sont perdues au checkpoint. L’application doit les rétablir, ce qui est automatique dans le cas d’une requête PHP WordPress, mais pourrait poser problème avec des websockets ou du streaming.
Pour le déploiement perso ou un cluster de préprod, zeropod devient envisageable. En production avec des connexions longues, je reste mesuré, mais l’évolution est nette.
Les pépites de la semaine#
Keeper : Un synchronisateur de calendriers ouvert, support CalDAV, serveur MCP pour les assistants IA, déploiement Docker. Sur le papier, c’est un tool que j’aurais aimé aimer. Dans les faits, vous synchronisez vos calendriers une fois, puis vous n’y touchez plus. Utile si vous galérez avec 3 calendriers Google + un CalDAV Nextcloud, mais c’est un réservoir, pas un client. keeper.sh
Euro-Office : La suite bureautique souveraine européenne sort le 9 juin, intégrée à Nextcloud Hub 26 Spring. Si la souveraineté numérique vous intéresse et que vous cherchez une alternative à OnlyOffice/Collabora avec une conformité RGPD renforcée, ça vaut le coup d’œil.
*Stop Making arrs : stopmakingarrs.org remet en question la galaxie *arr (Radarr, Sonarr, Lidarr…). Maintenance lourde, UI fragmentée, dépendance aux trackers privés. Si votre stack *arr commence à vous prendre plus de temps que le visionnage lui-même, des alternatives plus légères existent.
Open source et contributions AI : Franck Nijhof rappelle que l’IA a simplement accéléré le problème des mainteneurs. Les PR arrivent en masse, la relecture reste le goulet d’étranglement. Rien de neuf, mais une piqûre de rappel utile si vous contribuez ou maintenez.
FUTO, 2 ans après : Immich a publié un bilan de son partenariat avec FUTO. Si vous utilisez Immich comme alternative Google Photos, c’est instructif sur la viabilité des modèles économiques open source.
Commande du jour#
dig raspberrypi.home +shortQuand vous aurez activé le DNS local Freebox, vous voudrez vérifier que ça marche. Pour le diagnostic DNS, un +trace peut aussi aider à voir où la résolution casse si le .home ne répond pas. Si dig n’est pas installé : drill ou host font le job. Les résolveurs locaux comme Unbound ont tendance à ne pas forwarder .home, vérifiez votre forward-zone si vous en utilisez un. Bon déploiement.
