This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building consensus over DNSSEC enhancements to glibc.


----- Original Message -----
> From: "Florian Weimer" <fweimer@redhat.com>
> To: "Carlos O'Donell" <carlos@redhat.com>
> Cc: "Paul Wouters" <pwouters@redhat.com>, "Rich Felker" <dalias@libc.org>, "Simo Sorce" <simo@redhat.com>, "Petr
> Spacek" <pspacek@redhat.com>, libc-alpha@sourceware.org
> Sent: Thursday, November 19, 2015 3:24:28 PM
> Subject: Re: Building consensus over DNSSEC enhancements to glibc.

Hi Florian and others,

could anyone please give me a decent summary of what changed since my
last proposal[1]? I would like to get back into the discussion and I'm
willing to provide patches as I'm looking into glibc resolving code
pretty often anyway.

[1]: https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html

> On 11/19/2015 06:22 AM, Carlos O'Donell wrote:
> > Dare I say that systemd-resolved might solve some of this already?
> 
> Unfortunately, systemd-resolved caches far too aggressively and will
> poison its cache, even accidentally.  Various parties have tried to
> explain this to the upstream developers, but have not succeeded.
> systemd-resolved should be safe to run behind a BIND 9 recursive server
> in non-forwarding mode, but not much else (I believe even Unbound is
> unsafe due to its last-resort message handling).
> 
> systemd-resolved also does not handle exotic record types, I think, it
> is more an NSS-level solution than a libresolv-level solution.

Aha, that's an important information. I'm supporting both nss-style
forward/reverse resolution and DNS-style record resolution in netresolve[2]
and I was going to support systemd-resolved as one of the backends due
to its capability to resolve DNS, LLMNR and potentially other protocols
in parallel.

That means that to achieve the same I would either have to create my own
parallel-protocol name resolution backend or allow backend parallelization.

FYI, I'm now testing using netresolve[2] through libnss_netresolve as a
backend to glibc. On the other hand, glibc is not capable of using some
important netresolve features, but it is not even capable of using backends
for DNS resolution.

In netresolve[2] I do support both forward/reverse nss-style queries but also
DNS queries in the same way so that it's for example possible to provide
a file with DNS records similar to /etc/hosts used for forward/reverse queries.

[2]: https://sourceware.org/git/?p=netresolve.git;a=blob;f=README;hb=HEAD

Cheers,

Pavel

> (An earlier attempt in this direction is lwresd, which is part of BIND 9.)
> 
> Florian
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]