On 2/26/2013 11:39 AM, Robert Moskowitz wrote:

On 02/26/2013 11:14 AM, Phil Mayers wrote:
On 26/02/13 16:07, Robert Moskowitz wrote:

And I am having challenges with the forward option.  It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching?  And 'forward first' only looks in cache after a
forward fails?  This does not sound right and I am missing something in
the documentation; like forwarding ONLY applies IF the query is NOT in
cache?

No, you've misunderstood.


"forward first" means "try the forwarders, and if you don't get a reply, try the query yourself starting from the root"

"forward only" means "only ever try the forwarders"

"forward" replies are always cached for the relevant TTL.

OK. This is what I was hoping it meant, but I was not good at expressing it.
To clarify even further, caching is *always* in effect, no matter what kind of non-authoritative zone you define (forward, stub, etc.) or even if you have no explicit zone definition at all and simply follow the delegation chain to the data, as Phil described.

Think of "forward first" as "opportunistic", in the sense that you'll try to get the data via forwarding, but if that doesn't work, you'll fall back to whatever mechanism you'd use to resolve the name, if the zone definition didn't exist at all. Generally speaking, "forward first" is an attempt (usually unsuccessful, in most environments) to improve query performance by utilizing a centralized cache.

"Forward only", on the other hand, is "dependent", in the sense that your forwarders are the *only* thing that will allow you to resolve the name. If that doesn't work, the query fails completely. "Forward only" should be used, not solely as an attempt to enhance performance, but as a way to get around connectivity restrictions, e.g. firewalls or a restrictive routing regime.

So, in a nutshell: "forward first" as an opportunistic attempt to improve performance, but you can still fall back to your regular resolution methods; "forward only" to get around blockages or connectivity restrictions.

If all you want to do is run a private namespace, I wouldn't be fiddling around with forwarding at all. Set up your own root zone, propagate a private set of hints data, and be happy. I know that you once thrived in such a DNS environment :-)

                        - Kevin

P.S. Insightful readers may have picked up from the above that I am not particularly fond of forwarding at all. In my experience, iterative resolution usually shows better performance, especially in geographically-diverse infrastructures with many subdomain levels (would I really want to forward through Italian nameservers to resolve names that I could resolve from nameservers in the same metro area, for the North American subdivision of one of our partners?). For that matter, I'm an even bigger fan of replicating zone data far and wide on stealth slaves -- give your users the maximum in performance and resiliency, and they'll be happier for it. In practical terms, one of the biggest issues I have about forwarding is that admins who go hog wild with it tend to get really lazy and sloppy about keeping their delegations and glue straight. Which means they create massive interoperability problems for anyone who doesn't want to play in their forwarding sandbox. Even though I eschew forwarding myself, I leave the option open for people to forward to my infrastructure *if*they*must*, but with all of the broken delegations/glue, I am not afforded the same opportunity to utilize my preferred resolution methodology. That seems a little selfish/one-sided.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to