Non-local DNS resolution question

[Kevin Darcy]

Robert Lowe wrote:

>Jim Reid wrote:
>
>  
>
>>>>>>>"Robert" == Robert Lowe <Robert.H.Lowe at lawrence.edu> writes:
>>>>>>>              
>>>>>>>
>>    >> Having scanned the archives, it appears I put:
>>    >> 
>>    >> digitalriver.com NS fc-2kdc-01.fireclick.com.
>>    >> digitalriver.com NS fc-2kdc-02.fireclick.com.  
>>    >> fc-2kdc-01.fireclick.com.  A 192.168.254.26
>>    >> fc-2kdc-02.fireclick.com.  A 192.168.254.27
>>
>>    >> in the root zone file.
>>
>>    Robert> No, don't do this.  Use a forward zone in your named.conf files
>>
>>No! Don't do this either. A DNS "solution" that involves forwarding is
>>almost certainly broken. Configure your local name server(s) as slaves
>>for the digitalriver.com zone. These servers don't have to be listed
>>in the NS records for digitalriver.com. This way your local name
>>servers will be less dependent on the existing digitalriver.com
>>servers and your overall DNS infrastructure will therefore be more
>>robust and stable.
>>    
>>
>
>Late getting back to this... if he has the option of acting as a slave,
>and both parties are willing to do the work (and it might be trivial,
>but if there are lots of zones, it may not be), then I'll agree.  If not,
>there is nothing inherently "broken" about using a forward zone (and yes,
>Bob, one entry will cover all subdomains).  Interacting with private partner
>networks is what it's there for, and while some may misuse the feature, and
>others just don't like it, that's not to say it should be avoided at all
>costs.
>
I think what you're forgetting (or overlooking) is the "stub" option. 
This gives most of the benefits of slaving without the zone-transfer 
overhead, and most of the benefits of forwarding without as much 
fragility (or, as Cricket would say, "brittleness") or scalability 
problems (since forwarding basically shifts the name-resolution workload 
from the local nameservers to the forwarder(s)). "stub"s are especially 
efficient at deeply-delegated hiearchies, since they cache referral 
information for the relevant nameservers all of the way down the chain 
and can therefore "shortcut" future queries. The only thing that 
seriously trips up "stub"s are what I call "iceberg" hierarchies, where 
the authoritative servers for the apex zone (or perhaps a few levels 
below) are directly queriable, but the authoritative servers for the 
various descendant zones are not. Improper delegation often compounds 
the problems I have with such hierarchies. In those cases, forwarding 
must be used. In fact, I would say generally that forwarding should not 
be used except where there are connectivity issues ("forward only" mode) 
or there is a demonstrated performance benefit ("forward first" mode).

- Kevin