A C library for asynchronous DNS requests

Overview

c-ares

Build Status Windows Build Status Coverage Status CII Best Practices Fuzzing Status Releases

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/

Notes for c-ares hackers

  • 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.

Comments
  • Support for ares getaddrinfo

    Support for ares getaddrinfo

    This is a deeply reworked https://github.com/c-ares/c-ares/pull/112, though I have changed everything except maybe tests. It still lacks proper sorting (rfc and sortlist), but I hope to fix it later. Update: sorting as a separate function available in #239

    Summary of changes:

    • ares_addrinfo structure, with allocating function ares__malloc_addrinfo/ares__append_addrinfo, the latter one links new addrinfo to existing one
    • ares_sockaddr union; ares_process.c modified to use that union too
    • ares_getaddrinfo function, first resolves port than looks into hosts file and than performs AAAA and A lookups for AF_UNSPEC and/or A/AAAA lookups for AF_INET/AF_INET6. The resulting list is not sorted. Also there are no aliases in hostent sense as they are represented via separate linked addrinfo structures.
      • lookup_service function, uses getservbyname_r to get numeric name of the service
        • getservbyname_r function, copied from getservbyport_r
      • fake_addrinfo function, allocates addrinfo if we have an ip address in host field (same as fake_hostent)
      • next_lookup function, for file and dns lookups
        • ares__get_addrinfo function gets ares_addrinfo from file, it differs a bit from similar function in gethostbyname
    • ~~ares_parse_a_reply/ares_parse_aaaa_reply both changed to parse into ares_addrinfo structure~~ changed back in favour of private ares__parse_a/ares__parse_aaaa
    • new tests, though there are no ares_parse_a_reply/ares_parse_aaaa_reply tests with ares_getaddrinfo yet
    • manuals for all the public functions
    • clang format file to keep things in order, though tests style is different
    opened by ki11roy 44
  • Adding feature ares_getaddrinfo

    Adding feature ares_getaddrinfo

    Currently AF_UNSPEC is not well supported by ares. This Pull Request is a first attempt of an implementation of ares_getaddrinfo. Many details of the RFC described getaddrinfo are not implemented, however I think it's good enough for a starting point. It gets tested through:

    [ RUN ] AddressFamilies/MockChannelTestAI.FamilyV6/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyV6/0 (1 ms) [ RUN ] AddressFamilies/MockChannelTestAI.FamilyV4/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyV4/0 (1 ms) [ RUN ] AddressFamilies/MockChannelTestAI.FamilyV4_MultipleAddresses/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyV4_MultipleAddresses/0 (1 ms) [ RUN ] AddressFamilies/MockChannelTestAI.FamilyUnspecified/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyUnspecified/0 (2 ms)

    opened by ChristianAmmer 44
  • Windows DNS Server Order by Route Metrics

    Windows DNS Server Order by Route Metrics

    Based off original patch submitted by Brad Spencer [email protected] via https://c-ares.haxx.se/mail/c-ares-archive-2016-04/0000.shtml

    The original patch relied on Windows Vista-specific functions, I've made slight tweaks to load those functions dynamically for compatibility with older systems.

    Below is the original submission comments: 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.

    opened by bradh352 27
  • c-ares 1.17.0 release package issues

    c-ares 1.17.0 release package issues

    Building c-ares 1.17.0 from tarball c-ares-1.17.0.tar.gz fails because cmake can't find the following files:

    • c-ares-config.cmake.in
    • libcares.pc.cmake

    I tried to build (with Ninja as build tool) with the following cmake command:

    cmake -GNinja -DCMAKE_BUILD_TYPE:STRING=Release -DCARES_SHARED:BOOL=ON -DCARES_STATIC:BOOL=ON
    

    I have reproduced the issue both on Debian Linux as on Windows using MinGW-w64 GCC in MSYS2 shell.

    This is the output:

    CMake Error: File /home/brecht/_/c-ares-1.17.0/c-ares-config.cmake.in does not exist.
    CMake Error at /usr/share/cmake-3.13/Modules/CMakePackageConfigHelpers.cmake:316 (configure_file):
      configure_file Problem configuring file
    Call Stack (most recent call first):
      CMakeLists.txt:606 (CONFIGURE_PACKAGE_CONFIG_FILE)
    
    
    CMake Error: File /home/brecht/_/c-ares-1.17.0/libcares.pc.cmake does not exist.
    CMake Error at CMakeLists.txt:623 (CONFIGURE_FILE):
      CONFIGURE_FILE Problem configuring file
    
    
    -- Configuring incomplete, errors occurred!
    
    opened by brechtsanders 23
  • Added support for Windows DNS Suffix Search List

    Added support for Windows DNS Suffix Search List

    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:

    1. The global DNS suffix search list.
    2. The primary and connection specific DNS suffixes if the global is not available.
    opened by ChristianAmmer 22
  • ares_gethostbyname Appears to Leak from an 'ares_strdup' at the Conclusion of a Successful Query

    ares_gethostbyname Appears to Leak from an 'ares_strdup' at the Conclusion of a Successful Query

    When invoking ares_gethostbyname for a forward DNS name-to-address lookup, there seems to be a leak from ares_strdup, as reported by the clang/LLVM address sanitizer:

    Making check in examples
    Making check in CFHost
    make  CFHostExample
      CCLD     CFHostExample
    /bin/bash ../../libtool --mode execute ./CFHostExample
    Asynchronous lookups...
    By name 'localhost' (Forward DNS)...
        Resolved names:
            0: localhost
        Resolved addresses:
            0: ::1
            1: 127.0.0.1
    
    =================================================================
    ==1551143==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 10 byte(s) in 1 object(s) allocated from:
        #0 0x7fac81a14bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
        #1 0x7fac81325487 in ares_strdup (/usr/local/lib/libcares.so.2+0x10487)
    

    This was/is demonstrated against c-ares-1.18.1 using https://github.com/gerickson/opencfnetwork/blob/user/gerickson/github-issue-8-forward-dns-deadlock/third_party/CFNetwork/repo/Host/CFHost.c#L2770 along with the example application https://github.com/gerickson/opencfnetwork/blob/user/gerickson/github-issue-8-forward-dns-deadlock/examples/CFHost/CFHostExample.c.

    opened by gerickson 19
  • Service for getaddrinfo

    Service for getaddrinfo

    This branch is a development of #232. Some major changes are support of search domains and combining of ares_parse_a/aaaa_reply into ares__parse_into_addrinfo, though I haven't touched the original functions yet. I had to introduce additional flag ARES_AI_NOSORT to disable connecting to mock addresses while sorting. My first idea was to use ares_socket_functions, but there is no "getsockname" mock, so flag seems a better variant. Struct ares_addrinfo extended to keep ai_ttl and ai_cname_ttl. The latest ares_getaddrinfo fixes are not actual anymore, because the code is removed.

    opened by ki11roy 19
  • Portability updates for legacy systems.

    Portability updates for legacy systems.

    socklen_t should not be used in code, instead ares_socklen_t should be used. New type of ares_ssize_t to mimic ares_socklen_t since ssize_t isn't available on all platforms, must like socklen_t, we need to define our own as it is now part of the public headers.

    opened by bradh352 18
  • Virtual socket IO functions

    Virtual socket IO functions

    To integrate the C-ares library with seastar, we need to be able to control the way socket IO is performed, since

    1.) We optionally use our own network stack (virtio/dpdk) 2.) We do asynchronous even more asynchronous.

    This patch set adds a virtual socket function struct to c-ares, which can be attached to an individual channel using a setter function. The socket IO code is modified to use these bound functions if set (which in turn forgoes a lot of socket options etc, with the assumption that the provider deals with such matters.

    opened by elcallio 18
  • Add CMake build system support to C-Ares.

    Add CMake build system support to C-Ares.

    The patch does not modify any source files, it only adds 3 new files (CMakelists.txt, ares_build.h.cmake, ares_config.h.cmake) which form the build system. I've tried to go through as much of the autotools tests and extracted what I thought was appropriate, though many of the tests aren't as in-depth in CMake as they are for autotools ... it is unclear why some of them exist at all, I'm guessing for legacy systems that CMake probably doesn't support anyhow.

    Building the library, and examples (adig, ahost, acountry) plus installation should work across a large number of tested platforms. The tests have not yet been integrated.

    opened by bradh352 17
  • error compiling on c-ares AIX

    error compiling on c-ares AIX

    When trying to compile on AIX, I see the following error:

    In file included from /tmp/aix_softwares/cares-1.14.0/ares_parse_a_reply.c:34:
    /usr/include/arpa/nameser_compat.h:244:3: error: conflicting types for 'HEADER'
     } HEADER;
       ^~~~~~
    In file included from /usr/include/arpa/nameser.h:645,
                     from /tmp/aix_softwares/cares-1.14.0/ares_parse_a_reply.c:29:
    /usr/include/arpa/onameser_compat.h:265:3: note: previous declaration of 'HEADER' was here
     } HEADER;
       ^~~~~~
    

    To compile, I did the following:

    cd /path/to/cmake/source
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local/cares ..
    
    

    Any suggestions on how to solve the problem? I would be willing to send a PR for this, if suggestion is given. Problem seems to be that on AIX both these HEADER is defined in both .h files. Please let me know.

    opened by amandeepgautam 16
  • docs: reformat/cleanup man pages SYNOPSIS sections

    docs: reformat/cleanup man pages SYNOPSIS sections

    To make them render "nicer" in both terminals and on the website.

    • Removes the bold
    • Removes .PP lines
    • Indents them more like proper code style
    Documentation 
    opened by bagder 0
  • Documentation says ares_options.udp_port is in network byte order

    Documentation says ares_options.udp_port is in network byte order

    The documentation says:

    ARES_OPT_UDP_PORT unsigned short udp_port;
    The port to use for queries over UDP, in network byte order. The default value is 53 (in network byte order), the standard name service port.
    

    Yet, the code says:

      // NOTE: c-ares is assuming `options->udp_port` is in host byte order!
      if ((optmask & ARES_OPT_UDP_PORT) && channel->udp_port == -1)
        channel->udp_port = htons(options->udp_port);
    
    opened by aaron-michaux 2
  • [suggestion]Find a way to optimize out the OS calls in find_src_addr

    [suggestion]Find a way to optimize out the OS calls in find_src_addr

    Hi,

    I'm using c-ares recently, I noticed that there are a heavy OS calls in find_src_addr function , Do we have any way to optimize these OS calls out ?

    opened by ffproxy 3
  • CMake config files are not installed when building with autotools

    CMake config files are not installed when building with autotools

    When building c-ares with CMake the following files are installed: /lib64/cmake/c-ares/c-ares-targets.cmake /lib64/cmake/c-ares/c-ares-targets-noconfig.cmake /lib64/cmake/c-ares/c-ares-config.cmake /lib64/cmake/c-ares/c-ares-config-version.cmake

    These files allow consumers using CMake to find/import c-ares using find_package(c-ares).

    However, when building c-ares using the autotools buildsystem these files are not installed, meaning consumers cannot find/import c-ares that way.

    Some Linux distributions build c-ares using CMake while others build it using autotools. This produces inconsistent and surprising behavior for consumers of c-ares. Consumers should not need to know or care how a library was built in order to use it.

    opened by nicolasfella 4
  • Resolve foo.localhost as localhost

    Resolve foo.localhost as localhost

    From https://github.com/nodejs/undici/issues/1571:

    Bug Description

    In my local development env I got Hasura running and responding on hasura.localhost. This works fine in Chrome, I can open the web UI and do stuff from there. However this does not seem to work when trying to query the api using undici (see reproducible by below).

    This seems to break RFC-6761:

    Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

    So it seems that Chrome resolves hasura.localhost as the localhost loopback, while Node.js and in in turn c-ares do not.

    From a quick look at it, https://github.com/c-ares/c-ares/blob/e20215ab931eaf91a89b9fe3441dac18c4305979/src/lib/ares_getaddrinfo.c#L490-L499 does not handle this case.

    opened by mcollina 6
