nscd dns caching

[Yarisken]

Hallo,

Ik heb net gemerkt dat mijn linux servers geen dns caching doen. Ik heb gelezen dat je hiervoor nscd, bind of andere kan installeren. Nscd lijkt me het meest geschikt.
Is er een reden waarom ik dit niet zou installeren ?
We gebruiken redhat servers zonder gui.

[Ploink]

Ik denk dat er weinig redenen zijn om het niet te doen. Misschien levert het weinig winst als de upstream DNS heel snel reageert of misschien kan het soms voor extra vertraging zorgen in DNS record updates.

Gewoon doen dus, nscd is geschikt.
Bind is een complete dns server, maar als je dat nodig hebt zijn er betere alternatieven.
Jaren geleden heb ik bind de deur uit gegooid en vervangen door dnsmasq welke ook eigen dhcp en tftp servers integreert. Integratie van bind met dhcpd was een ramp.

[Yarisken]

Ok thx, dan installeer ik het gewoon op al mijn servers.

[Cidolfas]

Yarisken schreef op woensdag 11 september 2013 @ 15:26:
Ok thx, dan installeer ik het gewoon op al mijn servers.

Ik zou toch iets terughoudend zijn met het inzetten van nscd. Default doet het namelijk meer dan alleen dns caching, als je ldap gebruikt zitten ook je uids er in wat voor problemen kan zorgen.

Persoonlijk ben ik geen fan van nscd, het is in latere versies van RedHat ook vervangen door iets anders (sssd uit mijn hoofd..).

Weer voorzichtig in productie omgevingen met nscd en test wat bijvoorbeeld het uitvallen van ldap met je servers doet. Ik heb ervaringen dat lokale users (root) ook niet meer naar binnen mochten.

[Verwijderd]

Cidolfas schreef op zaterdag 14 september 2013 @ 11:53:

Ik zou toch iets terughoudend zijn met het inzetten van nscd. Default doet het namelijk meer dan alleen dns caching, als je ldap gebruikt zitten ook je uids er in wat voor problemen kan zorgen.

Persoonlijk ben ik geen fan van nscd, het is in latere versies van RedHat ook vervangen door iets anders (sssd uit mijn hoofd..).

Weer voorzichtig in productie omgevingen met nscd en test wat bijvoorbeeld het uitvallen van ldap met je servers doet. Ik heb ervaringen dat lokale users (root) ook niet meer naar binnen mochten.

Ik heb er de ervaring mee dat men dan juist nog wél in kon loggen als een LDAP server niet bereikbaar was. Maar goed, ik heb dan ook wél de servers goed geconfigureerd.

Overigens is jouw ervaring dat lokale gebruikers niet meer konden inloggen niet veroorzaakt door nscd maar door Linux PAM. Bij een goed geconfigureerde server worden user accounts opgezocht via /etc/nsswitch.conf, waarin wordt geconfigureerd dat gebruikers eerst lokaal worden opgezocht, en als dat lukt dat er niet naar LDAP wordt gekeken.
Linux PAM zit iets anders in elkaar, en er zijn veel meer keuzes om te maken. Je kunt het zo configureren dat lokale users prima zijn en dat er dan verder niet meer gekeken wordt. Dat stel je op Red Hat achtige systemen in met authconfig of authconfig-tui, en kijk dan met name naar de --enablelocauthorize en --enablesysnetauth (enigszins gevaarlijk) opties. En realiseer je dat dat simpelweg wordt vertaald naar configuratieregels in /etc/pam.d/ en dat er nog veel meer mogelijk is.

Ik vind het prima dat je ergens voor waarschuwt, maar ik hoop dat je nu inziet dat het wellicht aan jouw gebrek aan kennis en ervaring lag. En wat dat betreft kan ik alleen maar adviseren om even iets te gaan lezen over /etc/nsswitch.conf en Linux PAM.

Ik ben wél een fan van nscd, nslcd en niet van sssd. Wel moet je als je caching deamons gebruikt realiseren dat je bij problemen even je cache moet opschonen om zeker te weten dat je niet met een verkeerde entry in je cache zit. Ik heb overigens enkele malen meegemaakt dat er een verkeerde host entry in nscd zat en dat alleen op was te lossen met een restart van nscd, maar dat was zeer zeldzaam en ik heb het destijds niet verder uitgezocht.

