On Thu, 18.06.15 07:57, Daurnimator ([email protected]) wrote: > On 18 Jun 2015 3:51 am, "Lennart Poettering" <[email protected]> wrote: > > > > On Wed, 17.06.15 19:48, Igor Bukanov ([email protected]) wrote: > > > > > On 17 June 2015 at 15:27, Lennart Poettering <[email protected]> > wrote: > > > > To hook up local name service > > > > clients people should use the "nss-resolve" NSS module, which ensures > > > > that gethostbyname() and friends use resolved as backend. > > > > > > I suppose then non-glibc clients should deal with that on its own. I > > > thought converting LLMNR into DNS would be a reasonable hack, but then > > > if the translation requires too much insanity, then indeed it is > > > better not to do that. > > > > If people use libraries to do DNS manually, then they'll do *DNS* > > manually, and we shouldn't interfere with that really. > > > > Usually people pick non-libc DNS libraries because they need async > > behaviour. I am pretty sure that's a pretty bad reason though and if > > you want async behaviour you should use sd-resolve or so. > > I've also used them because I > - need other record types (e.g. SRV)
res_query() can do that too, as part of libc. The bus API of resolved allows queriying that. But of course, we don't advertise that yet, and haven't even declared it stable. > - want to use DNSSEC It is our intention to add this to resolved soon. > - Want to choose between recursive and stub resolvers I am pretty sure recursive resolvers should be left to DNS servers. If all clients would start doing that, the whole caching scheme of DNS would be pointless... > FWIW, I use http://25thandclement.com/~william/projects/dns.c.html in many > projects. > It parses nsswitch.conf, but only cares about a few predetermined values. > Maybe it should gain some features in this area? I am not a fan of people doing things like that. In the long run I am pretty sure people should ask resolved. In the short run people should use libc's res_query() interface... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
