hey, Kevin, hope you are hanging well back at the old stomping ground!
On 02/26/2013 01:42 PM, Kevin Darcy wrote:
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.
Very well summarized. Thank you. What I was expecting it to work, but
verify; don't just trust.
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 :-)
Them were the days.
- 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.
My little network will do well as I am setting it up. Plus I can run my
HIP testing. I leave the world-wide mess to old hands like you.
_______________________________________________
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
