On Thu, Apr 07, 2022 at 12:24:15PM +0100, Simon Kelley wrote: > This seems like a sensible idea, but it does need a clear warning in the > documentation that it will only work if the dnsmasq instance being > configured is not the one providing DNS to the local system.
And the idea did trigger further idea. Manual page has -S, --local, --server=[/[<domain>]/[domain/]][<ipaddr>[#<port>]][@<interface>][@<source-ip>[#<port>]] ( I think the mailing archive has a request for -S, --local, --server=[/[<domain>]/[domain/]]<ipaddr>[#<port>]][@<interface>][@<source-ip>[#<port>] so that <ipaddr> is mandatory. ) Making that -S, --local, --server=[/[<domain>]/[domain/]]<upstreamserver>[#<port>]][@<interface>][@<source-ip>[#<port>] where <upstreamerserver> can be an IP-address or servername. When it is a servername is nameresolving started for servername. Succesfull name resolving allow dnsmasq to do its task, failed name resolving yields a fatal error. The "name resolving" is gethostbyname function or other function that works for the (container) environment that started this request / idea. I imagine that gethostbyname() name resolving also reads /etc/hosts, so more "environment" can benefit from this new feature. Groeten Geert Stappers -- Silence is hard to parse _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
