Newbie install help

[Kevin Darcy]

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 well
> > 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 own
> > 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? Does
> > 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 their
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 zones,
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 whether
IXFR is available.

You could also consider a mixed approach, with some of your servers being slaves
(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 know
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 both
you and the "other" corporate DNS under a common internal-root structure while
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