What will BIND do?

[Kevin Darcy]

Yes, "view"s can eliminate the need to run multiple nameserver instances for
split DNS. But you still have to maintain some data in two different places --
or at least, one file $INCLUDE'd into two zones -- if you want it to be visible
internally and externally. "View" doesn't change that.


-Kevin

GBPAP018 wrote:

> Not that knowledgeably about BIND, but I think BIND can do this, with VIEWS,
> present different views to different networks of the same zone
>
> A
>
> "Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
> news:9bl66j$f0i at pub3.rc.vix.com...
> >
> > Yes, in a split DNS setup, the external data needs to be entered in
> > *both* versions of the zone, if it is to be visible both internally and
> > externally. Note that if the same machine is master for both internal and
> > external versions of the zone (either externally-accessible or a
> > "hidden" master for the external version), you might be able to play
> > $INCLUDE-file tricks to make the maintenance a little easier.
> Alternatively,
> > tweak your DNS maintenance system to maintain the external entries in
> parallel
> > with the internal ones. I doubt QIP is capable of this, but some homegrown
> > systems may be (I'm working on implementing "parallel maintenance" here).
> >
> >
> > - Kevin
> >
> > Christopher Fellows wrote:
> >
> > > Hello everyone, First time poster here...
> > >
> > > I have a situation that I need a little bit of advice on. We are
> currently
> > > designing a rooted DNS architecture for a large (global) company and are
> not
> > > sure what will happen under some very specific circumstances. First let
> me
> > > tell
> > > you a little bit about the design.
> > >
> > > Requirements:
> > >
> > > 1. Internal rooted DNS - several root servers sprinkled around the globe
> > > acting
> > > as "."
> > >
> > > 2. Default route to Internet for some internal clients - currently DNS
> is
> > > proxied along with WWW content. We require some (if not all) internal
> > > clients to
> > > have direct access to the Internet (non-proxied) This is due to some
> > > Internet
> > > based applications that require direct communication with the client
> (mostly
> > > JAVA applets and Citrix systems).
> > >
> > > 3. Secure Intranet zone files - We don't want the dirty outside people
> to be
> > > able to resolve all Intranet objects, only specific ones.
> > >
> > > 4. All internal clients need to be able to resolve both Intranet and
> > > Internet
> > > names.
> > >
> > > Design:
> > >
> > > Here is what I have come up with.
> > >
> > > 1. Several (11) Sun boxes at hubs around the planet running QIP (QDNS)
> as
> > > rooted
> > > DNS servers for the company. They will contain all internal name and
> address
> > > information.
> > >
> > > 2. On these servers we will implement DNS "views" or conditional
> forwarding
> > > to a
> > > Bastion host in the DMZ. Any request that is not "company.com" will be
> > > forwarded
> > > to this name server who has a foot on both the Internet and the
> Intranet.
> > > This
> > > host will run a caching only name server and have allow-query access
> lists
> > > option enabled so that only internal queries will be answered. Zone
> transfer
> > > requests will be sent to internal name servers.
> > >
> > > 3. A spit DNS server on the perimeter network hold company.com "shadow"
> name
> > > space information. Basically pared down zone information about
> company.com
> > > advertising only those hosts and mail gateways that we want seen from
> the
> > > Internet. This server is authoritative for comapny.com on the Internet.
> > >
> > > Opperation:
> > >
> > > Here is how I believe this should work.
> > >
> > > 1. An internal client requests "www.company.com" - Normal DNS function,
> uses
> > > internal name root name servers to answer client requests.
> > >
> > > 2. An internal client requests "www.suborg.company.com" - Normal DNS
> > > function,
> > > same deal as above
> > >
> > > 3. An internal client requests "www.anothercompany.com" - Root server
> > > forwards
> > > request based on it's view option to the Bastion host who performs
> recursive
> > > lookups on the Internet.
> > >
> > > 4. An external client requests "www.company.com" - Since the "Shadow"
> name
> > > server is authoritative for "company.com" on the Internet, and
> > > "www.company.com"
> > > is advertised in it's zone, it will answer the request.
> > >
> > > 5. An external client requests "mypc.company.com" - Since the "Shadow"
> zone
> > > file
> > > contains nothing about this object DNS will return "host not found".
> > >
> > > Questions: (finally)
> > >
> > > 1. What happens if "www.company.com" is on the Internet? - Will an
> internal
> > > client be able to resolve it? Or, will the internal root servers simply
> > > return
> > > "host not found"?
> > >
> > > 2. Is the only answer here to enter the external name-to-address
> information
> > > for
> > > external objects on the internal root servers by hand?
> > >
> > > 3. Is there any other problems with this design that I haven't thought
> of?
> > >
> > > Thanks for any help that you can offer. Please send replies to
> > > christopher.fellows at ins.com as I don't have constant access to the list
> > > email.
> > > Have a great one.
> > >
> > > Chris F
> >
> >
> >
> >
> >