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
