name caching and forwarding

[Kevin Darcy]

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.