[ale] nsswitch and db option

[Michael H. Warfield]

On Tue, 2011-11-01 at 12:02 -0400, Chesser.Damon wrote: 
> I am trying to research the db option in nsswitch (as in: hosts:  db
> files  dns ).  We figure if a Linux client can use the dns cache for
> lookups, that would be faster then files or dns.  However, I can't find
> anybody who has ever used that option and google is slim pickens
> researching it.

I seriously doubt you'll find much improvement exploring the db option.
I'm also not aware of anyone who has ever used that option in
nsswitch.conf, either.  I'm not aware of any of the cachers that require
it.  The "db" option (according to some sources) is for Berkeley
Database formatted files (sendmail database files for example) and I'm
not sure that's what you are looking for.

If you already have a local DNS client cacher running (nscd, dnsmasq,
dnscache, or even a full bore instantiation of Bind running as a local
recursive caching name server) then just use the DNS option but then set
your /etc/resolve.conf file to be just "nameserver 127.0.0.1" to direct
all queries to the location cacher.  I do this quite often but the
primary reason I do it is not for speed but rather so I can directly
forward certain well known domains, or domains with specific "views" to
specific authoritative name servers and not go through the full
recursion / redirection process through the root.  Some cachers, such as
dnsmasq, even require that you specify a set of forwarders since they
may not have full recursion / redirection capability.

OTOH, while nscd CAN provide this functionality without monkeying with
resolv.conf (it caches a number of things at the API level) it can be,
apparently, unreliable and make be more trouble that what it's worth.
I've seen some very negative comments about nscd like this:

"If there is DNS caching in Hell, it is provided by nscd. Don't. Use. It."

There are other alternatives.  Personally, I like dnsmasq.  The
challenge there is just updating its configuration files if it's a
laptop away from home base.  While dhclient and Network Mangler will
update resolve.conf (which you do NOT want in this case) getting them to
update /etc/dnsmasq.d/default.conf is not going to happen without some
work under the hood (dhclient has scripting hooks but Network Manager /
Mangler insists it knows what you want better than you do and you can
just sod off).  Any API level cacher working through gethostent or
gethostbyname or whatever is probably better in the pure caching case
where you don't need static forwardings and you have road warriors
where /etc/resolv.conf is going to get screwed with (some VPNs do this
too, grrrr).  Either way, you don't need the db option and you don't
need to monkey with nsswitch.conf.

Regards,
Mike

> How do you access the (Linux) client dns cache info? Would "hosts:  db
> files dns" cause the first check to be performed on the dns cache?
> 
>  
> 
> If NOT what does "db" cause to happen?
> 
>  
> 
> Thanks!
> 
>  
> 
> Damon.chesser at suntrust.com 
>   
>   
>   
> LEGAL DISCLAIMER 
> The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. 
>   
> SunTrust is a federally registered service mark of SunTrust Banks, Inc. Live Solid. Bank Solid. is a service mark of SunTrust Banks, Inc. 
> [ST:XCL] 
>  
> 
> 
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20111101/ad610143/attachment.bin