Owner
c-ares
Asynchronous name resolves and DNS functions. And stuff.
c-ares
C++ Requests: Curl for People, a spiritual port of Python Requests

C++ Requests: Curl for People Announcements The cpr project has new maintainers: Fabian Sauter and Tim Stack. TLDR C++ Requests is a simple wrapper ar

Huu Nguyen 5.1k Nov 25, 2022
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket, MQTT built-in protocols, async DNS resolver, and non-blocking API.

Mongoose - Embedded Web Server / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Cesanta Software 9k Dec 2, 2022
DNS and Target HTTP History Local Storage and Search

dooked DNS and Target HTTP History Local Storage and Search Installation Download Boost Library from the official website Extract the library into any

Michael Skelton 60 Oct 31, 2022
A local DNS server to obtain the fastest website IP for the best Internet experience

A local DNS server to obtain the fastest website IP for the best Internet experience

Nick Peng 5.5k Nov 23, 2022
a lightweight and performant multicast DNS (mDNS) reflector with modern design, supports zone based reflection and IPv6

mDNS Reflector mDNS Reflector (mdns-reflector) is a lightweight and performant multicast DNS (mDNS) reflector with a modern design. It reflects mDNS q

Yuxiang Zhu 87 Nov 28, 2022
deserter is the first of its kind targeted DNS cache poisoner

