Feature request - disable internal recursion cache
Dmitry Rybin
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. :(
Niall O'Reilly
I don't see the point.
If you need some code, other than BIND named, to handle
recursive queries from your clients, why not just have
that code listening on the addresses configured in the
stub resolver on each of the client systems?
Best regards,
Niall O'Reilly
University College Dublin IT Services
Dmitry Rybin
>> 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.
>
> If you need some code, other than BIND named, to handle
> recursive queries from your clients, why not just have
> that code listening on the addresses configured in the
> stub resolver on each of the client systems?
>
I'll explain, why.
Same Server is authoritative for internet/intranet and recursive for
intranet and one large AS. Sometimes Auth/Rec server IP cannot be spited
into different IP's.
Bind answer authoritative for all clients, and forward (if allowed)
recursive queries to recursive server.
Kevin Darcy
> Hello everybody!
>
> 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. :(
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 by changing nothing else and adding a
network hop?
- Kevin
Kevin Darcy
> 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. :(
>>
>>
>> If you need some code, other than BIND named, to handle
>> recursive queries from your clients, why not just have
>> that code listening on the addresses configured in the
>> stub resolver on each of the client systems?
>>
>
> I'll explain, why.
> Same Server is authoritative for internet/intranet and recursive for
> intranet and one large AS. Sometimes Auth/Rec server IP cannot be
> spited into different IP's.
>
> Bind answer authoritative for all clients, and forward (if allowed)
> recursive queries to recursive server.
Why not just point some or all of those recursive clients to the "other"
recursive resolver?
Seems like BIND ceases to add any value when it's just forwarding
everything and not caching any results.
- Kevin
Michael Hare
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 address.
In the surface, I too find this to be an interesting idea.
-Michael
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Kevin Darcy
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.
- Kevin
Chris Thompson
>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 address.
Put the authoritative-only nameservers at the new IP addresses, keeping
the recursive ones at the original IP addresses.
Been there, done that!
--
Chris Thompson
Email: ce...@cam.ac.uk
Kevin Darcy
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.
- Kevin
Mark Andrews
In message <4AEB00D0...@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, possibly hundreds of thousands of clients to change their DNS
> resolver IP address.
>
>
> -Michael
It's much easier to move authoritative servers to new addresses.
Just change the delegation and the iterative traffic will follow.
You can keep the old server as a stealth slave.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Barry Margolin
Kevin Darcy <k...@chrysler.com> wrote:
You don't have to change all the domain registrations. You just have to
change the A records of the nameserver names. Hopefully you haven't
done something silly like use different nameserver names for each domain.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Michael Hare
>> 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.
>
> change the A records of the nameserver names. Hopefully you haven't
> done something silly like use different nameserver names for each domain.
Updating the adns A records is great but this doesn't automatically
change firewall rulesets. I can't control what kind of good or bad
assumptions folks that we are secondaries for made.
I think we can agree that it can be a lot of effort to break auth and
recursive into two IPs no matter what route you go.
I agree that using adns for rdns proxy is suboptimal but sometimes the
lower cost engineering solutions in practice are just as good as the
painful ones.
I mostly threw my hat in the ring so that it would be known that more
than one BIND user could benefit from a feature like this.
-Michael
Matus UHLAR - fantomas
>
>>> 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.
>>
>> If you need some code, other than BIND named, to handle
>> recursive queries from your clients, why not just have
>> that code listening on the addresses configured in the
>> stub resolver on each of the client systems?
On 30.10.09 13:44, Dmitry Rybin wrote:
> I'll explain, why.
> Same Server is authoritative for internet/intranet and recursive for
> intranet and one large AS. Sometimes Auth/Rec server IP cannot be spited
> into different IP's.
>
> Bind answer authoritative for all clients, and forward (if allowed)
> recursive queries to recursive server.
why shouldn't it cache those responses?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.
Dmitry Rybin
>> 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 by changing nothing else and adding a
> network hop?
recursion possibilities of bind is very pity in compare with
powerdns-recursor, unbound & so on. It allocate a lot of memory and make
high CPU usage.
Sometimes unable change authoritative and recursive IPs.
The decision is:
Authoritative q: bind answer it
Recursive: pass from bind ACL and proxy all recursive queries to special
recursion daemon.
It'll be very useful option.
Dmitry Rybin
>> 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
> 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 by changing nothing else and adding
>> a network hop?
>
> recursion possibilities of bind is very pity in compare with
> make high CPU usage.
>
> Sometimes unable change authoritative and recursive IPs.
mis-deployed/mis-architected something, and are therefore locked into
using the same IP for recursive and authoritative nameservice?
If you prefer other recursive resolvers to BIND, then go ahead and use
them, you should have planned ahead and provisioned separate IPs so that
you'd have that option.
You might be able to deal with your current predicament by selectively
NAT'ing or PAT'ing incoming recursive queries, to bypass your BIND
instance, e.g. using the "u32" module of iptables, see, e.g. (for
inspiration)
http://www.stupendous.net/archives/2009/01/24/dropping-spurious-nsin-recursive-queries/
But, frankly, anything along those lines would be a kludge.
- Kevin
Kevin Darcy
> In article <mailman.834.1256928...@lists.isc.org>,
> Kevin Darcy <k...@chrysler.com> wrote:
>
>
> change the A records of the nameserver names. Hopefully you haven't
> done something silly like use different nameserver names for each domain.
>
http://cr.yp.to/djbdns/notes.html#gluelessness to heart, despite its
obsolescence, and consider all delegations which *don't* point to names
in the specific domain which is being delegated, to be "glueless" and in
some way inferior to "in-bailiwick" delegations.
So the practice of delegating to domain-unique nameserver names, is
rather rampant, and it means many folks would have to update a *lot* of
records, if they changed the address(es) of their authoritative
nameserver(s). It's not a trivial change at all.
- Kevin
JINMEI Tatuya / 神明達哉
Dmitry Rybin <kir...@corbina.net> 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 improved performance by changing nothing else and adding a
> > network hop?
>
> recursion possibilities of bind is very pity in compare with
> powerdns-recursor, unbound & so on. It allocate a lot of memory and make
> high CPU usage.
I don't deny in some cases BIND9 caching server may require a lot of
memory and may run slowly, but if you are still using a massive number
of views as you've previously reported:
https://lists.isc.org/pipermail/bind-users/2008-December/074173.html
the excessive number of views can be a main reason for the performance
problems, in which case comparison with other implementations that
don't support views doesn't make much sense.
Anyway, if you want to forward incoming queries to a different server
without caching the results, I believe setting max-cache-ttl (and
perhaps max-ncache-ttl also) to 0 does pretty much of
it. (max-cache-ttl = 0 has a bad effect, as noted in recent ARM, but
if you only care about results from an external forwarder, it should
be okay)
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
Dmitry Rybin
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/
Dave Sparro
> 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 server?
It seems like dnsproxy would be much more useful if it performed it's
query routing based on the RD bit.
--
Dave
Kevin Darcy
> 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.
with less processes, and less listening ports/addresses, by BIND's
"view" feature? You can have one view for recursive resolution, and
another view that's only authoritative data, with no recursion at all,
and select the view depending on the client source address. This is, in
fact, how many folks (including us) run their Internet-facing
nameservers these days.
Perhaps this is why the dnsproxy code hasn't been updated in over 4
years. It would appear to be obsolete.
- Kevin