I took a look at the awesome self-hosted repo and found DailyTxt. I have no experience with it but maybe worth a try?

I had a quick look at resolv.conf’s manpage on Debian and I think @daddy32@lemmy.world’s suggestion of adding a second nameserver would actually work:

nameserver Name server IP address
    Internet  address  of a name server that the resolver should query, either an IPv4 address (in dot notation), or an IPv6 address in colon (and possibly dot) notation as per RFC 2373.  Up to MAXNS (currently 3, see <re‐
    solv.h>) name servers may be listed, one per keyword.  If there are multiple servers, the resolver library queries them in the order listed.  If no nameserver entries are present, the default is to use the name  server
    on  the  local  machine.   (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are
    made.)

According to the doc, the resolver will try each name server in order until one is successful.

Sorry, I was unclear: I use dnsmasq as single source of truth. In its DHCP config, I set machine names, routes and all. And this is because this dnsmasq is the DHCP that it knows how to translate the names of the devices it configured. Pi-hole forwards all DNS requests to dnsmasq. Now if I use two instances of dnsmasq, only one can be a DHCP and the other won’t know how to resolve local names, unless it uses the first dnsmasq as upstream. But in scenarios where this first dnsmasq instance is down, we are back to square one.

My goodness, that’s some impressive responsiveness ^^

I guess see your point. But then the problem shifts to the upstream dnsmasq instance which acts as DHCP + DNS for the local devices. This is the server ultimately able to translate local names.

I don’t think it’s doable to have two instances of dnsmasq that are able to translate local names interchangeably. That would require two DHCPs to have authority on the network. But I’m no expert so I may be missing something obvious.

For some reason, I am only seeing this comment thread now, so sorry for the late response.

Thanks for those valuable details. But I am still a bit confused. I understand why you are saying that pi hole should be the only DNS server handling requests sent by LAN devices (including the machine hosting the DNS). That’s because it is the only one which can resolve local names (well, that’s actually its upstream dnsmasq running as a sibling container that does that but that’s a minor detail).

But then you say there should be another DNS server to solve my problem. If I put two server entries in /etc/resolv.conf, one being pi hole and the other my ISP’s DNS, the two of them will be randomly picked by DNS clients. When the ISP’s is used, it will fail to translate local names. I guess there is a way to let the client try the other server after a failure but it will add some undesirable latency.

Sorry if I misunderstood your point but after reading the first comments I was quite convinced by the idea of adding a second nameserver entry in /etc/resolv.conf. Your explanations convinced me otherwise and now I have the impression that I can’t really solve my initial problem in a reliable way.

Well, I have not really thought about why. I guess that’s partly due to old habits of running services on the host with systemd (my migration to docker is recent and still a work in progress). But I guess I’d like to continue to be able to resolve names of local devices on my network when connected through ssh on the host. Is that inherently wrong, still? I will implement the secondary DNS as a fallback. I am hoping to get rid of the issue that way.

Yes, others have suggested something similar. I’ll do that first because it is easy. Monitoring-wise, I should already be covered but since prometheus is running on the same server, it was down during the outage. There is room for improvement, for sure! I have a couple of RPis on my network that I can leverage for better monitoring.

Your suggestion looks similar to this other comment and makes sense. I’ll try that!

I have never managed to wrap my head around DoH and DoT but this is on my todo list ^^

I didn’t know dnsmasq has an adblock plugin, I’ll have a look. Originally, I was using dnsmasq alone (running on bare metal). Then I migrated to docker and added pi-hole for ad blocking. I tried to get rid of dnsmasq but pi-hole’s embedded DHCP is not as configurable as dnsmasq’s and I could not address my use case.

Thanks a lot for your time!

I see. I kind of thought about it earlier today while mulling over the problem. I can definitely do that first because it’s easy and makes total sense.

I already have prometheus monitoring the DNS resolution, I think. I’ll check!

Thanks for taking the time to answer!

Yeah, that was my plan B. To be honest, I was not super confident that it would work when I put this setup together, because of the “host uses a container as DNS and docker uses the host as DNS” kind of circular dependency.

But people do use docker for DNS servers so it has to work, right? That’s where I’d like to understand where I’m wrong. I’m fine with running pi hole and dnsmasq on the host as long as I get why this is not doable in docker.

Thanks for your input, though. That’s helpful.

