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
[email protected]
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.
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
