Un-deprecating nss_hesiod?

Un-deprecating nss_hesiod?

[JFLF]

Dear all,

Apologies for not participating last July when that topic was brought up, but I don't follow the glibc development closely.

From what I could find, the deprecation of nss_hesiod was justified with the following message:

> Storing user databases in DNS, without client-side DNSSEC validation,
> is problematic from a security point of view.

This is a very valid concern, but hasn't DNSSEC been implemented in the glibc resolver in 2019? If so, doesn't that make this point moot?

Moreover, even without this Hesiod traffic can be secured to the clients via a local DNSSEC-validating forwarder, DNS-over-TLS or -HTTPS, etc. Thus the solutions to the lack of security of Hesiod (which it inherits from DNS) have existed for a while, and the responsibility for deploying them rests with the admin (just like LDAP). Unsecured Hesiod isn't less secure than the alternatives (NIS or unsecured LDAP), which haven't been deprecated.

I am aware that RedHat has deprecated Hesiod in RHEL 7, possibly for support reasons. But there is still a small community of people using Hesiod, and a lot of small deployments and use cases for which the complexity of LDAP isn't justified. Also, if you based your decision on the lack of bug reports about Hesiod, you should rejoice: it just works! Nss_hesiod works perfectly fine.

So as long as it doesn't affect anything else, may I ask you to consider un-deprecating nss_hesiod?

Thanks!
JF

Re: Un-deprecating nss_hesiod?

[Florian Weimer]

* JFLF via Libc-alpha:

> This is a very valid concern, but hasn't DNSSEC been implemented in
> the glibc resolver in 2019? If so, doesn't that make this point moot?

The glibc stub resolver is still non-validating.

> So as long as it doesn't affect anything else, may I ask you to
> consider un-deprecating nss_hesiod?

NSS is a plug-in framework.  There is no requirement that NSS service
modules are built as part of glibc.

Would you be interested in taking the nss_hesiod sources and maintaining
them outside of the glibc source tree?  Then nss_hesiod might even be
able to reuse parts of the (already separate) hesiod library.

Once that separate project exist, we can remove nss_hesiod from the
glibc source tree.

Thanks,
Florian

Re: Un-deprecating nss_hesiod?

[JFLF]

Hi Florian,

Thank you for your answer.

On 01/03/2021 12.39, Florian Weimer wrote:
> * JFLF via Libc-alpha:
> 
>> This is a very valid concern, but hasn't DNSSEC been implemented in
>> the glibc resolver in 2019? If so, doesn't that make this point moot?
> 
> The glibc stub resolver is still non-validating.
> 
>> So as long as it doesn't affect anything else, may I ask you to
>> consider un-deprecating nss_hesiod?
> 
> NSS is a plug-in framework.  There is no requirement that NSS service
> modules are built as part of glibc.
> 
> Would you be interested in taking the nss_hesiod sources and maintaining
> them outside of the glibc source tree?  Then nss_hesiod might even be
> able to reuse parts of the (already separate) hesiod library.

I might look into this at some point. Due to other commitments it won't
be at any time in the near future, though. Hopefully someone else will
step up before then.

Thanks!
JF

> Once that separate project exist, we can remove nss_hesiod from the
> glibc source tree.
> 
> Thanks,
> Florian
> 

Re: Un-deprecating nss_hesiod?

[Rich Felker]

On Mon, Mar 01, 2021 at 12:39:50PM +0100, Florian Weimer via Libc-alpha wrote:
> * JFLF via Libc-alpha:
> 
> > This is a very valid concern, but hasn't DNSSEC been implemented in
> > the glibc resolver in 2019? If so, doesn't that make this point moot?
> 
> The glibc stub resolver is still non-validating.

And everyone needs to be running a dnssec-validating (which gives you
caching for free, too) nameserver on localhost. Validation does not
belong in glibc, but glibc should be pushing distros to ship with a
default, out of the box configuration that makes this safe unless the
user explicitly overrides/refuses it.

Rich

Re: Un-deprecating nss_hesiod?

[Zack Weinberg]

On Thu, Mar 4, 2021 at 9:55 AM Rich Felker <dalias@libc.org> wrote:
> On Mon, Mar 01, 2021 at 12:39:50PM +0100, Florian Weimer via Libc-alpha wrote:
> > * JFLF via Libc-alpha:
> >
> > > This is a very valid concern, but hasn't DNSSEC been implemented in
> > > the glibc resolver in 2019? If so, doesn't that make this point moot?
> >
> > The glibc stub resolver is still non-validating.
>
> And everyone needs to be running a dnssec-validating (which gives you
> caching for free, too) nameserver on localhost. Validation does not
> belong in glibc, but glibc should be pushing distros to ship with a
> default, out of the box configuration that makes this safe unless the
> user explicitly overrides/refuses it.

With the caveat that I think there are several use cases where the
application needs access to validation details and not just the "trust
me I validated this" bit, fully agreed.  unbound is easy to set up,
there's no reason not to have validation active by default.

zw