Dmitry Rybin wrote:
I found answer for my feature request - simple C proxer:
http://www.wolfermann.org/dnsproxy.html
It can forward queries to auth or recursion server. Based on client IPs.
So, what does a dnsproxy approach accomplish, that can't be achieved
with less processes, and less listen
On Wed, Dec 2, 2009 at 9:43 AM, Dmitry Rybin wrote:
> I found answer for my feature request - simple C proxer:
> http://www.wolfermann.org/dnsproxy.html
>
> It can forward queries to auth or recursion server. Based on client IPs.
>
What if one of your access customers is running their own DNS ser
I found answer for my feature request - simple C proxer:
http://www.wolfermann.org/dnsproxy.html
It can forward queries to auth or recursion server. Based on client IPs.
FreeBSD port /usr/ports/dns/dnsproxy/
___
bind-users mailing list
bind-users@list
At Mon, 02 Nov 2009 18:24:54 +0300,
Dmitry Rybin wrote:
>
> Kevin Darcy wrote:
> >> Daemon as unbound, pdns-recursor - much faster in recursion queries,
> >> that bind. :(
> >> ___
> > So, you don't cache locally, you forward to another daemon that (in
Barry Margolin wrote:
In article ,
Kevin Darcy wrote:
Chris Thompson wrote:
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
Dmitry Rybin wrote:
Kevin Darcy wrote:
Daemon as unbound, pdns-recursor - much faster in recursion queries,
that bind. :(
___
So, you don't cache locally, you forward to another daemon that (in
the best case) answers from *its* cache.
How have you
Matus UHLAR - fantomas wrote:
Bind answer authoritative for all clients, and forward (if allowed)
recursive queries to recursive server.
why shouldn't it cache those responses?
Bind cache is slow. It allocate a lot of memory and make high CPU usage.
_
Kevin Darcy wrote:
Daemon as unbound, pdns-recursor - much faster in recursion queries,
that bind. :(
___
So, you don't cache locally, you forward to another daemon that (in the
best case) answers from *its* cache.
How have you improved performance
> 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. :(
>>
>>
Well, except then you need to update all of your delegations. That can
not only be an administrative hassle, but can also get very expensive,
especially if you have hundreds of them in ccTLDs, where you have to pay
your "in-country agent" a fee for every registry change. It's quite a
racket.
In article ,
Kevin Darcy wrote:
> Chris Thompson wrote:
> > 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 machin
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,
Chris Thompson wrote:
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 hundr
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 cli
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.
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
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. :(
___
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
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.
I
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 se
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. :(
21 matches
Mail list logo
