subdomain/split dns question

Kevin Darcy kcd at chrysler.com
Fri Oct 12 20:40:22 UTC 2007


Example: mtu.daimlerchrysler.com

Ask the daimlerchrysler.com nameservers, they return a CNAME to 
mtu.graz.daimlerchrysler.com

Ask the daimlerchrysler.com nameservers *again* for 
mtu.graz.daimlerchrysler.com and they give you a referral of the 
graz.daimlerchrysler.com zone to ns1.graz.daimlerchrysler.com and 
ns2.graz.daimlerchrysler.com

Ask those nameservers about mtu.graz.daimlerchrysler.com and you get the 
A records.

Clear?

                                                                         
                        - Kevin

Kevin Darcy wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>>
>>>>
>>>>       
>>>>         
>>>     
>>>       
>>
>>
>>
>>   
>>     
>
>
>
>
>   



More information about the bind-users mailing list