subdomain/split dns question

[Kevin Darcy]

Chris,
          I think you're not getting the point that what you see as the 
result of a single nslookup transaction doesn't really simulate the 
multi-step algorithm that an iterative resolver uses to resolve a name 
into an address. There's no problem at all with one set of servers 
giving only a CNAME, another set of servers giving a referral to the 
zone containing the target of the CNAME, and a third set of servers 
actually serving up the A record(s) in that zone. An iterative resolver 
can navigate all of this. You'd need to be familiar with the algorithm, 
however, in order to simulate it using nslookup or dig or some other 
commonly-used command-line tool.

                                                                         
                                       - Kevin

Chris Rizzo wrote:
> So, then, from what I'm reading, this can't be done?
> For security reasons, I don't want anyone on the Internet to be able to do a
> google.com query against my server, yet they need to be able to query
> anything on the subdomain, which is hosted on a different dns server.
> Effectively, I need to allow recursion only for this subdomain, and nothing
> else.
>
>
> On 10/12/07, Kevin Darcy <kcd at chrysler.com> wrote:
>   
>> Chris Rizzo wrote:
>>     
>>> The interesting thing about this, is that what you have below will work,
>>>       
>> if
>>     
>>> I point to a name server that is allowed to do recursion (only my
>>>       
>> internal
>>     
>>> dns servers are allowed to do recursion against this server). If I point
>>>       
>> my
>>     
>>> host directly to the server (acting as any Internet based client or dns
>>> server on the Internet), I get the following...."Served by:" and then a
>>>       
>> list
>>     
>>> of the name servers authoritative for the subdomain.
>>>       
>> Yes, that's how nslookup represents a referral response, what you'd
>> typically get from a non-recursive nameserver or a nameserver that is
>> not honoring recursion for you. Iterative resolvers can handle such
>> responses. You shouldn't point a *stub* resolver at a nameserver that
>> doesn't provide recursion. If you have "exception" clients in the
>> Internet address space that need recursion, you'll need to add their
>> addresses or address ranges to your "internal" view, have a separate
>> (third) view, or go back to the drawing board on your design.
>>
>>
>>                                 - Kevin
>>
>>     
>>> It look like it only
>>> works with recursion, which I don't want.
>>> On 10/11/07, Kevin Darcy <kcd at chrysler.com> wrote:
>>>
>>>       
>>>> Chris Rizzo wrote:
>>>>
>>>>         
>>>>> I have begun the process of creating a split external/internal dns
>>>>>
>>>>>           
>>>> setup. I
>>>>
>>>>         
>>>>> am using bind views so that internal users can see the full zone list,
>>>>>
>>>>>           
>>>> but
>>>>
>>>>         
>>>>> external users only see the Internet routable addresses. It seems to
>>>>>           
>> be
>>     
>>>>> working except for one small issue....I have a subdomain that is
>>>>>
>>>>>           
>>>> delegated
>>>>
>>>>         
>>>>> out to my load balancing devices, i.e.  global.company.com - the load
>>>>> balancers are running bind, and are authoritative, for the global
>>>>>
>>>>>           
>>>> subdomain.
>>>>
>>>>         
>>>>> When a user queries www.company.com, it is actually an alias to
>>>>> www.global.company.com. It looks like the only way that I can get this
>>>>>
>>>>>           
>>>> to
>>>>
>>>>         
>>>>> work is to turn on recursion for the external view, but would rather
>>>>>
>>>>>           
>>>> not. Is
>>>>
>>>>         
>>>>> there some way to do this that I'm missing??? I tried forwarders and
>>>>>
>>>>>           
>>>> stub
>>>>
>>>>         
>>>>> zones but nothing seems to work....Thanks for any help....
>>>>>
>>>>>
>>>>>           
>>>> It'll work as is, but only because resolvers are persistent:
>>>> 1) they'll query the company.com nameservers for www.company.com and
>>>>         
>> get
>>     
>>>> back only the CNAME record,
>>>> 2) they'll turn around and query the alias target
>>>> (www.global.company.com), which may entail talking, coincidentally,
>>>> again to the same company.com nameservers, which will give them a
>>>> referral for global.company.com
>>>> 3) they'll get the A records for www.global.company.com from the
>>>> global.company.com nameservers
>>>> 4) they'll merge both the CNAME and A records into the response and
>>>>         
>> pass
>>     
>>>> it back to the end-user client
>>>>
>>>>
>>>>                        - Kevin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>
>>>
>>>       
>>
>>     
>
>
>
>
>
>