Newbie - config questions

[Tilman Schmidt]

At 13:44 29.02.00 +1100, Bryan Tonnet wrote:
>We have the following setup
>
>An internal network of 192.168.x.y
>
>A dual homed masquerading firewall with an outward facing 'real' ip
>address
>Two other machines in a perimeter net with 'real' ip addresses.
>
>One of the internal machines runs bind 4.9.2 and is a primary for
>192.168.x, and has a forwarder of the firewall machine.
>
>The firewall machine runs bind 4.9.7, and is a secondary for 192.168.x,
>and has forwarders to two of our ISP's NS machines.
>
>Our ISP is the primary for our 'real' IP addresses.
>
>There is only one domain for the company both internal and external.
>
>My issues;
>
>* Is the above a reasonable setup or have I got it completely wrong? 

Seems reasonable to me, as far as it goes. The interesting part,
however, is how you set up the authority for the company domain.
Both your internal BIND server and the primary at the ISP should
be primaries for that, but with different zone contents.

>For example, there's nothng to stop us being the primary for our 'real'
>addresses if that's more sensible than leaving it to our ISP.

That's more of an administrative rather than technical issue.
Personally, I prefer to have full control over my domain, so I would
always make my own server the primary and have the ISP's servers as
secondaries. But if it is more practical for you to have your zone
files maintained by your ISP, that's ok too.

>* The generic domain resolves fine from outside the company, but inside
>the domain does not resolve.  I'm clueless as to whether this should be
>another A record or a CNAME or what.  Neither of these seems to work.

You have to duplicate your entire externally visible domain on your
internal nameserver. If the internal nameserver is configured as
authoritative for the domain then it will return NXDOMAIN for any
name it cannot find in that domain. It will *never* forward queries
for that zone to a forwarder. 

>* 'Real' IP addresses for the domain in the internal NS named files
>don't seem to work.  The firewall machine therefore has to have these in
>its hosts file (messy).

Same reason, probably.

>   This at least solves some problems, but why
>can't the internal primary handle a few extra IP addresses outside of
>192.168.x.y as part of the domain?

It can. Works fine here. If it doesn't for you, there must be an
error somewhere.

>* I think the firewall machine gets occasionally confused as to where to
>forward requests for our domain.  It should go looking at it's own
>(secondary) tables first, but seems to occasionally reach outside to the
>ISP's primary tables which, of course, have none of the internal
>machines listed.

That description sounds wrong to me. The firewall machine's own secondary
tables should be an exact copy of the ISP's primary tables; that's what
primaries and secondaries are all about. If the firewall machine is to be
able, for its own purposes, to resolve internal names, it shouldn't query
its own nameserver, but the internal one. Ie. in resolv.conf, do not
specify localhost as a nameserver (at least not as the first one), but
your internal BIND server.

-- 
Tilman Schmidt          E-Mail: Tilman.Schmidt at sema.de (office)
Sema Group Koeln, Germany       tilman at schmidt.bn.uunet.de (private)