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

[Simon Kelley]

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.

Two comments about the patch.

1) Geert's point is a good one: This patch uses only libc: it doesn't 
add any build dependencies and it's small. There's no reason to make it 
a compile-time option.

2) Not handling multiple addresses from getaddrinfo() feels like a 
mistake. What should happen in that case is obvious and the obvious 
behaviour is useful. If it's not done now, we'll end up doing it later 
when someone falls foul of this short-cut. the implementation is more 
complex, but I think returning the struct addrinfo * linked list from 
getaddrinfo instead of a single address should work: the caller of 
parse_server becomes responsible for freeing the struct addrinfos

3) One error that needs to be handled is if a source address is 
specified, and the address family of the source address doesn't match 
the address family of an address returned  from getaddrinfo. My initial 
thought was to make this a fatal error, but that has the problem that

server=dns.example.com at 192.168.7.1

will work fine until an AAAA record is added for dns.example.com, when 
dnsmasq would no longer start. Better I thing to only use DNS records 
that match the source address type if it's specified.


Cheers,

Simon.





On 02/04/2022 20:40, Dominik Derigs wrote:
> Dear Simon,
> 
> In docker swarm and compose configurations, other containers are
> only reachable via hostnames. It is not always possible to assign
> IP addresses beforehand. Hence, the upstream server IP is not
> known at dnsmasq start when the upstream is part of the deployed
> configuration, e.g., a local cloudflared or unbound container.
> 
> So far, getting dnsmasq to run in such a case requires hacks that
> somehow try to determine the IP address before starting dnsmasq.
> An example for such a hack (not invented by me):
> https://github.com/tschaffter/docker-dnsmasq/blob/54b5d5d551746b6f1708fbf4a705e2de66c2eaee/docker-entrypoint.sh#L14-L23
> 
> This patch implements name resolution functionality for
> server=... by querying the system resolver for a hostname. It is
> only used when a user supplied something that is not a valid IP
> address (dnsmasq currently fails hard in this case so this isn't
> a breaking change) and can be omitted by a compile time flag (I
> think it's worthwhile to have it).
> 
> I know my proposal does sound somewhat strange (resolving a DNS
> server name) but this is something that is somewhat frequently
> needed and currently only possible through external hacks.