Avoid requiring resolver configuration

[mimi89999]

Issue

The module currently requires a manually configured resolver, which can pose challenges in certain scenarios. For example, if an ISP changes its resolver server addresses, if the local network's resolver address is updated, or if the server is migrated to a different ISP, administrators may forget to update the resolver settings across all configurations. This is especially true for less obvious places like web server configurations.

The default configuration example uses a forwarder on localhost, but this may not always be available or top-of-mind for administrators when setting up the system. This dependency on a fixed resolver address increases the risk of configuration errors and disruptions.

Proposed Solution

It would be more robust and efficient to default to using the system resolver when no explicit resolver configuration is provided. This would ensure that the module adapts to changes in resolver configurations without requiring manual intervention in every affected location, significantly reducing the risk of errors.

Additional Context

No response

[bavshin-f5]

The module code runs as a background task in the nginx worker process. We are not allowed to use the system resolver because gethostbyname interface is blocking¹ and may stall traffic processing for dozens of seconds in a particularly bad scenario.

Footnotes

1. while getaddrinfo_a exists, it is not portable and its reliance on signals makes the API unsuitable for us. ↩

[mimi89999]

There is also systemd-resolved, but that is even less portable: https://systemd.io/WRITING_RESOLVER_CLIENTS/

I was thinking more about using res_ninit(res_state statep) to get the address of the resolver configured in the system. Something like:

struct __res_state res;
res_ninit(&res)
struct sockaddr_in *ns_addr = &res.nsaddr_list[0];

[mimi89999]

Most systems do have a /etc/resolv.conf even if it is externally managed. There could be a resolver auto or resolver system option that would use that file. The only possible issue would be monitoring that file for changes or reading it on every query.

[bavshin-f5]

Most systems do have a /etc/resolv.conf even if it is externally managed. There could be a resolver auto or resolver system option that would use that file.

It would be more appropriate to raise this in the main nginx repo. For the record, as much as I'd like to see this implemented, I don't make decisions on the core nginx development.

IIRC, a similar option was proposed several times in the mailing lists and rejected on the basis of not being able to support resolv.conf completely. Crucial options like ndots or search could not be applied to our resolver configuration.

The only possible issue would be monitoring that file for changes or reading it on every query.

I don't believe that part is possible, it goes against both the architecture of the nginx internal resolver, and the general principles of our configuration. It's also expensive.

I was thinking more about using res_ninit(res_state statep) to get the address of the resolver configured in the system.

The list of platforms we have to consider is long and diverse. res_ninit is unavailable even on some Linux distributions, so we would not want to rely on it.