[Cidolfas]

Verwijderd schreef op zaterdag 14 september 2013 @ 12:10:
[...]

Ik heb er de ervaring mee dat men dan juist nog wél in kon loggen als een LDAP server niet bereikbaar was. Maar goed, ik heb dan ook wél de servers goed geconfigureerd.

Overigens is jouw ervaring dat lokale gebruikers niet meer konden inloggen niet veroorzaakt door nscd maar door Linux PAM. Bij een goed geconfigureerde server worden user accounts opgezocht via /etc/nsswitch.conf, waarin wordt geconfigureerd dat gebruikers eerst lokaal worden opgezocht, en als dat lukt dat er niet naar LDAP wordt gekeken.
Linux PAM zit iets anders in elkaar, en er zijn veel meer keuzes om te maken. Je kunt het zo configureren dat lokale users prima zijn en dat er dan verder niet meer gekeken wordt. Dat stel je op Red Hat achtige systemen in met authconfig of authconfig-tui, en kijk dan met name naar de --enablelocauthorize en --enablesysnetauth (enigszins gevaarlijk) opties. En realiseer je dat dat simpelweg wordt vertaald naar configuratieregels in /etc/pam.d/ en dat er nog veel meer mogelijk is.

Ik vind het prima dat je ergens voor waarschuwt, maar ik hoop dat je nu inziet dat het wellicht aan jouw gebrek aan kennis en ervaring lag. En wat dat betreft kan ik alleen maar adviseren om even iets te gaan lezen over /etc/nsswitch.conf en Linux PAM.

Ik ben wél een fan van nscd, nslcd en niet van sssd. Wel moet je als je caching deamons gebruikt realiseren dat je bij problemen even je cache moet opschonen om zeker te weten dat je niet met een verkeerde entry in je cache zit. Ik heb overigens enkele malen meegemaakt dat er een verkeerde host entry in nscd zat en dat alleen op was te lossen met een restart van nscd, maar dat was zeer zeldzaam en ik heb het destijds niet verder uitgezocht.

De aannames in je lange antwoord zijn redelijk lachwekkend. Niet alleen denk je te weten wat in mijn omgeving precies het probleem was, je weet ook nog wat te vertellen over mijn kennis betreffende Linux! !

Met zo'n instelling kom je er wel...

Destijds is het probleem wat ik had overigens gefixed in een errata van nscd, was nog op RHEL3 uit m'n hoofd.

Mijn boodschap was meer dat je deze wijziging in je infrastructuur goed moet overwegen en testen en niet gewoon "even aan moet zettten".

Maar daar las je vast over heen terwijl je bezig was te bedenken hoe dom ik wel niet ben en hoe jij alles beter weet.

[magistus]

Ugh, nscd. Als je het niet hoeft te gebruiken, niet doen. Zeker hiervoor, gewoon bind oid als caching only nameserver inzetten. Veel betrouwbaarder, zeker als je alleen DNS nodig hebt, en scheelt je weer vreemde memory leaks....

[Yarisken]

magistus schreef op dinsdag 17 september 2013 @ 16:00:
Ugh, nscd. Als je het niet hoeft te gebruiken, niet doen. Zeker hiervoor, gewoon bind oid als caching only nameserver inzetten. Veel betrouwbaarder, zeker als je alleen DNS nodig hebt, en scheelt je weer vreemde memory leaks....

Damn man wat moet ik nu :-). Dacht ok leuk nscd gebruiken. Geen probleem, gewoon wat cachen van dns en klaar. Nu spreken jullie hierover memory leaks .

[Ploink]

Ik zou je gewoon houden aan de standaard oplossing voor jouw specifieke distro, dat zal wel goed getest zijn.

[Cidolfas]

Yarisken schreef op woensdag 18 september 2013 @ 13:13:
[...]


Damn man wat moet ik nu :-). Dacht ok leuk nscd gebruiken. Geen probleem, gewoon wat cachen van dns en klaar. Nu spreken jullie hierover memory leaks .

