|
|
|
|
.\"
|
|
|
|
|
.\" Copyright 1998 by the Massachusetts Institute of Technology.
|
|
|
|
|
.\" Copyright (C) 2004-2010 by Daniel Stenberg
|
|
|
|
|
.\"
|
|
|
|
|
.\" SPDX-License-Identifier: MIT
|
|
|
|
|
.\"
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
.TH ARES_INIT_OPTIONS 3 "5 March 2010"
|
|
|
|
|
.SH NAME
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
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;
|
|
|
|
|
int udp_max_queries;
|
|
|
|
|
int maxtimeout; /* in milliseconds */
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
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,
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
int \fIoptmask\fP);
|
|
|
|
|
|
|
|
|
|
int ares_init(ares_channel_t **\fIchannelptr\fP);
|
|
|
|
|
|
|
|
|
|
.fi
|
|
|
|
|
.SH DESCRIPTION
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
The \fBares_init(3)\fP function is equivalent to calling
|
|
|
|
|
\fBares_init_options(channelptr, NULL, 0)\fP. It is recommended to use
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
\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
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
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.
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
.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
|
|
|
|
|
first try. (After the first try, the timeout algorithm becomes more
|
|
|
|
|
complicated, but scales linearly with the value of \fItimeout\fP.) The
|
|
|
|
|
default is two seconds. This option is being deprecated by
|
|
|
|
|
\fIARES_OPT_TIMEOUTMS\fP starting in c-ares 1.5.2.
|
|
|
|
|
.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
|
|
|
|
|
the first try. (After the first try, the timeout algorithm becomes more
|
|
|
|
|
complicated, but scales linearly with the value of \fItimeout\fP.) The
|
|
|
|
|
default is two seconds. 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.
|
|
|
|
|
.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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
.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
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
.TP 18
|
|
|
|
|
.B ARES_OPT_QUERY_CACHE
|
|
|
|
|
.B unsigned int \fIqcache_max_ttl\fP;
|
|
|
|
|
.br
|
|
|
|
|
Enable the built-in query cache. Will cache queries 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).
|
|
|
|
|
.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
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
|
|
|
|
|
.SH RETURN VALUES
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
\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)
|
Query Cache support (#625)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes #608
Fix By: Brad House (@bradh352)
1 year ago
|
|
|
\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)
|
