> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
