Joshua Banks <[EMAIL PROTECTED]> writes: > Was this patch automatically applied when I emerged "djbdns" ??
Yes. It's part of the ebuild. > When I do a "qpkq -I -v" this patch isn't listed. I don't know what qpkg is or does. Sorry. > Wouldn't the above apply to how this is setup normally...regardless > of having a forwarding caching server setup > internally??... I.E..clients resolvers pointing to 2 upstream dns > servers. Yes, of course. Additionally the upstream servers get info about the number of your internal computers. > > Your dnscache gets the client requests, they are forwarded to your > > forward server that does the resolving. The answer is the cached by > > your dnscache and given to the client. > > There is one step too much here, isn't it? > > Not that I can see. Not sure what you mean.?? Dnscache does a good job in resolving itself. So there is no need to forward to another server (special setups may *require* forwarding, but not in your case). So you simply let dnscache talk to all required dns servers itself instead of asking for help at the ISP's servers (that's called forwarding). > > So you don't use the core function of dnscache. Maybe you confuse > > forwarding with resolving? > > Ummm. I don't know. I thought in my type of setup that its doing > both. No. Stock dnscache either does resolving or forwarding. With the fwdzone patch you control this on a per zone base. > I thought that when forwarding it was more or less acting like > a proxy on behalf of the clients that point to it. I think I can see your point of confusion. When talking about forwarding you mean the resolving that is done by dnscache on behalf of the stub resolvers at the clients. Explanation: nearly no clients contain a full blown resolver. They rely on a resolver that answers recursive queries. Such a resolver may be dnscache or the dns servers (caches/resolvers) at your ISP. But forwarding in context of dnscache means that dnscache doesn't do resolving - instead it relies on the resolver service of the ISP. > > > When I rebooted "svscan" didn't start at boot which I find a little > > > strange so I guess I need to add this to the default runlevel with > > > the "rc-update add svscan default". Sorry for the rant. > > > > This info is displayed when emerging daemontools, I think. But I may > > be wrong here. > > What info?? Hm. The info that "you have add svscan to your default runlevel"? > Forwarding must work because I have two internal clients that are > soley pointing their dns resolvers at my server that is running the > forwarding cache at 192.168.1.1. They get dns resolution so I would > have to assume that this is working correctly.... NO?? No. If dnscache does resolving itself, you have the setup that I recommended. This works too of course. To see what is going on look at your dnscache logfile. It contains the IP addresses that dnscache talks to (in hexadecimal format). Regards, Frank -- [EMAIL PROTECTED] mailing list
