Brussels / 3 & 4 February 2018


Living on the Edge

Greatly needed stub resolver capabilities for applications and systems with the getdns library

To improve system security to the next level, the DNS services used by applications at the end-point need recent standards implemented. Currently typical use of DNS by applications is limited to forwarding requests to the system's stub resolver, which in turn simply forwards it to the recursive resolver in the network which does all the heavy lifting; iterate over the authoritatives, secure the lookups with DNSSEC etc.  This first-mile in the DNS eco-system (from application, via stub to the recursive resolver) is completely insecure and exposed. This makes the use of DANE (a secure alternative to the flawed CA based PKIX) impossible and also leaves end-users unprotected to DNS based connection hijacking and very exposed to eavesdropping attacks!

To deliver DANE and Privacy to the end-user, we need to address these issues as close to the end-user as possible. The getdns library is a resolver library for applications, providing a versatile stub resolver that takes care of all the difficulties and complexities that arise when these higher security and privacy demands need to be practiced for actual users instead of just networks.

For both DANE and DNS Privacy, stub resolvers need to be able to reliably establish the authenticity of data at the remote end. This alone already involves DNSSEC and/or PKIX validation, and might also involve DNSSEC roadblocks avoidance, discovery and anticipating IPv6-only networks (DNS64/NAT64), and reliable trust requirements maintenance (i.e. the KSK rollover). Furthermore, to correctly perform DANE, applications need to learn from the stub resolver the status of the authentication result.

In the course of the presentation the following topics will be covered:

  * the current techniques stub resolvers utilise to reliably do DNSSEC,   * the changing architectural role of the stub-resolver system-component (Stub as daemon, as library, as both, dbus interface, nsswitch module),   * the stub resolver specific challenges with the root KSK rollover, and   * the implementation status of different stub software with respect to the bullet points above.


Willem Toorop