Newbie install help

Armando L. Parada alparada at bellsouth.net
Wed Dec 29 02:50:53 UTC 1999


I don't understand what you mean by : "define the top level of thei
> > r
> > domain as "type forward" and list their servers in the "forwarders { ...
> > }" directive for that zone". Any help would be sincerely appreciated.
Armando

----- Original Message -----
From: <Mark_Andrews at iengines.com>
To: Kevin Darcy <kcd at daimlerchrysler.com>
Cc: ALP <alparada at bellsouth.net>; <bind-users at isc.org>
Sent: Tuesday, November 23, 1999 11:29 PM
Subject: Re: Newbie install help


>
> > Joseph S D Yao wrote:
> >
> > > On Wed, Nov 17, 1999 at 05:08:14PM -0500, ALP wrote:
> > > > Hi all,
> > > > I'm in the process of restructuring our network and need some help.
Our
> > > > needs are as follows:
> > > >
> > > > 1. Resolve our own domain.
> > > > 2. Resolve our email, ftp and web services externally (on our DMZ)
as wel
> > l
> > > > as Internet resolution.
> > > > 3. Somehow also be able to resolve a corporate intranet with a
different
> > > > domain name (we are not a subdomain).
> > > >
> > > > This intranet has no outside connections to the Internet and use
their ow
> > n
> > > > DNS. I know I can setup our new internal DNS with the forwarders
command
> > > > going to an external DNS and that should take care of Items 1 and 2.
My
> > > > question is how do I accomplish item 3? Is there anyway of doing
this? Do
> > es
> > > > bind 8.2.2 have any commands that would selectively forward request?
> > > >
> > > > Many thanks,
> > > > Armando
> > >
> > > Selective forwarding is actually one of the major improvements in BIND
> > > 8.2 over previous versions.  But ISTM that you don't really need it
for
> > > your configuration.  Set your internal name server to be authoritative
> > > for the internal domain(s) and reverse DNS lookups.  Forward [only] to
> > > ... well, now, I am puzzled.  At one point you say there is no
> > > connection to the Internet, and at another you say that you can
forward
> > > to the Internet.  Which is it?  ;-)  I suspect you have a firewall
with
> > > that DMZ.  You can run your external name server on the firewall
bastion
> > > host, which will also allow DNS forwarding through it.
> >
> > (Joseph: I think Armando meant that the "other" corporate intranet had
no
> > Internet connection.)
> >
> > Selective forwarding might be useful here for the "other" intranet: just
set
> > up
> > your forwarding hierarchy as normal, and then selectively forward
queries for
> > the "other" domain to their servers. To do this, define the top level of
thei
> > r
> > domain as "type forward" and list their servers in the "forwarders { ...
> > }" directive for that zone.
> >
> > You could also do this the old-fashioned way and become a slave for
their zon
> > es,
> > but then you'd have to define not only the top level of their domain,
but
> > *every* *one* of their zones on all of your servers (otherwise queries
in
> > subzones will use the global forwarder), and this could become a
maintenance
> > nightmare. This alternative might be mandatory if the only servers of
the
> > "other" intranet you can reach have recursion turned off, or you might
choose
> > this option for performance reasons. In terms of resource usage, the
optimal
> > choice of forwarding versus being a slave is driven by a number of
factors,
> > including frequency and variety of queries for the zone, size of the
zone,
> > frequency of changes to the zone, TTL/refresh settings for the zone, and
whet
> > her
> > IXFR is available.
>
> Just add a empty forwarders clause to slave zone to disable
> forwarding for the subzones.
>
> e.g.
> options {
> forwarders { <IP ADDRESS LIST> };
> };
>
> zone "example" {
> type slave;
> masters { <IP ADDRESS LIST> };
> file "cache/example";
> // disable global forwarding for child zones
> forwarders { };
> };
>
> Queries for foo.sub.example will follow the normal resolution
> procedures.
>
> The same procedure can be applied to stub and master zones
> as well.
>
> >
> > You could also consider a mixed approach, with some of your servers
being sla
> > ves
> > (or even pure iterative servers if they didn't need to be part of your
> > forwarding hierarchy), and the rest selectively forwarding to those
servers.
> > That way, you keep most of the forwarding traffic on your own intranet.
> >
> > Using stub zones might be another possibility, but, quite frankly, I
don't kn
> > ow
> > how stub zones interact with global forwarding.
> >
> > What would be even more useful, however, is if named could deal sanely
with a
> > combination of internal roots and global forwarding. Then you could set
up bo
> > th
> > you and the "other" corporate DNS under a common internal-root structure
whil
> > e
> > still allowing your clients to be able to resolve names in the Internet
> > namespace. A patch to the 8.2.2 source is currently being considered (I
hope)
> > ,
> > which would enable this.
> >
> >
> > - Kevin
> >
> >
> --
> Mark Andrews, Internet Engines Inc. / Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com
>
>




More information about the bind-users mailing list