[Dnsmasq-discuss] Extend server to accept hostnames for upstream resolver

Geert Stappers stappers at stappers.nl
Fri Apr 8 06:41:43 UTC 2022


On Thu, Apr 07, 2022 at 05:27:31PM +0200, Geert Stappers via Dnsmasq-discuss wrote:
> 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. )

Found https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q4/014440.html
then deciced to gonna make a fresh patch.

 
> 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



More information about the Dnsmasq-discuss mailing list