In both the pi-hole (exposed on the host) and dnsmasq (used as upstream by pi-hole) containers:

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make
 further changes once it
# has been modified.

nameserver 127.0.0.11
options ndots:0

# Based on host file: '/etc/resolv.conf' (internal res
olver)
# ExtServers: [host(127.0.0.1)]
# Overrides: []
# Option ndots from: internal

So they are pointing to docker’s embedded DNS, itself forwarding to the host.

Je ne connaissais pas Rethink, merci ! En plus elle est sur FDroid, trop bien. Ca ressemble à AdAway en effet. Y avait Blokada dans le temps, aussi.

Euh ben en tout mon téléphone n’est pas rooté donc je ne crois pas. Je suis sur Lineage avec mindthegapps. Au pire ça s’essaye et tu sauras vite.

En alternative, il y a AdAway, appli libre dispo sur FDroid qui ne nécessite pas d’accorder sa confiance à un service tiers fermé. Je l’utilise depuis des années et ça marche bien. Mon pi hole ne voit plus grand chose à bloquer depuis mes appareils Android.

C’est aussi ce que je pense. Hélas les commentaires mis en avant en bas de l’article me font douter. J’espère que c’est juste une sélection biaisée.

Les vélomobiles ne sont pas particulièrement nouveaux. Le prix vient à mon avis plutôt du mode de fabrication qui reste très artisanal pour des séries très petites.

Certains modèles ont effectivement une assistance électrique. Je ne suis pas sûr que le DFXL présenté en propose une. Mais la plupart des modèles du marché ont une assistance en option. C’est une question de choix et de région. Les néerlandais aiment bien le vélomobile et chez eux, c’est tout plat ! J’ai mis plus de détails dans ce commentaire si jamais.

L’innovation est déjà entièrement là :) J’ai mis quelques détails dans ce commentaire

Pour ceux que ça intéresse, je crois que le vélomobile présenté est un DFXL de la marque DF https://www.velomobileworld.com/product/df-dfxl/

Le reportage est assez pauvre en informations, alors je vais en rajouter quelques unes, sur la base des recherches que j’ai pu effectuer ces dix dernières années.

Il existe bien d’autres marques et modèles de vélomobiles, certains orienté sport et vitesse (ex : le Quest, d’autres confort ou praticité pour les déplacements quotidiens. Les modèles sont souvent disponibles avec ou sans assistance électrique. Les coques sont le plus souvent en fibre de verre ou en carbone, le premier étant moins cher et plus facile à réparer et le second un peu moins lourd. Certains sont ouverts au niveau de la tête, comme le DFXL sur la vidéo. D’autres ont une casquette rigide, souvent amovible pour une protection parfaite contre les intempéries, comme le Waw.

Certains ont une suspension pour le confort (souvent optionnelle, étant donné le poids et le prix qui vont avec).

Tout est affaire de compromis entre le poids, le prix, la performance, le confort et la facilité de manoeuvre. Le rayon de braquage est notamment un point à considérer, certains comme le Quest ayant (de mémoire) un rayon de 12m ! Cela peut être handicapant en ville.

En ce qui me concerne, mon préféré est le Waw de la marque Katanga en République Tchèque : https://www.katanga.eu/waw/, dont David Massot, un français passionné a fait plusieurs vidéos de présentation comme celle-ci David a aussi réalisé un voyage de 1500 km entre les locaux de Katanga et Avignon, visible ici

En France, il y a un revendeur spécialisé très connu dans le milieu : les cycles JV Fenioux basés à Chasnais en Vendée, autrefois au Mans. Ils organisent des séances d’essai de temps en temps. Et ils sont aussi fabricants de deux modèles plutôt soignés : le Le Mans et le Mulsanne

Le risque est d’avoir une surintensité sur ton périphérique à 1000€, pour économiser sur un câble à 10€.

J’ai pas compris ce que tu voulais dire ici. Un câble ne peut pas causer une surintensité sur l’appareil qu’il alimente. En revanche, un câble de mauvaise qualité aura une impédance trop importante, ce qui causera une chute de tension telle que l’appareil n’aura pas la tension nécessaire et ne démarrera pas ou ne fonctionnera pas bien.

Un câble ne peut que limiter l’intensité du circuit, il ne peut pas l’augmenter. Ce n’est pas un composant actif comme peut l’être un générateur.

J’ai essayé de lire le post de Leung mais il a été supprimé on dirait.