I'm trying to settle on a (Linux) caching stub resolver configuration
and looking at lwresd, but it's not working as I expect for validation.
Given an lwresd.conf of:
-=-
options {
forwarders { 192.168.125.1; };
forward only;
dnssec-enable yes;
dnssec-validation auto;
};
lwres {};
-=-
Clients (via libnss-lwres) can unexpectedly resolve
www.dnssec-failed.org. The forwarder (192.168.125.1) is a validating
bind instance, but lwresd is sending queries with the CD flag set,
though it then doesn't follow up by doing any validation locally. I can
force lwresd to not set the CD flag with an additional:
-=-
server 192.168.125.1 {
edns no;
};
-=-
and then the SERVFAIL for dnssec-failed.org from the bind instance does
propagate down to the client, but this all feels a bit guess-worky.
I'd really appreciate any input from people who have deployed lwresd or
a different stub resolver. From scraping around the web, I detect that
lwresd isn't widely used. Should I just use 'full' named everywhere?
systemd-resolved makes too many assumptions to be in with much of a
chance, and nscd holds unhappy memories.
Graham
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
