Non-local DNS resolution question

[Kevin Darcy]

Robert Lowe wrote:

>Kevin Darcy wrote:
>
>  
>
>>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. 
>>    
>>
>
>Yes, I had forgotten about stubs.  IIRC, stubs are a sort of a
>middleground between slaving and forwarding.  The OP needs only
>one stub zone for the apex, correct?  Seems like an elegant solution
>without much work at all.
>
>  
>
>>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)
>>    
>>
>
>I'm assuming you mean the case of a private link, such that the forwarder(s)
>would not be accessible over the public Internet.  I can't think of any
>others off hand.  In this case, the OP's company had just been purchased,
>and the new parent company had dropped nameservers on his LAN with their
>internal zones on them.  That implies a private link for connectivity to
>hosts not visible on the Internet, and to maintain the parent company's
>internal zones.
>
>  
>
>>or there is a demonstrated performance benefit ("forward first" mode).
>>    
>>
>
>Without knowing the details of the heirarchy in question, and the
>connectivity between the parent/child companies, it seems to be only
>conjecture as to what the best approach might be.  Given the assumed
>temporary nature of the nameserver arrangement and close "proximity"
>of the two sets of nameservers, forwarding seemed to be easiest,
>although not necessarily the most robust.  If the newly deployed set
>of nameservers by the parent company contains the complete set of
>zones needed by the child company, then a stub zone doesn't go much
>further though, correct?
>
Even in that case, I think stub zones might be preferable. In some 
versions of BIND, forwarders are used *sequentially*, which means if the 
"top" forwarder becomes unavailable, every forwarded query gets 
penalized until the order is manually changed or the "top" forwarder 
becomes available again. With stub zones, the RTT algorithm is used for 
nameserver selection, so it's more adaptable to failures, and balances 
load better. This does, however, require that all zones and subzones are 
properly delegated...

- Kevin