deserter is the first of its kind targeted DNS cache poisoner. It is capable of DNS cache poisoning without bruteforcing the target ID and source port - instead, it sniffs out DNS probes and uses the information inside to craft poisoned responses and send them back to the target.

null 90 Nov 9, 2022
deserter is a targeted DNS cache poisoner.

deserter is a targeted DNS cache poisoner. It is capable of DNS cache poisoning without bruteforcing the target ID and source port - instead, it sniffs out DNS probes and uses the information inside to craft poisoned responses and send them back to the target.

null 90 Nov 9, 2022
Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.

Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.

null 53 Nov 20, 2022
Brutally effective DNS amplification ddos attack tool. Can cripple a target machine from a single host. Use with extreme caution.

Brutally effective DNS amplification ddos attack tool. Can cripple a target machine from a single host. Use with extreme caution.

thescientist 0 Nov 28, 2022
DNS amplification DDOS attack tool.

DNS amplification DDOS attack tool.

the-scientist 27 Sep 23, 2022
A project designed for the esp8266 D1 Mini or the esp8266 D1 Mini PRO to provide a wifi http server and dns server.

PS4 Server 9.00 This is a project designed for the esp8266 D1 Mini or the esp8266 D1 Mini PRO to provide a wifi http server and dns server. this is fo

