From 416ef5e2bf59bb2e45066a1d5d91ac677c0f48e5 Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Wed, 10 Dec 2014 03:05:47 +0000 Subject: Initial commit --- doc/libresolv.html | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 doc/libresolv.html (limited to 'doc/libresolv.html') diff --git a/doc/libresolv.html b/doc/libresolv.html new file mode 100644 index 0000000..7a9fd31 --- /dev/null +++ b/doc/libresolv.html @@ -0,0 +1,140 @@ + + + + + s6-dns: the problem with libresolv + + + + + + +

+s6-dns
+Software
+skarnet.org +

+ +

The problem with libresolv

+ +

+ The BIND name server software comes with its own client library, +named libresolv. +

+ +

+ As can be expected from an ISC product, libresolv is not good software. +Here are a few reasons why. +

+ +

libresolv's security model is flawed.

+ +

+ The same people who wrote BIND wrote libresolv. That is the amount of +trust you can place in libresolv. Ten years ago, the security status +of libresolv looked like +this. I am not +confident that is has improved: bugs in the software may have been +fixed, but new ones will appear, and most importantly, the security +management policy at ISC is still the same: security holes will be +denied instead of acknowledged and worked upon. +

+ +

+ If you find a bug, and a fortiori a security hole, in +s6-dns, you can be sure it will be fixed promptly with apologies +from the author. skarnet.org doesn't do obfuscation, and never lets +politics get in the way of technical quality. +

+ +

libresolv is unboundedly synchronous.

+ +

+ You'd expect a real DNS client library to do better in this aspect +than getaddrinfo(), but no: libresolv's +function calls are still purely synchronous and may uncontrollably +block if the network is unresponsive. +

+ +

+ Additionally, libresolv only provides a synchronous +interface to clients. Despite the fundamentally asynchronous nature +of DNS, and the need to implement asynchronous primitives +internally, only blocking calls are made available in the API. +This forces users to stack yet another piece of software on top +of their dependencies if they need asynchronous DNS resolution. +

+ +

+ libs6dns provides several layers of asynchronous interfaces. +The user has access to +low-level packet sending +and receiving, to +synchronous +resolution of several queries at once, and to a +real high-level asynchronous DNS library. +

+ +

It is too big for what it does.

+ +

+ The libresolv-2.13.so binary file compiled for an i386 +Debian Linux system is roughly 71k bytes. The libs6dns.so.2.0 +file, for the same system, is roughly 41k bytes, while offering +more functionality. libresolv does not do any high-level answer +parsing, so the user still has to do some work after the libresolv +calls. s6-dns tries to be small and still provide the user comfortable +interfaces. +

+ +

The API is cumbersome to use.

+ +

+ Some examples of less-than-ideal interfaces for the users: +

+ + + +

+ There is a reason why system calls and local functions take +user-supplied buffers as arguments. They are relatively fast, it is +not too costly to call them again if the buffer is too small the +first time, and the result is consistent, i.e. after the first call, +the right buffer length is known. But functions making +network exchanges with variable-length results from one call to +another ? Those need heap-allocated storage. It is +good design to avoid using the heap whenever possible, but it is +not good design to waste network round-trips to save a malloc(). +

+ +

Conclusion

+ +

+ Like many other "standards", and C library interfaces in particular, +libresolv is at best a mediocre one, that people use because +there has been nothing better so far. +

+ +

+ s6-dns tries to be an alternative solution - not as ambitious, +but based on solid design principles and a reliable code base. +

+ + + -- cgit v1.2.3