| commit | 39aeafd27ddabfcdcaa406ffb585d918bee7263e | [log] [tgz] |
|---|---|---|
| author | Brad House <brad@monetra.com> | Mon Mar 13 02:54:10 2017 -0400 |
| committer | Daniel Stenberg <daniel@haxx.se> | Mon Mar 13 07:54:10 2017 +0100 |
| tree | cbbcd8a75676bfa9eda3bc3c3bc995660f8eafd6 | |
| parent | 53387228abb04e0d51d40b4ae006ec2ed355055d [diff] |
Windows DNS server sorting (#81) Original Patch From Brad Spencer: https://c-ares.haxx.se/mail/c-ares-archive-2016-04/0000.shtml My modifications include: * Dynamically find GetBestRoute2 since it is a Windows Vista+ symbol, and will fall back to prior behavior when not available. * Prefer get_DNS_AdaptersAddresses as the modifications should alleviate the concerns which caused us to prefer get_DNS_NetworkParams * Update AppVeyor to use MinGW-w64 instead of the legacy MinGW * Fix compile error in test suite for Windows. Original message from patch below: From: Brad Spencer <bspencer@blackberry.com> Date: Fri, 29 Apr 2016 14:26:23 -0300 On Windows, the c-ares DNS resolver tries first to get a full list of DNS server addresses by enumerating the system's IPv4/v6 interfaces and then getting the per-interface DNS server lists from those interfaces and joining them together. The OS, at least in the way the c-ares prefers to query them (which also may be the only or best way in some environments), does not provide a unified list of DNS servers ordered according to "current network conditions". Currently, c-ares will then try to use them in whatever order the nested enumeration produces, which may result in DNS requests being sent to servers on one interface (hosting the current default route, for example) that are only intended to be used via another interface (intended to be used when the first interface is not available, for example). This, in turn, can lead to spurious failures and timeouts simply because of the server address order that resulted because of the enumeration process. This patch makes the (safe?) assumption that there is no other better rule to chose which interface's DNS server list should be prioritized. After all, a DNS lookup isn't something "per network"; applications don't look up "these DNS names on this interface and those DNS names on that interface". There is a single resource pool of DNS servers and the application should presume that any server will give it the "right" answer. However, even if all DNS servers are assumed to give equally useful responses, it is reasonable to expect that some DNS servers will not accept requests on all interfaces. This patch avoids the problem by sorting the DNS server addresses using the Windows IPv4/v6 routing tables. For example, a request to DNS server C on interface 2 that is actually sent over interface 1 (which may happen to have the default route) may be rejected by or not delivered to DNS server C. So, better to use DNS servers A and B associated with interface 1, at least as a first try. By using the metric of the route to the DNS server itself as a proxy for priority of the DNS server in the list, this patch is able to adapt dynamically to changes in the interface list, the DNS server lists per interface, which interfaces are active, the routing table, and so on, while always picking a good "best" DNS server first. In cases where any DNS server on any interface will do, this patch still seems useful because it will prioritize a lower-metric route's (and thus interface's) servers.
This is c-ares, an asynchronous resolver library. It is intended for applications which need to perform DNS queries without blocking, or need to perform multiple DNS queries in parallel. The primary examples of such applications are servers which communicate with multiple clients and programs with graphical user interfaces.
The full source code is available in the ‘c-ares’ release archives, and in a git repository: http://github.com/c-ares/c-ares. See the INSTALL.md file for build information.
If you find bugs, correct flaws, have questions or have comments in general in regard to c-ares (or by all means the original ares too), get in touch with us on the c-ares mailing list: http://cool.haxx.se/mailman/listinfo/c-ares
c-ares is of course distributed under the same MIT-style license as the original ares.
You'll find all c-ares details and news here: https://c-ares.haxx.se/
The distributed ares_build.h file is only intended to be used on systems which can not run the also distributed configure script.
The distributed ares_build.h file is generated as a copy of ares_build.h.dist when the c-ares source code distribution archive file is originally created.
If you check out from git on a non-configure platform, you must run the appropriate buildconf* script to set up ares_build.h and other local files before being able to compile the library.
On systems capable of running the configure script, the configure process will overwrite the distributed ares_build.h file with one that is suitable and specific to the library being configured and built, this new file is generated from the ares_build.h.in template file.
If you intend to distribute an already compiled c-ares library you MUST also distribute along with it the generated ares_build.h which has been used to compile it. Otherwise the library will be of no use for the users of the library that you have built. It is your responsibility to provide this file. No one at the c-ares project can know how you have built the library.
File ares_build.h includes platform and configuration dependent info, and must not be modified by anyone. Configure script generates it for you.
We cannot assume anything else but very basic compiler features being present. While c-ares requires an ANSI C compiler to build, some of the earlier ANSI compilers clearly can't deal with some preprocessor operators.
Newlines must remain unix-style for older compilers' sake.
Comments must be written in the old-style /* unnested C-fashion */
Try to keep line lengths below 80 columns.