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 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?
Best regards,
Niall O'Reilly University College Dublin IT Services
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.
> 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.
> 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. :( > _______________________________________________
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?
>>> 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. > _______________________________________________
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.
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.
In the surface, I too find this to be an interesting idea.
>>>> 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. >> _______________________________________________ > 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.
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.
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 clients to > change their DNS resolver IP address.
> In the surface, I too find this to be an interesting idea.
>>>>> 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. >>> _______________________________________________ >> 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.
>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.
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 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!
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 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, 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
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
> 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 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!
> 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.
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 ***
>> 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.
> 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.
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.
>>> 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.
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.
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.
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 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.
So, you want to add an operational mode to BIND because you 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-...
But, frankly, anything along those lines would be a kludge.
Barry Margolin wrote: > In article <mailman.834.1256928257.14796.bind-us...@lists.isc.org>, > Kevin Darcy <k...@chrysler.com> 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 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!
>> 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.
> 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.
Unfortunately, the reality of the situation is that many folks have taken 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 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:
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.
On Wed, Dec 2, 2009 at 9:43 AM, Dmitry Rybin <kirg...@corbina.net> 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 server?
It seems like dnsproxy would be much more useful if it performed it's query routing based on the RD bit.
> 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 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.
|
