|
|
|
# [![c-ares logo](https://c-ares.org/art/c-ares-logo.svg)](https://c-ares.org/)
|
|
|
|
|
|
|
|
[![Build Status](https://api.cirrus-ci.com/github/c-ares/c-ares.svg?branch=main)](https://cirrus-ci.com/github/c-ares/c-ares)
|
|
|
|
[![Windows Build Status](https://ci.appveyor.com/api/projects/status/aevgc5914tm72pvs/branch/main?svg=true)](https://ci.appveyor.com/project/c-ares/c-ares/branch/main)
|
|
|
|
[![Coverage Status](https://coveralls.io/repos/github/c-ares/c-ares/badge.svg?branch=main)](https://coveralls.io/github/c-ares/c-ares?branch=main)
|
|
|
|
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/291/badge)](https://bestpractices.coreinfrastructure.org/projects/291)
|
|
|
|
[![Fuzzing Status](https://oss-fuzz-build-logs.storage.googleapis.com/badges/c-ares.svg)](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened&can=1&q=proj:c-ares)
|
|
|
|
[![Bugs](https://sonarcloud.io/api/project_badges/measure?project=c-ares_c-ares&metric=bugs)](https://sonarcloud.io/summary/new_code?id=c-ares_c-ares)
|
|
|
|
[![Coverity Scan Status](https://scan.coverity.com/projects/c-ares/badge.svg)](https://scan.coverity.com/projects/c-ares)
|
|
|
|
|
|
|
|
- [Overview](#overview)
|
|
|
|
- [Code](#code)
|
|
|
|
- [Communication](#communication)
|
|
|
|
- [Release Keys](#release-keys)
|
|
|
|
- [Verifying signatures](#verifying-signatures)
|
|
|
|
- [Features](#features)
|
|
|
|
- [RFCs and Proposals](#supported-rfcs-and-proposals)
|
|
|
|
|
|
|
|
## Overview
|
|
|
|
[c-ares](https://c-ares.org) is a modern DNS (stub) resolver library, written in
|
|
|
|
C. It provides interfaces for asynchronous queries while trying to abstract the
|
|
|
|
intricacies of the underlying DNS protocol. It was originally intended for
|
|
|
|
applications which need to perform DNS queries without blocking, or need to
|
|
|
|
perform multiple DNS queries in parallel.
|
|
|
|
|
|
|
|
One of the goals of c-ares is to be a better DNS resolver than is provided by
|
|
|
|
your system, regardless of which system you use. We recommend using
|
|
|
|
the c-ares library in all network applications even if the initial goal of
|
|
|
|
asynchronous resolution is not necessary to your application.
|
|
|
|
|
|
|
|
c-ares will build with any C89 compiler and is [MIT licensed](LICENSE.md),
|
|
|
|
which makes it suitable for both free and commercial software. c-ares runs on
|
|
|
|
Linux, FreeBSD, OpenBSD, MacOS, Solaris, AIX, Windows, Android, iOS and many
|
|
|
|
more operating systems.
|
|
|
|
|
|
|
|
c-ares has a strong focus on security, implementing safe parsers and data
|
|
|
|
builders used throughout the code, thus avoiding many of the common pitfalls
|
|
|
|
of other C libraries. Through automated testing with our extensive testing
|
|
|
|
framework, c-ares is constantly validated with a range of static and dynamic
|
|
|
|
analyzers, as well as being constantly fuzzed by [OSS Fuzz](https://github.com/google/oss-fuzz).
|
|
|
|
|
|
|
|
While c-ares has been around for over 20 years, it has been actively maintained
|
|
|
|
both in regards to the latest DNS RFCs as well as updated to follow the latest
|
|
|
|
best practices in regards to C coding standards.
|
|
|
|
|
|
|
|
## Code
|
|
|
|
|
|
|
|
The full source code and revision history is available in our
|
|
|
|
[GitHub repository](https://github.com/c-ares/c-ares). Our signed releases
|
|
|
|
are available in the [release archives](https://c-ares.org/download/).
|
|
|
|
|
|
|
|
|
|
|
|
See the [INSTALL.md](INSTALL.md) file for build information.
|
|
|
|
|
|
|
|
## Communication
|
|
|
|
|
|
|
|
**Issues** and **Feature Requests** should be reported to our
|
|
|
|
[GitHub Issues](https://github.com/c-ares/c-ares/issues) page.
|
|
|
|
|
|
|
|
**Discussions** around c-ares and its use, are held on
|
|
|
|
[GitHub Discussions](https://github.com/c-ares/c-ares/discussions/categories/q-a)
|
|
|
|
or the [Mailing List](https://lists.haxx.se/mailman/listinfo/c-ares). Mailing
|
|
|
|
List archive [here](https://lists.haxx.se/pipermail/c-ares/).
|
|
|
|
Please, do not mail volunteers privately about c-ares.
|
|
|
|
|
|
|
|
**Security vulnerabilities** are treated according to our
|
|
|
|
[Security Procedure](SECURITY.md), please email c-ares-security at
|
|
|
|
haxx.se if you suspect one.
|
|
|
|
|
|
|
|
|
|
|
|
## Release keys
|
|
|
|
|
|
|
|
Primary GPG keys for c-ares Releasers (some Releasers sign with subkeys):
|
|
|
|
|
|
|
|
* **Daniel Stenberg** <<daniel@haxx.se>>
|
|
|
|
`27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2`
|
|
|
|
* **Brad House** <<brad@brad-house.com>>
|
|
|
|
`DA7D64E4C82C6294CB73A20E22E3D13B5411B7CA`
|
|
|
|
|
|
|
|
To import the full set of trusted release keys (including subkeys possibly used
|
|
|
|
to sign releases):
|
|
|
|
|
|
|
|
```bash
|
|
|
|
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2 # Daniel Stenberg
|
|
|
|
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys DA7D64E4C82C6294CB73A20E22E3D13B5411B7CA # Brad House
|
|
|
|
```
|
|
|
|
|
|
|
|
### Verifying signatures
|
|
|
|
|
|
|
|
For each release `c-ares-X.Y.Z.tar.gz` there is a corresponding
|
|
|
|
`c-ares-X.Y.Z.tar.gz.asc` file which contains the detached signature for the
|
|
|
|
release.
|
|
|
|
|
|
|
|
After fetching all of the possible valid signing keys and loading into your
|
|
|
|
keychain as per the prior section, you can simply run the command below on
|
|
|
|
the downloaded package and detached signature:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
% gpg -v --verify c-ares-1.29.0.tar.gz.asc c-ares-1.29.0.tar.gz
|
|
|
|
gpg: enabled compatibility flags:
|
|
|
|
gpg: Signature made Fri May 24 02:50:38 2024 EDT
|
|
|
|
gpg: using RSA key 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2
|
|
|
|
gpg: using pgp trust model
|
|
|
|
gpg: Good signature from "Daniel Stenberg <daniel@haxx.se>" [unknown]
|
|
|
|
gpg: WARNING: This key is not certified with a trusted signature!
|
|
|
|
gpg: There is no indication that the signature belongs to the owner.
|
|
|
|
Primary key fingerprint: 27ED EAF2 2F3A BCEB 50DB 9A12 5CC9 08FD B71E 12C2
|
|
|
|
gpg: binary signature, digest algorithm SHA512, key algorithm rsa2048
|
|
|
|
```
|
|
|
|
|
|
|
|
## Features
|
|
|
|
|
|
|
|
See [Features](FEATURES.md)
|
|
|
|
|
|
|
|
### Supported RFCs and Proposals
|
|
|
|
- [RFC1035](https://datatracker.ietf.org/doc/html/rfc1035).
|
|
|
|
Initial/Base DNS RFC
|
|
|
|
- [RFC2671](https://datatracker.ietf.org/doc/html/rfc2671),
|
|
|
|
[RFC6891](https://datatracker.ietf.org/doc/html/rfc6891).
|
|
|
|
EDNS0 option (meta-RR)
|
|
|
|
- [RFC3596](https://datatracker.ietf.org/doc/html/rfc3596).
|
|
|
|
IPv6 Address. `AAAA` Record.
|
|
|
|
- [RFC2782](https://datatracker.ietf.org/doc/html/rfc2782).
|
|
|
|
Server Selection. `SRV` Record.
|
|
|
|
- [RFC3403](https://datatracker.ietf.org/doc/html/rfc3403).
|
|
|
|
Naming Authority Pointer. `NAPTR` Record.
|
|
|
|
- [RFC6698](https://datatracker.ietf.org/doc/html/rfc6698).
|
|
|
|
DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol.
|
|
|
|
`TLSA` Record.
|
|
|
|
- [RFC9460](https://datatracker.ietf.org/doc/html/rfc9460).
|
|
|
|
General Purpose Service Binding, Service Binding type for use with HTTPS.
|
|
|
|
`SVCB` and `HTTPS` Records.
|
|
|
|
- [RFC7553](https://datatracker.ietf.org/doc/html/rfc7553).
|
|
|
|
Uniform Resource Identifier. `URI` Record.
|
|
|
|
- [RFC6844](https://datatracker.ietf.org/doc/html/rfc6844).
|
|
|
|
Certification Authority Authorization. `CAA` Record.
|
|
|
|
- [RFC2535](https://datatracker.ietf.org/doc/html/rfc2535),
|
|
|
|
[RFC2931](https://datatracker.ietf.org/doc/html/rfc2931).
|
|
|
|
`SIG0` Record. Only basic parser, not full implementation.
|
|
|
|
- [RFC7873](https://datatracker.ietf.org/doc/html/rfc7873),
|
|
|
|
[RFC9018](https://datatracker.ietf.org/doc/html/rfc9018).
|
|
|
|
DNS Cookie off-path dns poisoning and amplification mitigation.
|
|
|
|
- [draft-vixie-dnsext-dns0x20-00](https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00).
|
|
|
|
DNS 0x20 query name case randomization to prevent cache poisioning attacks.
|
|
|
|
- [RFC7686](https://datatracker.ietf.org/doc/html/rfc7686).
|
|
|
|
Reject queries for `.onion` domain names with `NXDOMAIN`.
|
|
|
|
- [RFC2606](https://datatracker.ietf.org/doc/html/rfc2606),
|
|
|
|
[RFC6761](https://datatracker.ietf.org/doc/html/rfc6761).
|
|
|
|
Special case treatment for `localhost`/`.localhost`.
|
|
|
|
- [RFC2308](https://datatracker.ietf.org/doc/html/rfc2308),
|
|
|
|
[RFC9520](https://datatracker.ietf.org/doc/html/rfc9520).
|
|
|
|
Negative Caching of DNS Resolution Failures.
|
|
|
|
- [RFC6724](https://datatracker.ietf.org/doc/html/rfc6724).
|
|
|
|
IPv6 address sorting as used by `ares_getaddrinfo()`.
|
|
|
|
- [RFC7413](https://datatracker.ietf.org/doc/html/rfc7413).
|
|
|
|
TCP FastOpen (TFO) for 0-RTT TCP Connection Resumption.
|
URI parser/writer for ares_set_servers_csv()/ares_get_servers_csv() (#882)
The DNS server format is insufficient for future configurations, such as
supporting DNS over TLS (DoT) and DNS over HTTPS (DoH), as well as
additional functionality such as domain-specific servers. Already, in
the case where different UDP and TCP ports are used, it is impossible to
represent in the current format.
In order to try to use some standardized format, we are going to define
our own URI schemes that should be parse-able by any URI parser. The new
scheme will only be used when the configuration cannot otherwise be
expressed using the current `ipaddr%iface:port` format, which is the
format used as the nameserver configuration in `/etc/resolv.conf`.
However, the parser `ares_set_servers_csv()` shall accept the new URI
scheme format even when it is not necessary.
This PR implements a URI parser and writer and hooks the basic usage
into `ares_set_servers_csv()` and `ares_get_servers_csv()` as well as
provides updated documentation in the relevant manpages.
We will define these URI schemes:
* `dns://` - Normal DNS server (UDP + TCP). We need to be careful not to
conflict with query params defined in
https://datatracker.ietf.org/doc/html/rfc4501 since we'd technically be
extending this URI scheme. Port defaults to `53`.
* `dns+tls://` - DNS over TLS. Port defaults to `853`.
* `dns+https://` - DNS over HTTPS. Port defaults to `443`.
We initially will define these query parameters (additional arguments
may be required in the future to specify options such as TLS certificate
validation rules):
* `tcpport` - TCP port to use, only for `dns://` scheme. The `port`
specified as part of the `authority` component of the URI will be used
for both UDP and TCP by default, this option will override the TCP port.
* `ipaddr` - Only for `dns+tls://` and `dns+https://`. If the
`authority` component of the URI contains a hostname, this is used to
specify the ip address of the hostname. If not specified, will need to
use a non-secure server to perform a DNS lookup to retrieve this
information. It is always recommended to have both the ip address and
fully qualified domain name specified.
* `hostname` - Only for `dns+tls://` and `dns+https://`. If the
`authority` component of the URI contains an ip address, this is used to
specify the fully qualified domain name of the server. If not specified,
will need to use a non-secure server to perform a DNS reverse lookup to
retrieve this information. It is always recommended to have both the ip
address and fully qualified domain name specified.
* `domain` - If specified, this server is a domain-specific server. Any
queries for this domain will be routed to this server. Multiple servers
may be tagged with the same domain.
Examples:
```
dns://8.8.8.8
dns://[2001:4860:4860::8888]
dns://[fe80::b542:84df:1719:65e3%en0]
dns://192.168.1.1:55
dns://192.168.1.1?tcpport=1153
dns://10.0.1.1?domain=myvpn.com
dns+tls://8.8.8.8?hostname=dns.google
dns+tls://one.one.one.one?ipaddr=1.1.1.1
```
NOTE: While we are defining the scheme for things like domain-specific
servers, DNS over TLS and DNS over HTTPS, the underlying implementations
for those features do not yet exist and therefore will result in errors
if they are attempted to be used.
### Non-compliance in implementation
All these could be easily implemented/fixed if desired, however any such
changes would be of no use to the current c-ares usage of URIs:
* Does not currently support relative references
* Requires use of the authority section, blank is not allowed
* The query string is interpreted to be in
[application/x-www-form-urlencoded](https://en.wikipedia.org/wiki/Application/x-www-form-urlencoded)
format only and will result in parse errors if it is not. This is the
most common format used, however technically not valid to mandate this
format is used. We could add flags in the future to treat the query
string as opaque and leave it to the user to process. Or we could
internally have a list of schemes that use this format.
* [IDNA](https://en.wikipedia.org/wiki/Internationalized_domain_name) is
not supported.
* Does not support hex-encoded IPv4 addresses (this is compliant with RFC3986, but not WHATWG)
Authored-By: Brad House (@bradh352)
2 months ago
|
|
|
- [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986).
|
|
|
|
Uniform Resource Identifier (URI). Used for server configuration.
|