stub resolver (lwresd?)

Graham Clinch g.clinch at lancaster.ac.uk
Sun Apr 17 23:20:56 UTC 2016


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


More information about the bind-users mailing list