A C library for asynchronous DNS requests (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

413 lines
14 KiB

.\"
.\" Copyright 1998 by the Massachusetts Institute of Technology.
.\" Copyright (C) 2004-2010 by Daniel Stenberg
.\"
.\" SPDX-License-Identifier: MIT
.\"
.TH ARES_INIT_OPTIONS 3 "5 March 2010"
.SH NAME
ares_init_options, ares_init \- Initialize a resolver channel
.SH SYNOPSIS
.nf
#include <ares.h>
struct ares_server_failover_options {
unsigned short retry_chance;
size_t retry_delay;
};
struct ares_options {
int flags;
int timeout; /* in seconds or milliseconds, depending on options */
int tries;
int ndots;
unsigned short udp_port;
unsigned short tcp_port;
int socket_send_buffer_size;
int socket_receive_buffer_size;
struct in_addr *servers;
int nservers;
char **domains;
int ndomains;
char *lookups;
ares_sock_state_cb sock_state_cb;
void *sock_state_cb_data;
struct apattern *sortlist;
int nsort;
int ednspsz;
char *resolvconf_path;
char *hosts_path;
Configuration option to limit number of UDP queries per ephemeral port (#549) Add a new ARES_OPT_UDP_MAX_QUERIES option with udp_max_queries parameter that can be passed to ares_init_options(). This value defaults to 0 (unlimited) to maintain existing compatibility, any positive number will cause new UDP ephemeral ports to be created once the threshold is reached, we'll call these 'connections' even though its technically wrong for UDP. Implementation Details: * Each server entry in a channel now has a linked-list of connections/ports for udp and tcp. The first connection in the list is the one most likely to be eligible to accept new queries. * Queries are now tracked by connection rather than by server. * Every time a query is detached from a connection, the connection that it was attached to will be checked to see if it needs to be cleaned up. * Insertion, lookup, and searching for connections has been implemented as O(1) complexity so the number of connections will not impact performance. * Remove is_broken from the server, it appears it would be set and immediately unset, so must have been invalidated via a prior patch. A future patch should probably track consecutive server errors and de-prioritize such servers. The code right now will always try servers in the order of configuration, so a bad server in the list will always be tried and may rely on timeout logic to try the next. * Various other cleanups to remove code duplication and for clarification. Fixes Bug: #444 Fix By: Brad House (@bradh352)
1 year ago
int udp_max_queries;
int maxtimeout; /* in milliseconds */
unsigned int qcache_max_ttl; /* in seconds */
ares_evsys_t evsys;
struct ares_server_failover_options server_failover_opts;
};
`ares_channel` -> `ares_channel_t *`: don't bury the pointer (#595) `ares_channel` is defined as `typedef struct ares_channeldata *ares_channel;`. The problem with this, is it embeds the pointer into the typedef, which means an `ares_channel` can never be declared as `const` as if you write `const ares_channel channel`, that expands to `struct ares_channeldata * const ares_channel` and not `const struct ares_channeldata *channel`. We will now typedef `ares_channel_t` as `typedef struct ares_channeldata ares_channel_t;`, so if you write `const ares_channel_t *channel`, it properly expands to `const struct ares_channeldata *channel`. We are maintaining the old typedef for API compatibility with existing integrations, and due to typedef expansion this should not even cause any compiler warnings for existing code. There are no ABI implications with this change. I could be convinced to keep existing public functions as `ares_channel` if a sufficient argument exists, but internally we really need make this change for modern best practices. This change will allow us to internally use `const ares_channel_t *` where appropriate. Whether or not we decide to change any public interfaces to use `const` may require further discussion on if there might be ABI implications (I don't think so, but I'm also not 100% sure what a compiler internally does with `const` when emitting machine code ... I think more likely ABI implications would occur going the opposite direction). FYI, This PR was done via a combination of sed and clang-format, the only manual code change was the addition of the new typedef, and a couple doc fixes :) Fix By: Brad House (@bradh352)
1 year ago
int ares_init_options(ares_channel_t **\fIchannelptr\fP,
const struct ares_options *\fIoptions\fP,
int \fIoptmask\fP);
int ares_init(ares_channel_t **\fIchannelptr\fP);
.fi
.SH DESCRIPTION
The \fBares_init(3)\fP function is equivalent to calling
\fBares_init_options(channelptr, NULL, 0)\fP. It is recommended to use
\fBares_init_options(3)\fP instead and to set or make configurable the
appropriate options for your application.
The \fBares_init_options(3)\fP function initializes a communications channel
for name service lookups. If it returns successfully,
\fBares_init_options(3)\fP will set the variable pointed to by
\fIchannelptr\fP to a handle used to identify the name service channel. The
caller should invoke \fIares_destroy(3)\fP on the handle when the channel is
no longer needed.
It is recommended for an application to have at most one ares channel and use
this for all DNS queries for the life of the application. When system
configuration changes, \fIares_reinit(3)\fP can be called to reload the
configuration if necessary. The recommended concurrent query limit is about
32k queries, but remembering that when specifying AF_UNSPEC for
\fBares_getaddrinfo(3)\fP or \fBares_gethostbyname(3)\fP, they may spawn
2 queries internally. The reason for the limit is c-ares does not allow
duplicate DNS query ids (which have a maximum of 64k) to be oustanding at a
given time, and it must randomly search for an available id thus 32k will limit
the number of searches. This limitation should not be a concern for most
implementations and c-ares may implement queuing in future releases to lift this
limitation.
The \fIoptmask\fP parameter generally specifies which fields in the structure pointed to
by \fIoptions\fP are set, as follows:
.TP 18
.B ARES_OPT_FLAGS
.B int \fIflags\fP;
.br
Flags controlling the behavior of the resolver:
.RS 4
.TP 23
.B ARES_FLAG_USEVC
Always use TCP queries (the "virtual circuit") instead of UDP
queries. Normally, TCP is only used if a UDP query yields a truncated
result.
.TP 23
.B ARES_FLAG_PRIMARY
Only query the first server in the list of servers to query.
.TP 23
.B ARES_FLAG_IGNTC
If a truncated response to a UDP query is received, do not fall back
to TCP; simply continue on with the truncated response.
.TP 23
.B ARES_FLAG_NORECURSE
Do not set the "recursion desired" bit on outgoing queries, so that the name
server being contacted will not try to fetch the answer from other servers if
it doesn't know the answer locally. Be aware that ares will not do the
recursion for you. Recursion must be handled by the application calling ares
if \fIARES_FLAG_NORECURSE\fP is set.
.TP 23
.B ARES_FLAG_STAYOPEN
Do not close communications sockets when the number of active queries
drops to zero.
.TP 23
.B ARES_FLAG_NOSEARCH
Do not use the default search domains; only query hostnames as-is or
as aliases.
.TP 23
.B ARES_FLAG_NOALIASES
Do not honor the HOSTALIASES environment variable, which normally
specifies a file of hostname translations.
.TP 23
.B ARES_FLAG_NOCHECKRESP
Do not discard responses with the SERVFAIL, NOTIMP, or REFUSED
response code or responses whose questions don't match the questions
in the request. Primarily useful for writing clients which might be
used to test or debug name servers.
.TP 23
.B ARES_FLAG_EDNS
Include an EDNS pseudo-resource record (RFC 2671) in generated requests. As of
v1.22, this is on by default if flags are otherwise not set.
Add flag to not use a default local named server on channel initialization (#713) Hello, I work on an application for Microsoft which uses c-ares to perform DNS lookups. We have made some minor changes to the library over time, and would like to contribute these back to the project in case they are useful more widely. This PR adds a new channel init flag, described below. Please let me know if I can include any more information to make this PR better/easier for you to review. Thanks! **Summary** When initializing a channel with `ares_init_options()`, if there are no nameservers available (because `ARES_OPT_SERVERS` is not used and `/etc/resolv.conf` is either empty or not available) then a default local named server will be added to the channel. However in some applications a local named server will never be available. In this case, all subsequent queries on the channel will fail. If we know this ahead of time, then it may be preferred to fail channel initialization directly rather than wait for the queries to fail. This gives better visibility, since we know that the failure is due to missing servers rather than something going wrong with the queries. This PR adds a new flag `ARES_FLAG_NO_DFLT_SVR`, to indicate that a default local named server should not be added to a channel in this scenario. Instead, a new error `ARES_EINITNOSERVER` is returned and initialization fails. **Testing** I have added 2 new FV tests: - `ContainerNoDfltSvrEmptyInit` to test that initialization fails when no nameservers are available and the flag is set. - `ContainerNoDfltSvrFullInit` to test that initialization still succeeds when the flag is set but other nameservers are available. Existing FVs are all passing. **Documentation** I have had a go at manually updating the docs to describe the new flag/error, but couldn't see any contributing guidance about testing this. Please let me know if you'd like anything more here. --------- Fix By: Oliver Welsh (@oliverwelsh)
9 months ago
.TP 23
.B ARES_FLAG_NO_DFLT_SVR
Do not attempt to add a default local named server if there are no other
servers available. Instead, fail initialization with \fIARES_ENOSERVER\fP.
DNS 0x20 implementation (#800) This PR enables DNS 0x20 as per https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00 . DNS 0x20 adds additional entropy to the request by randomly altering the case of the DNS question to help prevent cache poisoning attacks. Google DNS has implemented this support as of 2023, even though this is a proposed and expired standard from 2008: https://groups.google.com/g/public-dns-discuss/c/KxIDPOydA5M There have been documented cases of name server and caching server non-conformance, though it is expected to become more rare, especially since Google has started using this. This can be enabled via the `ARES_FLAG_DNS0x20` flag, which is currently disabled by default. The test cases do however enable this flag to validate this feature. Implementors using this flag will notice that responses will retain the mixed case, but since DNS names are case-insensitive, any proper implementation should not be impacted. There is currently no fallback mechanism implemented as it isn't immediately clear how this may affect a stub resolver like c-ares where we aren't querying the authoritative name server, but instead an intermediate recursive resolver where some domains may return invalid results while others return valid results, all while querying the same nameserver. Likely using DNS cookies as suggested by #620 is a better mechanism to fight cache poisoning attacks for stub resolvers. TCP queries do not use this feature even if the `ARES_FLAG_DNS0x20` flag is specified since they are not subject to cache poisoning attacks. Fixes Issue: #795 Fix By: Brad House (@bradh352)
5 months ago
.TP 23
.B ARES_FLAG_DNS0x20
Enable support for DNS 0x20 as per https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00
which adds additional entropy to the request by randomizing the case of the
query name. Integrators need to ensure they treat DNS name responses as
case-insensitive. In rare circumstances this may cause the inability to lookup
certain domains if the upstream server or the authoritative server for the
domain is non-compliant.
.RE
.TP 18
.B ARES_OPT_TIMEOUT
.B int \fItimeout\fP;
.br
The number of seconds each name server is given to respond to a query on the
Automatic query timeout adjustment based on server history (#794) With very little effort we should be able to determine fairly proper timeouts we can use based on prior query history. We track in order to be able to auto-scale when network conditions change (e.g. maybe there is a provider failover and timings change due to that). Apple appears to do this within their system resolver in MacOS. Obviously we should have a minimum, maximum, and initial value to make sure the algorithm doesn't somehow go off the rails. Values: - Minimum Timeout: 250ms (approximate RTT half-way around the globe) - Maximum Timeout: 5000ms (Recommended timeout in RFC 1123), can be reduced by ARES_OPT_MAXTIMEOUTMS, but otherwise the bound specified by the option caps the retry timeout. - Initial Timeout: User-specified via configuration or ARES_OPT_TIMEOUTMS - Average latency multiplier: 5x (a local DNS server returning a cached value will be quicker than if it needs to recurse so we need to account for this) - Minimum Count for Average: 3. This is the minimum number of queries we need to form an average for the bucket. Per-server buckets for tracking latency over time (these are ephemeral meaning they don't persist once a channel is destroyed). We record both the current timespan for the bucket and the immediate preceding timespan in case of roll-overs we can still maintain recent metrics for calculations: - 1 minute - 15 minutes - 1 hr - 1 day - since inception Each bucket contains: - timestamp (divided by interval) - minimum latency - maximum latency - total time - count NOTE: average latency is (total time / count), we will calculate this dynamically when needed Basic algorithm for calculating timeout to use would be: - Scan from most recent bucket to least recent - Check timestamp of bucket, if doesn't match current time, continue to next bucket - Check count of bucket, if its not at least the "Minimum Count for Average", check the previous bucket, otherwise continue to next bucket - If we reached the end with no bucket match, use "Initial Timeout" - If bucket is selected, take ("total time" / count) as Average latency, multiply by "Average Latency Multiplier", bound by "Minimum Timeout" and "Maximum Timeout" NOTE: The timeout calculated may not be the timeout used. If we are retrying the query on the same server another time, then it will use a larger value On each query reply where the response is legitimate (proper response or NXDOMAIN) and not something like a server error: - Cycle through each bucket in order - Check timestamp of bucket against current timestamp, if out of date overwrite previous entry with values, clear current values - Compare current minimum and maximum recorded latency against query time and adjust if necessary - Increment "count" by 1 and "total time" by the query time Other Notes: - This is always-on, the only user-configurable value is the initial timeout which will simply re-uses the current option. - Minimum and Maximum latencies for a bucket are currently unused but are there in case we find a need for them in the future. Fixes Issue: #736 Fix By: Brad House (@bradh352)
5 months ago
first try. See \fIARES_OPT_TIMEOUTMS\fP which this value is converted into.
.TP 18
.B ARES_OPT_TIMEOUTMS
.B int \fItimeout\fP;
.br
The number of milliseconds each name server is given to respond to a query on
Automatic query timeout adjustment based on server history (#794) With very little effort we should be able to determine fairly proper timeouts we can use based on prior query history. We track in order to be able to auto-scale when network conditions change (e.g. maybe there is a provider failover and timings change due to that). Apple appears to do this within their system resolver in MacOS. Obviously we should have a minimum, maximum, and initial value to make sure the algorithm doesn't somehow go off the rails. Values: - Minimum Timeout: 250ms (approximate RTT half-way around the globe) - Maximum Timeout: 5000ms (Recommended timeout in RFC 1123), can be reduced by ARES_OPT_MAXTIMEOUTMS, but otherwise the bound specified by the option caps the retry timeout. - Initial Timeout: User-specified via configuration or ARES_OPT_TIMEOUTMS - Average latency multiplier: 5x (a local DNS server returning a cached value will be quicker than if it needs to recurse so we need to account for this) - Minimum Count for Average: 3. This is the minimum number of queries we need to form an average for the bucket. Per-server buckets for tracking latency over time (these are ephemeral meaning they don't persist once a channel is destroyed). We record both the current timespan for the bucket and the immediate preceding timespan in case of roll-overs we can still maintain recent metrics for calculations: - 1 minute - 15 minutes - 1 hr - 1 day - since inception Each bucket contains: - timestamp (divided by interval) - minimum latency - maximum latency - total time - count NOTE: average latency is (total time / count), we will calculate this dynamically when needed Basic algorithm for calculating timeout to use would be: - Scan from most recent bucket to least recent - Check timestamp of bucket, if doesn't match current time, continue to next bucket - Check count of bucket, if its not at least the "Minimum Count for Average", check the previous bucket, otherwise continue to next bucket - If we reached the end with no bucket match, use "Initial Timeout" - If bucket is selected, take ("total time" / count) as Average latency, multiply by "Average Latency Multiplier", bound by "Minimum Timeout" and "Maximum Timeout" NOTE: The timeout calculated may not be the timeout used. If we are retrying the query on the same server another time, then it will use a larger value On each query reply where the response is legitimate (proper response or NXDOMAIN) and not something like a server error: - Cycle through each bucket in order - Check timestamp of bucket against current timestamp, if out of date overwrite previous entry with values, clear current values - Compare current minimum and maximum recorded latency against query time and adjust if necessary - Increment "count" by 1 and "total time" by the query time Other Notes: - This is always-on, the only user-configurable value is the initial timeout which will simply re-uses the current option. - Minimum and Maximum latencies for a bucket are currently unused but are there in case we find a need for them in the future. Fixes Issue: #736 Fix By: Brad House (@bradh352)
5 months ago
the first try of any given server. The default is two seconds, however any
value below 250ms will automatically be set to 250ms (roughly the RTT half-way
around the world). Note that this option is specified with the same struct field
as the former \fIARES_OPT_TIMEOUT\fP, it is but the option bits that tell c-ares
how to interpret the number. This option was added in c-ares 1.5.2.
As of c-ares 1.32.0, this option is only honored on the first successful query
to any given server, after that the timeout is automatically calculated based
on prior query history.
.TP 18
.B ARES_OPT_TRIES
.B int \fItries\fP;
.br
The number of tries the resolver will try contacting each name server
before giving up. The default is three tries.
.TP 18
.B ARES_OPT_NDOTS
.B int \fIndots\fP;
.br
The number of dots which must be present in a domain name for it to be
queried for "as is" prior to querying for it with the default domain
extensions appended. The default value is 1 unless set otherwise by
resolv.conf or the RES_OPTIONS environment variable. Valid range is 0-15.
.TP 18
.B ARES_OPT_MAXTIMEOUTMS
.B int \fImaxtimeout\fP;
.br
The upper bound for timeout between sequential retry attempts. When retrying
queries, the timeout is increased from the requested timeout parameter, this
caps the value.
.TP 18
.B ARES_OPT_UDP_PORT
.B unsigned short \fIudp_port\fP;
.br
The port to use for queries over UDP, in host byte order.
The default value is 53, the standard name service port.
.TP 18
.B ARES_OPT_TCP_PORT
.B unsigned short \fItcp_port\fP;
.br
The port to use for queries over TCP, in host byte order.
The default value is 53, the standard name service port.
.TP 18
.B ARES_OPT_SERVERS
.B struct in_addr *\fIservers\fP;
.br
.B int \fInservers\fP;
.br
The list of IPv4 servers to contact, instead of the servers specified in
resolv.conf or the local named. In order to allow specification of either IPv4
or IPv6 name servers, the \Bares_set_servers(3)\fP function must be used
instead.
.TP 18
.B ARES_OPT_DOMAINS
.B char **\fIdomains\fP;
.br
.B int \fIndomains\fP;
.br
The domains to search, instead of the domains specified in resolv.conf
or the domain derived from the kernel hostname variable.
.TP 18
.B ARES_OPT_LOOKUPS
.B char *\fIlookups\fP;
.br
The lookups to perform for host queries.
.I lookups
should be set to a string of the characters "b" or "f", where "b"
indicates a DNS lookup and "f" indicates a lookup in the hosts file.
.TP 18
.B ARES_OPT_SOCK_STATE_CB
.B void (*\fIsock_state_cb\fP)(void *data, ares_socket_t socket_fd, int readable, int writable);
.br
.B void *\fIsock_state_cb_data\fP;
.br
A callback function to be invoked when a socket changes state.
.I socket_fd
will be passed the socket whose state has changed;
.I readable
will be set to true if the socket should listen for read events, and
.I writable
will be set to true if the socket should listen for write events.
The value of
.I sock_state_cb_data
will be passed as the
.I data
argument. The channel lock is held during this callback, if in a multithreaded
application, care must be taken to ensure lock order is correct to be able to
handle this and avoid deadlocks.
Cannot be used with \fBARES_OPT_EVENT_THREAD\fP.
.TP 18
.B ARES_OPT_SORTLIST
.B struct apattern *\fIsortlist\fP;
.br
.B int \fInsort\fP;
.br
A list of IP address ranges that specifies the order of preference that
results from \fIares_gethostbyname\fP should be returned in. Note that
this can only be used with a sortlist retrieved via
\fBares_save_options(3)\fP (because
.B struct apattern
is opaque); to set a fresh sort list, use \fBares_set_sortlist(3)\fP.
.TP 18
.B ARES_OPT_SOCK_SNDBUF
.B int \fIsocket_send_buffer_size\fP;
.br
The send buffer size to set for the socket.
.TP 18
.B ARES_OPT_SOCK_RCVBUF
.B int \fIsocket_receive_buffer_size\fP;
.br
The receive buffer size to set for the socket.
.TP 18
.B ARES_OPT_EDNSPSZ
.B int \fIednspsz\fP;
.br
The message size to be advertised in EDNS; only takes effect if the
.B ARES_FLAG_EDNS
flag is set. Defaults to 1232, the recommended size.
.TP 18
.B ARES_OPT_RESOLVCONF
.B char *\fIresolvconf_path\fP;
.br
The path to use for reading the resolv.conf file. The
.I resolvconf_path
should be set to a path string, and will be honoured on *nix like systems. The
default is
.B /etc/resolv.conf
.br
.TP 18
.B ARES_OPT_HOSTS_FILE
.B char *\fIhosts_path\fP;
.br
The path to use for reading the hosts file. The
.I hosts_path
should be set to a path string, and will be honoured on *nix like systems. The
default is
.B /etc/hosts
.br
Configuration option to limit number of UDP queries per ephemeral port (#549) Add a new ARES_OPT_UDP_MAX_QUERIES option with udp_max_queries parameter that can be passed to ares_init_options(). This value defaults to 0 (unlimited) to maintain existing compatibility, any positive number will cause new UDP ephemeral ports to be created once the threshold is reached, we'll call these 'connections' even though its technically wrong for UDP. Implementation Details: * Each server entry in a channel now has a linked-list of connections/ports for udp and tcp. The first connection in the list is the one most likely to be eligible to accept new queries. * Queries are now tracked by connection rather than by server. * Every time a query is detached from a connection, the connection that it was attached to will be checked to see if it needs to be cleaned up. * Insertion, lookup, and searching for connections has been implemented as O(1) complexity so the number of connections will not impact performance. * Remove is_broken from the server, it appears it would be set and immediately unset, so must have been invalidated via a prior patch. A future patch should probably track consecutive server errors and de-prioritize such servers. The code right now will always try servers in the order of configuration, so a bad server in the list will always be tried and may rely on timeout logic to try the next. * Various other cleanups to remove code duplication and for clarification. Fixes Bug: #444 Fix By: Brad House (@bradh352)
1 year ago
.TP 18
.B ARES_OPT_UDP_MAX_QUERIES
.B int \fIudp_max_queries\fP;
.br
The maximum number of udp queries that can be sent on a single ephemeral port
to a given DNS server before a new ephemeral port is assigned. Any value of 0
or less will be considered unlimited, and is the default.
.br
.TP 18
.B ARES_OPT_QUERY_CACHE
.B unsigned int \fIqcache_max_ttl\fP;
.br
As of c-ares 1.31.0, the query cache is enabled by default with a TTL of 1hr.
To disable the query cache, specify this option with a TTL of 0. The query
cache is based on the returned TTL in the DNS message. Only fully successful
and NXDOMAIN query results will be cached. Fill in the \fIqcache_max_ttl\fP
with the maximum number of seconds a query result may be cached which will
override a larger TTL in the response message. This must be a non-zero value
otherwise the cache will be disabled. Choose a reasonable value for your
application such as 300 (5 minutes) or 3600 (1 hour). The query cache is
automatically flushed if a server configuration change is made.
.br
.TP 18
.B ARES_OPT_EVENT_THREAD
.B ares_evsys_t \fIevsys\fP;
.br
Enable the built-in event thread (Recommended). Introduced in c-ares 1.26.0.
Set the \fIevsys\fP parameter to \fBARES_EVSYS_DEFAULT\fP (0). Other values are
reserved for testing and should not be used by integrators.
This option cannot be used with the \fBARES_OPT_SOCK_STATE_CB\fP option, nor the
\fIares_set_socket_functions(3)\fP or
\fIares_set_socket_configure_callback(3)\fP functions.
When enabled, the integrator is no longer responsible for notifying c-ares of
any events on the file descriptors, so \fIares_process(3)\fP nor
\fIares_process_fd(3)\fP should ever be called when this option is enabled.
As of c-ares 1.29.0, when enabled, it will also automatically re-load the
system configuration when changes are detected.
Use \fIares_threadsafety(3)\fP to determine if this option is available to be
used.
Returns \fBARES_ENOTIMP\fP if this option is passed but not available, and
\fBARES_ESERVFAIL\fP if there is a critical failure during initialization of
the event thread.
.br
.TP 18
.B ARES_OPT_SERVER_FAILOVER
.B struct ares_server_failover_options \fIserver_failover_opts\fP;
.br
Configure server failover retry behavior. When a DNS server fails to
respond to a query, c-ares will deprioritize the server. On subsequent
queries, servers with fewer consecutive failures will be selected in
preference. However, in order to detect when such a server has recovered,
c-ares will occasionally retry failed servers. The
\fIares_server_failover_options\fP structure contains options to control this
behavior.
The \fIretry_chance\fP field gives the probability (1/N) of retrying a
failed server on any given query. Setting to a value of 0 disables retries.
The \fIretry_delay\fP field gives the minimum delay in milliseconds that c-ares
will wait before retrying a specific failed server.
If this option is not specificed then c-ares will use a probability of 10%
and a minimum delay of 5 seconds.
.br
.PP
The \fIoptmask\fP parameter also includes options without a corresponding
field in the
.B ares_options
structure, as follows:
.TP 23
.B ARES_OPT_ROTATE
Perform round-robin selection of the nameservers configured for the channel
for each resolution.
.TP 23
.B ARES_OPT_NOROTATE
Do not perform round-robin nameserver selection; always use the list of
nameservers in the same order.
.PP
.SH RETURN VALUES
\fBares_init_options(3)\fP and \fBares_init(3)\fP can return any of the
following values:
.TP 14
.B ARES_SUCCESS
Initialization succeeded.
.TP 14
.B ARES_EFILE
A configuration file could not be read.
.TP 14
.B ARES_ENOMEM
The process's available memory was exhausted.
.TP 14
.B ARES_ENOTINITIALIZED
c-ares library initialization not yet performed.
Add flag to not use a default local named server on channel initialization (#713) Hello, I work on an application for Microsoft which uses c-ares to perform DNS lookups. We have made some minor changes to the library over time, and would like to contribute these back to the project in case they are useful more widely. This PR adds a new channel init flag, described below. Please let me know if I can include any more information to make this PR better/easier for you to review. Thanks! **Summary** When initializing a channel with `ares_init_options()`, if there are no nameservers available (because `ARES_OPT_SERVERS` is not used and `/etc/resolv.conf` is either empty or not available) then a default local named server will be added to the channel. However in some applications a local named server will never be available. In this case, all subsequent queries on the channel will fail. If we know this ahead of time, then it may be preferred to fail channel initialization directly rather than wait for the queries to fail. This gives better visibility, since we know that the failure is due to missing servers rather than something going wrong with the queries. This PR adds a new flag `ARES_FLAG_NO_DFLT_SVR`, to indicate that a default local named server should not be added to a channel in this scenario. Instead, a new error `ARES_EINITNOSERVER` is returned and initialization fails. **Testing** I have added 2 new FV tests: - `ContainerNoDfltSvrEmptyInit` to test that initialization fails when no nameservers are available and the flag is set. - `ContainerNoDfltSvrFullInit` to test that initialization still succeeds when the flag is set but other nameservers are available. Existing FVs are all passing. **Documentation** I have had a go at manually updating the docs to describe the new flag/error, but couldn't see any contributing guidance about testing this. Please let me know if you'd like anything more here. --------- Fix By: Oliver Welsh (@oliverwelsh)
9 months ago
.TP 14
.B ARES_ENOSERVER
No DNS servers were available to use.
.SH NOTES
When initializing from
.B /etc/resolv.conf,
(or, alternatively when specified by the
.I resolvconf_path
path location)
\fBares_init_options(3)\fP and \fBares_init(3)\fP reads the \fIdomain\fP and
\fIsearch\fP directives to allow lookups of short names relative to the domains
specified. The \fIdomain\fP and \fIsearch\fP directives override one another.
If more than one instance of either \fIdomain\fP or \fIsearch\fP directives is
specified, the last occurrence wins. For more information, please see the
.BR resolv.conf (5)
manual page.
.SH SEE ALSO
.BR ares_reinit (3),
.BR ares_destroy (3),
.BR ares_dup (3),
.BR ares_library_init (3),
.BR ares_save_options (3),
.BR ares_set_servers (3),
.BR ares_set_sortlist (3),
.BR ares_threadsafety (3)