EVDNS(3) | NetBSD Library Functions Manual | EVDNS(3) |
int
evdns_init();
void
evdns_shutdown(int fail_requests);
const char *
evdns_err_to_string(int err);
int
evdns_nameserver_add(unsigned long int address);
int
evdns_count_nameservers();
int
evdns_clear_nameservers_and_suspend();
int
evdns_resume();
int
evdns_nameserver_ip_add(const(char, *ip_as_string););
int
evdns_resolve_ipv4(const char *name, int flags, evdns_callback_type callback, void *ptr);
int
evdns_resolve_reverse(struct in_addr *in, int flags, evdns_callback_type callback, void *ptr);
int
evdns_resolv_conf_parse(int flags, const char *);
void
evdns_search_clear();
void
evdns_search_add(const char *domain);
void
evdns_search_ndots_set(const int ndots);
void
evdns_set_log_fn(evdns_debug_log_fn_type fn);
int
evdns_config_windows_nameservers();
Async DNS lookups are really a whole lot harder than they should be, mostly stemming from the fact that the libc resolver has never been very good at them. Before you use this library you should see if libc can do the job for you with the modern async call getaddrinfo_a (see http://www.imperialviolet.org/page25.html#e498). Otherwise, please continue.
This code is based on libevent and you must call event_init before any of the APIs in this file. You must also seed the OpenSSL random source if you are using OpenSSL for ids (see below).
This library is designed to be included and shipped with your source code. You statically link with it. You should also test for the existence of strtok_r and define HAVE_STRTOK_R if you have it.
The DNS protocol requires a good source of id numbers and these numbers should be unpredictable for spoofing reasons. There are three methods for generating them here and you must define exactly one of them. In increasing order of preference:
The library keeps track of the state of nameservers and will avoid them when they go down. Otherwise it will round robin between them.
Quick start guide:
#include <evdns.h> void callback(int result, char type, int count, int ttl, void *addresses, void *arg); evdns_resolv_conf_parse(DNS_OPTIONS_ALL, "/etc/resolv.conf"); evdns_resolve("www.hostname.com", 0, callback, NULL);
When the lookup is complete the callback function is called. The first argument will be one of the DNS_ERR_* defines in evdns.h. Hopefully it will be DNS_ERR_NONE, in which case type will be DNS_IPv4_A, count will be the number of IP addresses, ttl is the time which the data can be cached for (in seconds), addresses will point to an array of uint32_t's and arg will be whatever you passed to evdns_resolve.
Searching:
In order for this library to be a good replacement for glibc's resolver it supports searching. This involves setting a list of default domains, in which names will be queried for. The number of dots in the query name determines the order in which this list is used.
Searching appears to be a single lookup from the point of view of the API, although many DNS queries may be generated from a single call to evdns_resolve. Searching can also drastically slow down the resolution of names.
To disable searching:
The order of searches depends on the number of dots in the name. If the number is greater than the ndots setting then the names is first tried globally. Otherwise each search domain is appended in turn.
The ndots setting can either be set from a resolv.conf, or by calling evdns_search_ndots_set.
For example, with ndots set to 1 (the default) and a search domain list of ["myhome.net"]:
Query: www
Order: www.myhome.net, www.
Query: www.abc
Order: www.abc., www.abc.myhome.net
The callback argument is a function which is called when this query completes and ptr is an argument which is passed to that callback function.
Returns non-zero on error
See the man page for resolv.conf for the format of this file. The flags argument determines what information is parsed from this file:
The following directives are not parsed from the file:
sortlist, rotate, no-check-names, inet6, debug
Returns non-zero on error:
The second is the waiting queue. The size of the inflight ring is limited and all other requests wait in waiting queue for space. This bounds the number of concurrent requests so that we don't flood the nameserver. Several algorithms require a full walk of the inflight queue and so bounding its size keeps thing going nicely under huge (many thousands of requests) loads.
If a nameserver loses too many requests it is considered down and we try not to use it. After a while we send a probe to that nameserver (a lookup for google.com) and, if it replies, we consider it working again. If the nameserver fails a probe we wait longer to try again with the next probe.
May 14, 2010 | NetBSD 5.99 |