 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev- | Prev- | Bind- | Oct- | Next- | Next- |
| Subject: | Re: subdomain/split dns question |
| Group: | Bind-users |
| From: | Chris Rizzo |
| Date: | 12 Oct 2007 |
right. Trying an nslookup would never work. So, I finally woke up and tried
using dig, from one of my external linux boxes, and it worked
perfectly....Sorry, about all of this. I now see the light. :)
On 10/12/07, Kevin Darcy <kcd> wrote:
> 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> 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> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
>
| Prev- | Prev- | Bind- | Oct- | Next- | Next- |