Newbie install help
Mark_Andrews at iengines.com
Mark_Andrews at iengines.com
Wed Nov 24 04:29:51 UTC 1999
> 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