Dat kan ook, maar ik zou er wel even over nadenken wat nscd default nog meer doet (dat kan per distributie verschillen) en of het past binnen je infrastructuur.

Zoals gezegd ben ik persoonlijk geen fan van nscd, mede door de vele problemen die er over te vinden zijn en welke ik zelf ook heb ervaren. Daarentegen wordt het door de meeste distributies gewoon ondersteund, dus je zou support kunnen verwachten mocht je tegen problemen aanlopen.

Als er geen noodzaak is zou ik het niet gebruiken "voor de leuk", maar dat geldt voor alle componenten op een productie systeem.

[_JGC_]

Op zich is nscd geen probleem, maar als je door uitval van je LDAP server dus een failed lookup cached, blijft die gebruiker niet bestaand totdat je nscd z'n cache leeggooit.

Ik heb nscd even nagekeken op een server waar ik het gebruik, maar Debian zet standaard de hosts cache uit. Dit vanwege bug http://sourceware.org/bugzilla/show_bug.cgi?id=4428

maw: je wilt nscd dus niet gebruiken voor DNS caching, kan je beter een lokale DNS recursor opzetten. Kan bind zijn, kan dnsmasq zijn, kan evt pdns-recursor zijn. Die laatste is mijn favoriet, maar is vooral omdat ik alle nameservers op PowerDNS heb draaien.

[deadinspace]

Heb je überhaupt iets aan DNS caching? Doet je hosting provider misschien niet al aan DNS caching?

[_JGC_]

Hangt ervan af wat je gaat cachen. Als je op een mailserver RBL lookups doet wil je gewoon een lokale recursor met caching die de TTL in acht houdt, dan wil je niet de DNS server van je ISP overbelasten en ervan uitgaan dat die de TTL juist respecteert.

[Yarisken]

deadinspace schreef op donderdag 19 september 2013 @ 11:20:
Heb je überhaupt iets aan DNS caching? Doet je hosting provider misschien niet al aan DNS caching?

Ik zie nu soms enorm veel requests van onze applicatieservers en andere naar onze interne dns. Wij werken standaard altijd met dns-namen voor onze applicaties op de servers.
Caching zou de load van het netwerk verminderen, nu niet dat dit een probleem is op dit moment maar het lijkt me toch properder :-).

[Hero of Time]

Caching kan helpen je load te beperken, maar als er een DNS record wijzigt, duurt het ook langer voordat 't in je cache staat. Net zo lang als de cache bewaart wordt namelijk. Afhankelijk van hoe vaak dat gebeurt, kan je besluiten of je dat risico wilt lopen, of liever een wat hogere load ziet op je DNS server.

[Yarisken]

Hero of Time schreef op vrijdag 20 september 2013 @ 09:48:
Caching kan helpen je load te beperken, maar als er een DNS record wijzigt, duurt het ook langer voordat 't in je cache staat. Net zo lang als de cache bewaart wordt namelijk. Afhankelijk van hoe vaak dat gebeurt, kan je besluiten of je dat risico wilt lopen, of liever een wat hogere load ziet op je DNS server.

Idd maar het flushen van de cache moet ook wel snel gaan hé. Bij nscd is dat de service herstarten.

[Hero of Time]

Owja, daar had ik even niet aan gedacht

[Wolfboy]

Persoonlijk zou ik gewoon voor Bind gaan en voor de relevante domeinen die servers als secondary master servers markeren zodat ze de updates gewoon direct doorgestuurd krijgen. Dan heb je ook geen gezeur met dns cache die out of date is.

[Cidolfas]

Yarisken schreef op vrijdag 20 september 2013 @ 13:21:
[...]


Idd maar het flushen van de cache moet ook wel snel gaan hé. Bij nscd is dat de service herstarten.

Dat zou je verwachten ja. Mijn ervaring is echter dat dat niet altijd het geval is. Je kan in dat geval een flush forceren met de invalidate optie:

code:

# nscd -i hosts

[Rainmaker]

Nog even een vraagje voor de TS; behalve DNS, kan nscd ook meer dingen cachen (zoals in dit topic al aangegeven).

Wordt er binnen de omgeving uberhaupt gebruik gemaakt van dingen als LDAP of NIS? Je kunt nscd overigens ook zo configureren dat alleen DNS gecached wordt met
enable-cache <service> no
voor alle services behalve "hosts"

