Generally the problem is that resolv.conf is quite limited and cannot
express
lot of things, like trust levels and per-domain forwarding (using different
servers for queries related to different domains).
One possibility how to solve this is to port applications to use different
library/API for name resolution but we have learn that this is not feasible
(recall the "everything to NSS" effort).
The NSS consolidation lessons don’t quite apply because the essential requirement of that
was “everything will use a single implementation” which is not actually a requirement in
this case: it is only “everything will talk to the correct same resolver and will have the
same assumptions about it being trusted for DNSSEC validation”. So one option you haven’t
mentioned is: Keep all the current resolver libraries and their APIs, but modify their
implementations to take their configuration from a different source; and have the local
unbound, if any, use /etc/resolf.conf (along with other configuration sources?).
If possible, this would be very nice in that it would allow us to keep /etc/resolv.conf as
the _administrator_-targeted configuration file where the external/forwarding DNS
resolvers are configured, while keeping the _internal implementation_-focused state
(availability and address of the trusted local resolver, an implementation detail of
DNSSEC rather than an administrator-visible configuration item) invisible/less visible to
administrators, and in fact not even a part of API of any of the resolver libraries, and
it would minimize users’ disruption. As it is now, we will end up with this weird
“configuration” file in /etc which looks like just any other configuration file except
this one is both _not_ user modifiable _and_ cannot be just removed.
From the various small code snippets in this thread and elsewhere it
seems that doing this would probably not be possible because the knowledge that
“/etc/resolv.conf is where I read which resolver to send packets to” has leaked from the
libraries to the applications, so merely patching resolvers would be insufficient. (And,
honestly, ABIs should be code interfaces and not file formats, so I will not mourn for
editable /etc/resolv.conf too much…)
But, well, just in case it were actually possible…
Mirek