A C library for asynchronous DNS requests (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

80 lines
2.6 KiB

/* MIT License
*
* Copyright (c) The c-ares project and its contributors
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* SPDX-License-Identifier: MIT
*/
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
#include "ares.h"
6 months ago
/* Include ares internal file for DNS protocol constants */
#include "ares_nameser.h"
int LLVMFuzzerTestOneInput(const unsigned char *data, unsigned long size);
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)
3 months ago
/* Fuzzing on a query name isn't very useful as its already fuzzed as part
* of the normal fuzzing operations. So we'll disable this by default and
* instead use this same fuzzer to validate our URI scheme parsers accessed
* via ares_set_servers_csv() */
#ifdef USE_LEGACY_FUZZERS
6 months ago
/* Entrypoint for Clang's libfuzzer, exercising query creation. */
int LLVMFuzzerTestOneInput(const unsigned char *data, unsigned long size)
{
6 months ago
/* Null terminate the data. */
char *name = malloc(size + 1);
unsigned char *buf = NULL;
int buflen = 0;
name[size] = '\0';
memcpy(name, data, size);
ares_create_query(name, C_IN, T_AAAA, 1234, 0, &buf, &buflen, 1024);
free(buf);
free(name);
return 0;
}
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)
3 months ago
#else
int LLVMFuzzerTestOneInput(const unsigned char *data, unsigned long size)
{
ares_channel_t *channel = NULL;
char *csv;
ares_library_init(ARES_LIB_INIT_ALL);
ares_init(&channel);
/* Need to null-term data */
csv = malloc(size + 1);
memcpy(csv, data, size);
csv[size] = '\0';
ares_set_servers_csv(channel, csv);
free(csv);
ares_destroy(channel);
ares_library_cleanup();
return 0;
}
#endif