Newbie install help

[Mark_Andrews at iengines.com]

> 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