Re: Feature request - disable internal recursion cache
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
At Mon, 02 Nov 2009 18:24:54 +0300, Dmitry Rybin kirg...@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. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. It'll be very useful option. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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-recursive-queries/ But, frankly, anything along those lines would be a kludge. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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? 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. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. -Michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Feature request - disable internal recursion cache
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. :( ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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 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. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. :( ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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 Kevin Darcy wrote: 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 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. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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. - Kevin 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. -Michael Kevin Darcy wrote: 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 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. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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! -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
