Feature request - disable internal recursion cache

2009-10-30 Thread Dmitry Rybin
Hello everybody! I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :(

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Niall O'Reilly
Dmitry Rybin wrote: Hello everybody! I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( I don't

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Dmitry Rybin
Niall O'Reilly wrote: I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( I don't see the point.

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Kevin Darcy
Dmitry Rybin wrote: Niall O'Reilly wrote: I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( I don't see

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Kevin Darcy
Dmitry Rybin wrote: Hello everybody! I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :(

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Michael Hare
For those of us that are still running auth and recursive on the same IP, I believe the benefit would be to deploy a best practices recursive only nameserver on a different machine/IP address without getting, in my case, possibly hundreds of thousands of clients to change their DNS resolver IP

9.6.1-P1 zone parser false errors

2009-10-30 Thread Len Conrad
uname -a Linux ns1.abcxyz.net 2.4.20-31.9smp #1 SMP Tue Apr 13 17:40:10 EDT 2004 i686 i686 i386 GNU/Linux old BIND: /usr/sbin/named-checkzone -v 9.2.1 /usr/sbin/named-checkzone abcxyz.com /var/named/db.abcxyz.com zone abcxyz.com/IN: loaded serial 2009102902 OK == current BIND:

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Kevin Darcy
Getting clients to change their resolvers can be challenging, especially if there are large numbers of them and many/most of them don't get their resolvers via DHCP. But I think the answer to that challenge is to come up with better ways of managing clients, not to add a proxy mode to BIND.

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Chris Thompson
On Oct 30 2009, Michael Hare wrote: For those of us that are still running auth and recursive on the same IP, I believe the benefit would be to deploy a best practices recursive only nameserver on a different machine/IP address without getting, in my case, possibly hundreds of thousands of

Forward zone files not working on Bind 9.3.6-P1 for Solaris and OpenSolaris??

2009-10-30 Thread Kaya Saman
Hi, I'm not sure if there is a syntax error or if I've missed to include something but for some reason my forward zone files don't seem to be working :-( I pulled the skeleton of the files straight off my working Solaris 9 boxes which use Bind 9 from Blastwave! I checked and double checked

Re: Forward zone files not working on Bind 9.3.6-P1 for Solaris and OpenSolaris??

2009-10-30 Thread Kaya Saman
Kevin Darcy wrote: If you're loading a zone as sgd.test, then an owner name of ns-m.test doesn't belong in it, and BIND is correct to reject it. Either change that name to something under sgd.test, or set up a separate zone for ns-m.test or anything above that in the hierarchy (i.e. test or

Re: 9.6.1-P1 zone parser false errors

2009-10-30 Thread Chris Buxton
I'm unable to reproduce this error. __ $ named-checkzone -v 9.6.1-P1 $ named-checkzone abcxyz.com abcxyz.com-hosts zone abcxyz.com/IN: loaded serial 2009103001 OK $ cat abcxyz.com-hosts $TTL 1D @ SOA localhost. hostmaster 2009103001 8H 2H

Re: Forward zone files not working on Bind 9.3.6-P1 for Solaris and OpenSolaris??

2009-10-30 Thread Kevin Darcy
Kaya Saman wrote: Kevin Darcy wrote: If you're loading a zone as sgd.test, then an owner name of ns-m.test doesn't belong in it, and BIND is correct to reject it. Either change that name to something under sgd.test, or set up a separate zone for ns-m.test or anything above that in the

Re: 9.6.1-P1 zone parser false errors

2009-10-30 Thread Chris Buxton
On Oct 30, 2009, at 2:53 PM, Len Conrad wrote: -- Original Message -- From: Chris Buxton cbux...@menandmice.com Date: Fri, 30 Oct 2009 14:13:31 -0700 I'm unable to reproduce this error. Could it be that, for a brief time, those names were CNAME'd no,

Re: Feature request - disable internal recursion cache

2009-10-30 Thread Mark Andrews
In message 4aeb00d0.8030...@doit.wisc.edu, Michael Hare writes: For those of us that are still running auth and recursive on the same IP, I believe the benefit would be to deploy a best practices recursive only nameserver on a different machine/IP address without getting, in my case,

Re: Forward zone files not working on Bind 9.3.6-P1 for Solaris and OpenSolaris??

2009-10-30 Thread Kaya Saman
Am I right in assuming this?? Otherwise, with my setup taking an example of google.com - I was trying to use the .com with the .test where I actually wanted to use the .test as the secondary level domain of google but not append a TLD to it. I think this is against all DNS rules no??

Re: Forward zone files not working on Bind 9.3.6-P1 for Solaris and OpenSolaris??

2009-10-30 Thread Kaya Saman
Luc I. Suryo wrote: you have to become auth for the .test and then in that zone define the subdomain's NS make sense? nb: old company we had .prv for internal use :) -ls Thanks Luc, I think I understand now! The TLD for my domain has become .test therefor the secondary level domain