The standard C library provides a number of functions related to host and service name resolution and DNS information retrieval. The former are mainly intended to support applications when connecting to services while the latter gives them access to additional DNS information.
Name resolution for libraries
Current versions of glibc offer the
res_*() functions and
_res.options. The former two are used for host and service name resolution and for DNS record retrieval, respectively. While this works well for applications, libraries may need to tweak the configuration without affecting the application. Basically, the configuration needs to be specific to the caller and the caller needs to be able to provide the configuration when performing host/service name resolution and DNS record retrieval.
Example use case
A cryptographic library may want to configure the resolver so that it only receives records secured by DNSSEC. The same library may also want to perform ordinary name resolution where records not secured by DNSSEC are returned as well. None of the configuration should ever affect the running application, therefore three different configuration contexts are needed.
For each libc library function that uses the shared context, provide a new function that would accept an opaque pointer to a specific context object. We also need to provide a set of functions to create and configure the context object.
For example, netresolve provides a context object and allows for all sorts of name resolution backends including DNS.
- Test program to check a blocking call to
netresolve_query_getaddrinfo()using a brand new object for the query.
A global context could still be available and the classic
getaddrinfo() function could call the new function with the global context.
The application and the libraries can be single-threaded as well as multi-threaded. Any solutions using thread local storage are therefore not generally suitable.
File descriptor based non-blocking API
The libc socket API allows for both blocking and non-blocking usage, thus being useful in all sorts of single threaded and multi-threaded applications and libraries. This doesn't apply to the libc name resolution API which is strictly blocking from top to bottom. Unfortunately this also applies to the nsswitch backend API.
Add a new non-blocking API for applications and a new non-blocking API for nsswitch backends.
What to do with nsswitch backends that don't support the new API, yet?
For example, netresolve provides a file descriptor based non-blocking API.
Trusted validating name servers
The current glibc implicitly trusts all name servers specified in
/etc/resolv.conf and the
res_* functions pass the AD flag to calling applications. This tricks applications into believing validation results of random servers recieved through DHCP and other means. If the requested DNS record was for example TLSA, the application (or a security library) is tricked into believing that the key data are secured by DNSSEC and have been properly validated.
Add a new directive to
/etc/resolv.conf specifying that the listed nameservers are trusted.
nameserver 184.108.40.206 nameserver 220.127.116.11 trusted-nameservers
Add a new directive to specify a trusted name server.
nameserver 18.104.22.168 nameserver 22.214.171.124 trusted-nameserver 126.96.36.199 trusted-nameserver 188.8.131.52
Secure only mode for name resolution
An application or a security library may want to perform a DNS information query in a secure only mode where only results secured by DNSSEC and validated by a trusted name server are returned.
A security library requests the TLSA record but only cares about one that is secured by DNSSEC and successfully validated.
Add a resolver configuration option to only return results secured by DNSSEC.
Resolve a host name to a list of network layer addresses
The getaddrinfo API as implemented in glibc doesn't provide a replacement for gethostbyname, i.e. an API that would return a list of network layer addresses for a host name.
- IP-based access lists
- Network layer testing tools
- Any tools working with non-TCP non-UDP protocols
- Possibly even tools working with TCP and UDP
- family (AF_UNSPEC, AF_INET, AF_INET6)
- List of sockaddr style addresses (zero ports, zero protocols, etc)
- Canonical name (why?)