Re: nscd: Was Re: long delays with LDAP nss/pam
also sprach Donovan Baarda [EMAIL PROTECTED] [2004.10.30.0447 +0200]: I prefer to run a caching dns server on one machine, and nscd on all the clients. In my case I'm using libnss-ldap on the clients so I kinda need to run it anyway. I thought so too, but with proper indexing on the server, you hardly notice the difference with or without now. I took it out again. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: nscd: Was Re: long delays with LDAP nss/pam
On Sat, 30 Oct 2004 12:47, Donovan Baarda [EMAIL PROTECTED] wrote: Seriously, does nscd really not correctly handle dns caching/expiry properly? I thought the dns caching stuff was well thought out and defined... not implementing it properly would be dumb. It's what I've been told. I haven't tested it myself. I don't think that it's that simple... I seem to be getting lookups for both of those. Are you sure you didn't just have smtp.sws.net.au in your hosts file? You are correct, I stuffed up that test. I think that ping is buggy in this regard. I think that it should just keep using the first DNS result that it gets, if the user wants ping to re-do the DNS lookups then they will press ^C and re-start it! Would you like to file the bug report or shall I? There may be reasons that it doesn't round robin DNS? Dynamic DNS flapping? dunno. I disagree, and I am not the only one, see the following URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109709 -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nscd: Was Re: long delays with LDAP nss/pam
On Thu, Oct 28, 2004 at 06:10:33PM +0200, martin f krafft wrote: also sprach Russell Coker [EMAIL PROTECTED] [2004.10.28.1520 +0200]: Run named on localhost. What an extraordinarily bad advice, IMHO. BIND is too much a piece of crap. I really suggest djbdns. I know, it's nonfree. But it's damn good. How is djbdns good? In that it doesn't correctly implement the RFCs on some crucial parts of the DNS protocol? (hint: search for 'AXFR' or 'IXFR', and see what mr. Bernstein has to say about that. No, rsync is /not/ a suitable protocol to synchronise DNS configuration!) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: nscd: Was Re: long delays with LDAP nss/pam
also sprach Wouter Verhelst [EMAIL PROTECTED] [2004.10.29.1112 +0200]: How is djbdns good? In that it doesn't correctly implement the RFCs on some crucial parts of the DNS protocol? (hint: search for 'AXFR' or 'IXFR', and see what mr. Bernstein has to say about that. No, rsync is /not/ a suitable protocol to synchronise DNS configuration!) Neither AXFR nor IXFR are crucial, and instead of your proof by assertion, would you care to tell me why rsync is not suitable? It works far better here. Anyway, with the confidence that boldly jumps out of your post, I am sure you know about axfrdns, which is part of djbdns. That provides AXFR but not IXFR. I have yet to see an implementation of IXFR that works. If you now way BIND, I am just going to laugh at you. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: nscd: Was Re: long delays with LDAP nss/pam
On Fri, Oct 29, 2004 at 12:04:51PM +0200, martin f krafft wrote: also sprach Wouter Verhelst [EMAIL PROTECTED] [2004.10.29.1112 +0200]: How is djbdns good? In that it doesn't correctly implement the RFCs on some crucial parts of the DNS protocol? (hint: search for 'AXFR' or 'IXFR', and see what mr. Bernstein has to say about that. No, rsync is /not/ a suitable protocol to synchronise DNS configuration!) Neither AXFR nor IXFR are crucial, and instead of your proof by assertion, would you care to tell me why rsync is not suitable? It assumes that all DNS servers use the same configuration format, or that all DNS servers in a given zone run the same software, which simply is an incorrect assumption. It works far better here. Anyway, with the confidence that boldly jumps out of your post, I am sure you know about axfrdns, which is part of djbdns. Well, no. Seems my information was out of date; but the IXFR part stands. That provides AXFR but not IXFR. I have yet to see an implementation of IXFR that works. If you now way BIND, I am just going to laugh at you. Well, go ahead then. But make sure you don't laugh too hard. Using BIND9, nsupdate, and domain keys, you have an IXFR implementation that is complete, secure (at least as secure as BIND itself and the key you're using), and that works: [EMAIL PROTECTED]:~$ dig ixfr=116 grep.be ; DiG 9.2.4 ixfr=116 grep.be ;; global options: printcmd grep.be.86400 IN SOA folk.grep.be. wouter.grep.be. 117 10800 3600 604800 86400 grep.be.86400 IN SOA folk.grep.be. wouter.grep.be. 116 10800 3600 604800 86400 grep.be.86400 IN SOA folk.grep.be. wouter.grep.be. 117 10800 3600 604800 86400 worldmusic.grep.be. 86400 IN A 192.168.119.10 grep.be.86400 IN SOA folk.grep.be. wouter.grep.be. 117 10800 3600 604800 86400 ;; Query time: 40 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Oct 29 15:03:35 2004 ;; XFR size: 5 records Yes, obviously this requires you to do some configuration first. So what? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: nscd: Was Re: long delays with LDAP nss/pam
On Fri, 29 Oct 2004 09:56, Donovan Baarda [EMAIL PROTECTED] wrote: I actually run pdnsd. I find it leaner and simpler than named. However, is run named on all hosts really better than run nscd on all hosts? That's debatable. Some people will say that DNS servers are too much of a security risk. However another issue is that nscd uses different cache algorithms to DNS servers and is likely to either give worse performance or less accurate results than using a DNS server. I have the gut feeling nscd is a lighter simpler and faster solution than named, but I could be wrong. Probably. But on a modern machine named takes so little resources that it doesn't matter (IMHO). Having named on localhost gives better performance than talking to another server while guaranteeing the same results (the other server is almost certainly running named). apps like squid that explicitly have it). If you ping, every single ping packet triggers an nslookup. Which ping program have you seen doing this? The ping program in iputils-ping I am using the ping from iputils-ping in sarge. It definitely does ns lookups for every packet... using iptraf to monitor traffic, I see the following repeated for every ping packet. Try pinging smtp.sws.net.au (my mail server) and www.coker.com.au (my web server). Note that the repeated reverse lookups only occur on www.coker.com.au, it seems that the repeated lookups only occur if forward and reverse DNS don't match (but I haven't checked the source code to verify this). You are correct that it does repeated DNS lookups in some situations. The first test case that I chose happened to be one that it does not do such lookups for. This is when I first noticed this behaviour... ping was taking ~10secs between each ping packet... it turns out waiting for nslookups to time out before trying the second nameserver between each ping. I think that ping is buggy in this regard. I think that it should just keep using the first DNS result that it gets, if the user wants ping to re-do the DNS lookups then they will press ^C and re-start it! Would you like to file the bug report or shall I? Is there any reason why nscd should not be installed on a system? It wastes RAM on small machines. Caches get stale some times. It's one more thing that can go wrong or have a security issue. Most people don't need it. but does running named instead really avoid all these issues, or make them worse? If there was a choice between running only nscd or only named then nscd might be a reasonable option. But given that every serious network will need a caching DNS proxy (for which task it's unfortunate that there is nothing better than BIND) it doesn't seem to be a problem to me that you run it on several machines instead of just one. If you have only a single machine connected to an ISP then maybe nscd will be the best choice. However that scenario is becoming increasingly rare. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nscd: Was Re: long delays with LDAP nss/pam
also sprach Wouter Verhelst [EMAIL PROTECTED] [2004.10.29.1508 +0200]: It assumes that all DNS servers use the same configuration format, or that all DNS servers in a given zone run the same software, which simply is an incorrect assumption. It has suited me just fine. I am thankful that djbdns provides me with a strong basis upon which I can converge. axfrdns additionally offers zone transfers to AXFR servers, and scripts exist to convert AXFR transfers to djbdns format. If you've ever seen the djbdns config file format, you aren't going back. Or are you going to argue that BIND zone files are intuitive, not error-prone, and easy to manage? Using BIND9, nsupdate, and domain keys, you have an IXFR implementation that is complete, secure (at least as secure as BIND itself and the key you're using), and that works: My last status was that the encryption used was not much better than MIME64. I may well be wrong. Yes, obviously this requires you to do some configuration first. So what? Well, I have better things to do. No, I don't want a flame war, so please don't reply. You use BIND, I used djbdns, makes two happy people. In any case, please don't advocate to run BIND to everyone. Too much can go wrong. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: nscd: Was Re: long delays with LDAP nss/pam
G'day, From: Russell Coker [EMAIL PROTECTED] On Fri, 29 Oct 2004 09:56, Donovan Baarda [EMAIL PROTECTED] wrote: I actually run pdnsd. I find it leaner and simpler than named. However, is run named on all hosts really better than run nscd on all hosts? That's debatable. Some people will say that DNS servers are too much of a security risk. However another issue is that nscd uses different cache algorithms to DNS servers and is likely to either give worse performance or less accurate results than using a DNS server. I'd say that sounds like a bug in nscd :-) Seriously, does nscd really not correctly handle dns caching/expiry properly? I thought the dns caching stuff was well thought out and defined... not implementing it properly would be dumb. Try pinging smtp.sws.net.au (my mail server) and www.coker.com.au (my web server). Note that the repeated reverse lookups only occur on www.coker.com.au, it seems that the repeated lookups only occur if forward and reverse DNS don't match (but I haven't checked the source code to verify [...] I don't think that it's that simple... I seem to be getting lookups for both of those. Are you sure you didn't just have smtp.sws.net.au in your hosts file? This is when I first noticed this behaviour... ping was taking ~10secs between each ping packet... it turns out waiting for nslookups to time out before trying the second nameserver between each ping. I think that ping is buggy in this regard. I think that it should just keep using the first DNS result that it gets, if the user wants ping to re-do the DNS lookups then they will press ^C and re-start it! Would you like to file the bug report or shall I? There may be reasons that it doesn't round robin DNS? Dynamic DNS flapping? dunno. If there was a choice between running only nscd or only named then nscd might be a reasonable option. But given that every serious network will need a caching DNS proxy (for which task it's unfortunate that there is nothing better than BIND) it doesn't seem to be a problem to me that you run it on several machines instead of just one. If you have only a single machine connected to an ISP then maybe nscd will be the best choice. However that scenario is becoming increasingly rare. I prefer to run a caching dns server on one machine, and nscd on all the clients. In my case I'm using libnss-ldap on the clients so I kinda need to run it anyway. The other reason either a caching dns or nscd is a better idea than multiple nameservers in resolve.conf is the timeout waits on every lookup when the first nameserver is down. Donovan Baardahttp://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nscd: Was Re: long delays with LDAP nss/pam
On Wed, 27 Oct 2004 18:07, Donovan Baarda [EMAIL PROTECTED] wrote: Sorry to subvert a thread like this, but has anyone else decided that nscd is pretty much essential for all systems, regardless of nss, or local nameservers? No. It seems without it there is _no_ dns caching of any kind (except for Run named on localhost. apps like squid that explicitly have it). If you ping, every single ping packet triggers an nslookup. Which ping program have you seen doing this? The ping program in iputils-ping only does a DNS lookup before sending the first packet and I expect that all other ping programs do the same. Run tcpdump while running ping and check what your ping program does. Even if you have a local caching name server, the UDP traffic on the loopback interface hurts. How does UDP traffic on the loopback hurt more than Unix domain socket access? Is there any reason why nscd should not be installed on a system? It wastes RAM on small machines. Caches get stale some times. It's one more thing that can go wrong or have a security issue. Most people don't need it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nscd: Was Re: long delays with LDAP nss/pam
also sprach Russell Coker [EMAIL PROTECTED] [2004.10.28.1520 +0200]: Run named on localhost. What an extraordinarily bad advice, IMHO. BIND is too much a piece of crap. I really suggest djbdns. I know, it's nonfree. But it's damn good. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
RE: nscd: Was Re: long delays with LDAP nss/pam
I've will agree with this whole heartedly. I've moved to using local dnscaches on most my smtp servers, and webservers that do DNSLookups with my network network dnscache acting as a root server for them. DNS traffic to and from my network has significantly dropped, along with request to my network caches. Just have to flush them every once in a while when I'm working on DNS. plug Admittedly it took a little while for me to get used to djbdns, but with djbdns + VegaDNS(http://www.vegadns.org/) by Bill Shupp I spend very little time on DNS related requests/problems. The changeover from bind only took me 3 days, and everything has been up and running without trouble since. I've even been able to offload dns management for my colo clients through VegaDNS. /plug .darrel. -Original Message- From: martin f krafft [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 12:11 PM To: [EMAIL PROTECTED] Subject: Re: nscd: Was Re: long delays with LDAP nss/pam also sprach Russell Coker [EMAIL PROTECTED] [2004.10.28.1520 +0200]: Run named on localhost. What an extraordinarily bad advice, IMHO. BIND is too much a piece of crap. I really suggest djbdns. I know, it's nonfree. But it's damn good. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! -- Incoming mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.269 / Virus Database: 264.12.4 - Release Date: 10/27/2004 -- Outgoing mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.269 / Virus Database: 264.12.4 - Release Date: 10/27/2004
Re: nscd: Was Re: long delays with LDAP nss/pam
G'day, From: Russell Coker [EMAIL PROTECTED] On Wed, 27 Oct 2004 18:07, Donovan Baarda [EMAIL PROTECTED] wrote: Sorry to subvert a thread like this, but has anyone else decided that nscd is pretty much essential for all systems, regardless of nss, or local nameservers? No. It seems without it there is _no_ dns caching of any kind (except for Run named on localhost. I actually run pdnsd. I find it leaner and simpler than named. However, is run named on all hosts really better than run nscd on all hosts? I have the gut feeling nscd is a lighter simpler and faster solution than named, but I could be wrong. apps like squid that explicitly have it). If you ping, every single ping packet triggers an nslookup. Which ping program have you seen doing this? The ping program in iputils-ping I am using the ping from iputils-ping in sarge. It definitely does ns lookups for every packet... using iptraf to monitor traffic, I see the following repeated for every ping packet. ICMP echo req (84 bytes) from 192.168.2.33 to 203.12.237.50 on eth1 ICMP echo rply (84 bytes) from 203.12.237.50 to 192.168.2.33 on eth1 UDP (72 bytes) from 127.0.0.1:54815 to 127.0.0.1:53 on lo UDP (72 bytes) from 127.0.0.1:54815 to 127.0.0.1:53 on lo UDP (188 bytes) from 127.0.0.1:53 to 127.0.0.1:54815 on lo UDP (188 bytes) from 127.0.0.1:53 to 127.0.0.1:54815 on lo ICMP echo req (84 bytes) from 192.168.2.33 to 203.12.237.50 on eth1 ICMP echo rply (84 bytes) from 203.12.237.50 to 192.168.2.33 on eth1 UDP (72 bytes) from 127.0.0.1:54815 to 127.0.0.1:53 on lo UDP (72 bytes) from 127.0.0.1:54815 to 127.0.0.1:53 on lo UDP (188 bytes) from 127.0.0.1:53 to 127.0.0.1:54815 on lo UDP (188 bytes) from 127.0.0.1:53 to 127.0.0.1:54815 on lo Note you only see this when you ping hosts not found in your /etc/hosts file (obviously). If you don't have a local name server, this triggers remote nslookups. Even worse, if you have multiple remote nameservers in your resolve.conf, and the first is down, It waits for the first nslookup to time-out before trying the second... for _every_ lookup. This is when I first noticed this behaviour... ping was taking ~10secs between each ping packet... it turns out waiting for nslookups to time out before trying the second nameserver between each ping. only does a DNS lookup before sending the first packet and I expect that all other ping programs do the same. Run tcpdump while running ping and check what your ping program does. see above... Even if you have a local caching name server, the UDP traffic on the loopback interface hurts. How does UDP traffic on the loopback hurt more than Unix domain socket access? Unix domain socket access doesn't show up in iptraf? :-) I would have though that since nscd hooks in at the libc level, it would be more efficient... again unfounded speculation on my part... Is there any reason why nscd should not be installed on a system? It wastes RAM on small machines. Caches get stale some times. It's one more thing that can go wrong or have a security issue. Most people don't need it. but does running named instead really avoid all these issues, or make them worse? Donovan Baardahttp://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nscd: Was Re: long delays with LDAP nss/pam
also sprach Darrel O'Pry [EMAIL PROTECTED] [2004.10.29.0133 +0200]: I've even been able to offload dns management for my colo clients through VegaDNS. Unfortunately, it's PHP and thus not an option for anyone with a tad bit of a security concern. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
nscd: Was Re: long delays with LDAP nss/pam
On Wed, 2004-10-27 at 17:55, Donovan Baarda wrote: [...] nscd stopped running? Sorry to subvert a thread like this, but has anyone else decided that nscd is pretty much essential for all systems, regardless of nss, or local nameservers? It seems without it there is _no_ dns caching of any kind (except for apps like squid that explicitly have it). If you ping, every single ping packet triggers an nslookup. Even if you have a local caching name server, the UDP traffic on the loopback interface hurts. If you don't have a local dns cache, it really hurts. Is there any reason why nscd should not be installed on a system? -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nscd: Was Re: long delays with LDAP nss/pam
also sprach Donovan Baarda [EMAIL PROTECTED] [2004.10.27.1007 +0200]: Is there any reason why nscd should not be installed on a system? It's often a pain to use if you make frequent changes? It's got a weird caching policy that I can't seem to control the way I interpret it? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: nscd: Was Re: long delays with LDAP nss/pam
On Wed, 27 Oct 2004, martin f krafft wrote: also sprach Donovan Baarda [EMAIL PROTECTED] [2004.10.27.1007 +0200]: Is there any reason why nscd should not be installed on a system? It's often a pain to use if you make frequent changes? It's got a weird caching policy that I can't seem to control the way I interpret it? It causes security headaches as well, because you never know when it got a stale cache? If you don't need it, don't use it. The same goes for lwresd, and other caches. Although lwresd at least expires things in a predictable way (i.e. it follows the DNS caching times). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
