name caching and forwarding

[Robert Moskowitz]

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.