1. 31 Jan, 2019 1 commit
    • George Kulakowski's avatar
      [cares] Suppress a Wunused-function warning · 538d4537
      George Kulakowski authored
      This function is morally static, but exposed for testing, and happens
      to be unused with our configuration. It is thus actually unused when
      not building tests.
      
      This seems the clearest way to suppress the warning, and seems
      preferable to a binary-wide or even file-wide compiler flag toggle.
      
      Test: built and observed no more warning
      Change-Id: Ib3169ba35afbe29008dd428a2dd99b91543422b8
      538d4537
  2. 09 Jan, 2019 1 commit
  3. 17 May, 2018 1 commit
  4. 04 Apr, 2018 1 commit
  5. 10 Mar, 2018 1 commit
  6. 24 Jun, 2017 1 commit
  7. 20 Jun, 2017 1 commit
  8. 06 Jun, 2017 1 commit
    • ChristianAmmer's avatar
      Added support for Windows DNS Suffix Search List (#93) · cb9521d5
      ChristianAmmer authored
      This change solves issue #53.
      
      Support for suffix search lists was already built in for Linux. The search list could be set via set_search. With this change the suffix search list from Windows is read from the registry and then set into the ares configuration via set_search. There are two sources for the search list:
      
      The global DNS suffix search list.
      The primary and connection specific DNS suffixes if the global is not available.
      
      Contributed by @ChristianAmmer 
      cb9521d5
  9. 26 May, 2017 1 commit
  10. 23 May, 2017 4 commits
  11. 21 May, 2017 1 commit
  12. 02 May, 2017 1 commit
  13. 18 Mar, 2017 7 commits
  14. 17 Mar, 2017 2 commits
  15. 14 Mar, 2017 1 commit
  16. 13 Mar, 2017 1 commit
    • Brad House's avatar
      Windows DNS server sorting (#81) · 39aeafd2
      Brad House authored
      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.
      39aeafd2
  17. 22 Feb, 2017 1 commit
  18. 06 Feb, 2017 2 commits
  19. 31 Jan, 2017 4 commits
  20. 30 Jan, 2017 1 commit
  21. 15 Jan, 2017 5 commits
  22. 11 Jan, 2017 1 commit