Door een lage TTL timeout (zowel positieve als negatieve cache timouts) te geven, kun je ook "voorkomen" (nou ja, redelijk voorkomen) dat je de cache zeer regelmatig moet flushen.

Ik heb nscd redelijk veel gebruikt in een grote server omgeving (voornamelijk redhat). Op Linux zelden problemen mee gezien (qua memory leaks e.d.) Kijk wel uit als je nscd op HP-UX wil installeren, daar heb ik het in de praktijk nog wel wat problemen zien geven.

Overigens heb ik met hetzelfde zitten stoeien met het "lokaal inloggen gaat voor LDAP". Is een irritant probleem. Na 2 dagen met 2 man de PAM config door te spitten, vonden we de "juiste" configuratie voor de omgeving. Het lijkt zo simpel; nssswitch passwd: files ldap, maar dat is dus niet genoeg.

Authconfig vernaggelde de configuratie dusdanig dat er via de ILO nog net een shell los te peuteren was. Maar dat was ook de 1e en laatste keer dat ik authconfig probeerde.

[Yarisken]

Rainmaker schreef op zondag 22 september 2013 @ 03:39:
Nog even een vraagje voor de TS; behalve DNS, kan nscd ook meer dingen cachen (zoals in dit topic al aangegeven).

Wordt er binnen de omgeving uberhaupt gebruik gemaakt van dingen als LDAP of NIS? Je kunt nscd overigens ook zo configureren dat alleen DNS gecached wordt met
enable-cache <service> no
voor alle services behalve "hosts"

Door een lage TTL timeout (zowel positieve als negatieve cache timouts) te geven, kun je ook "voorkomen" (nou ja, redelijk voorkomen) dat je de cache zeer regelmatig moet flushen.

Ik heb nscd redelijk veel gebruikt in een grote server omgeving (voornamelijk redhat). Op Linux zelden problemen mee gezien (qua memory leaks e.d.) Kijk wel uit als je nscd op HP-UX wil installeren, daar heb ik het in de praktijk nog wel wat problemen zien geven.

Overigens heb ik met hetzelfde zitten stoeien met het "lokaal inloggen gaat voor LDAP". Is een irritant probleem. Na 2 dagen met 2 man de PAM config door te spitten, vonden we de "juiste" configuratie voor de omgeving. Het lijkt zo simpel; nssswitch passwd: files ldap, maar dat is dus niet genoeg.

Authconfig vernaggelde de configuratie dusdanig dat er via de ILO nog net een shell los te peuteren was. Maar dat was ook de 1e en laatste keer dat ik authconfig probeerde.

Hey, het zou ook gebruikt worden op redhat en we gaan het enkel gebruiken voor dns hostcaching. Dus geen ldap of andere.

[Verwijderd]

Yarisken schreef op maandag 23 september 2013 @ 16:36:

Hey, het zou ook gebruikt worden op redhat en we gaan het enkel gebruiken voor dns hostcaching. Dus geen ldap of andere.

Dan moet je dat configureren, want standaard worden alle passwd, group en shadow services entries ook gecached. Dat kun je in /etc/nscd.conf aanpassen.

Is je netwerk zo traag dat je niet gebruik kunt maken van de cache van je recursive nameserver? Of doe je zo verdomd veel lookups dat je er echt bij gebaat bent?

[ Voor 1% gewijzigd door Verwijderd op 23-09-2013 19:12 . Reden: Geen shadow, duh... ]

[Yarisken]

Verwijderd schreef op maandag 23 september 2013 @ 19:09:
[...]

Dan moet je dat configureren, want standaard worden alle passwd, group en shadow entries ook gecached. Dat kun je in /etc/nscd.conf aanpassen.

Is je netwerk zo traag dat je niet gebruik kunt maken van de cache van je recursive nameserver? Of doe je zo verdomd veel lookups dat je er echt bij gebaat bent?

Er gaan enorm veel lookups over het netwerk. Niet dat we hierdoor problemen hebben ofzo maar ik hou alles graag proper.
Ok thx voor de tip, ik ga nscd dan is bekijken.