null 13 Sep 7, 2022
requests-like networking library using boost for C++

cq == C++ Requests cq == C++ Requests is a "Python Requests"-like C++ header-only library for sending HTTP requests. The library is inspired a lot by

null 11 Dec 15, 2021
C++ client for making HTTP/REST requests

REST client for C++ About This is a simple REST client for C++. It wraps libcurl for HTTP requests. Usage restclient-cpp provides two ways of interact

Daniel Schauenberg 1.4k Dec 1, 2022
Application that sends custom requests to League of Legends LCU api

More screenshots For fun project made in the span of 2 nights back in February 2021, which I'm now updating Technologies used No external libraries, o

null 168 Nov 29, 2022
Filter Garry'sMod built-in HTTP requests with a lua hook

Filter Garry'sMod built-in HTTP requests with a lua hook

Earu 3 Jul 28, 2022
traces tcp requests in kernel. allow to set up IPs to filter dynamically using bpf-map.

ttcp cilium/ebpf/examples/tcprtt에다가 BPF_MAP_TYPE_HASH를 추가해서 srcAddr을 필터링하도록 수정함. 어플리케이션에는 Http API를 추가해서 필터링할 IP를 추가, 삭제, 조회할 수 있도록 함. Getting Startd

null 8 May 20, 2022
Cross-platform, efficient, customizable, and robust asynchronous HTTP/WebSocket server C++14 library with the right balance between performance and ease of use

What Is RESTinio? RESTinio is a header-only C++14 library that gives you an embedded HTTP/Websocket server. It is based on standalone version of ASIO

Stiffstream 912 Nov 25, 2022
Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution

CppServer Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and

Ivan Shynkarenka 938 Nov 29, 2022
A Lightweight and fully asynchronous WebSocket client library based on libev

libuwsc(中文) A Lightweight and fully asynchronous WebSocket client library based on libev for Embedded Linux. And provide Lua-binding. Why should I cho

Jianhui Zhao 285 Nov 17, 2022