Non-local DNS resolution question

[Robert Lowe]

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?

-Robert