TUTORIALS

Set up external DNS on the FWTK machine.
This DNS server is the one that the InterNIC points to for your DNS.
Create full DNS records for the host(s) you have directly connected to the Internet.
Do not give out information on your internal network here! SOA - source of authority
NS - name server records
A - Address record(s)
MX - Mail exchanger record(s) - Make certain you use actual A records for this host no CNAMEs
HINFO - Host Info records

Set up DNS on an internal server.
This DNS server is used by only your machines, fill it with every piece of information you require. Again create full DNS records for all hosts including BOTH interfaces of the Firewall. Don't forget to give your external interface a name otherwise you will run into trouble with sendmail if the Firewall needs this information.  I typically enter this in /etc/hosts also. Hostnames may be any valid hostname including duplicates of hostnames you used on the outside. This is where you can play games with hostnames.  For instance you can call both of your Web servers, internal and external, www.yourdomain.com  Hosts on the Internet will talk to your external Web server and your internal network will talk to your Intranet server. This can be very helpful if you have people internally and externally that need services such as e-mail, web, nntp, etc. there is no need to make client changes based on where they are.  The client requests the same hostname and DNS points them at the correct server.
In named.boot:
You do not need a root server "cache" for internal servers, but some servers, Solaris, have trouble without it.
Add a forwarders line to the end of the file with the IP address of your Firewall's internal interface. This will resolve hostnames for external domains.

All machines should point to the internal DNS server for host name resolution, including the Firewall.
resolv.conf on your Firewall should have the  "nameserver" entry with the IP address of your internal DNS server.  This way your Firewall knows about your internal network and can also resolve information on the external network, via the forwarder, a.k.a. your firewall.

This should get give you the basic concept of split DNS.  There are many references on the net for DNS configuration, a good place to start is at the BIND home page: http://www.isc.org/bind.html

- Bill Earle <Bill.Earle@Dynabrade.COM>

The INTERNAL DNS (the one only our internal users can see) is set up as the primary DNS for our network.  It includes info for all machines behind the firewall. All internal machines point to it for ALL queries. It forwards all queries it can't handle to the only other server it knows about, the EXTERNAL DNS running on the firewall.

>From the named.boot file of our INTERNAL DNS:
cache           .                                   named.cache
primary         oicinc.com               named.oicinc.com
primary         172.16.100.in-addr.arpa named.oicinc.rev
forwarders      172.16.100.100

The named.cache file of our INTERNAL DNS: ;
; Initial cache data for root domain servers. ;
; list of servers...
. 99999999 IN NS portal.oicinc.com.
portal.oicinc.com. 99999999 IN A 172.16.100.100

The EXTERNAL DNS (the one the Internet sees) is the primary DNS as far as InterNIC is concerned. This server should have a cache file to leads to the root level servers.  Note: This server only contains info I want the world to know about. e.g. MX records and the addr of our external web and FTP servers.

- Paul Beltrani <beltrani@portal.oic.htdc.org>
 

2.2: Sendmail configuration

For running split DNS: External sites see the external MX and send to smap on the bastion. With the bastion's resolver pointing to an internal DNS, sendmail uses that first then gets forwarded to the bastion's named. Thus:

External mail inbound gets accepted by smap according to the external MX records. Sendmail then uses the internal MX records to deliver the mail. Too easy.

Outbound mail gets accepted by smap on the bastion. Sendmail looks in the internal DNS and gets no answer (directly) and the DNS query is forwarded to the bastion's DNS which returns the correct external A/MX record for mail delivery.

Works like a charm.

If you don't want to use split DNS, you'll need a .cf to force local mail to the internal mailhost. You could do this a number of ways

1) use LOCAL_NET_CONFIG and specify rules to deliver to a specific host. Something like the following should suffice:

LOCAL_NET_CONFIG
R$* < @ $* . $m. > $*   $# smtp $@ $2 $: $1 < @ $2 . $m > $3
R$* < @ $m. > $*        $# smtp $@ mailhost $: $1 < @ $m. > $2

The first line accepts mail for any machine in the domain and delivers to that machine. The second delivers mail adressed to the domain and sends it to the mailhost. Of course you could do the same in the first case - instead of sending to the host send to the mailhost and let it decide how to deliver.

2) use the "mailertable" feature. We use this on an internal machine which is doing a similar job to the bastion.

FEATURE(mailertable, hash /etc/mail/mailertable)

The "mailertable" is just a list of domains and delivery rules. eg

my.domain smtp:mailhost.internal.my.domain
.my.domain smtp:mailhost.internal.my.domain

These rules accept ALL mail for either the domain or any host/subdomain and use the "smtp" mailer to send to the internal mailhost. Of course you need to build "makemap" so you can create the hash table.

Colin Campbell <sgcccdc@citec.qld.gov.au>

FEATURE(nouucp)dnl
FEATURE(nodns)dnl
FEATURE(always_add_domain)dnl
FEATURE(nocanonify)dnl
MASQUERADE_AS(firesign.com)dnl
MAILER(local)dnl
MAILER(smtp)dnl

The inportant ones were the MASQUERADE_AS and the noncanonify. Also, make sure that the Cw has all of the possible hostnames in it  That might get you going without DNS.

Eric Geyer <ericg@firesign.com>
 
 

2.3: Help with applying patches

A patch file is NOT a C source code file.

A patch file is the 'diff' output between two files: in this case, probably two C source code files or support files.

The 'patch' program does, essentially, a reverse 'diff'.  You must start with the SAME source file as the older one that the person who made the patch started with.  You will end up with the SAME new source file that the person ended up with.

EXAMPLE:
     John and I both have files "list.c" in directory "src".

     I fix mine.  I make a 'diff' file and send it to John:

          $ diff -u list.c list.c.new > list.patch
          $ mailx -s list.patch john < list.patch

     John gets the file, and saves it by the same name [stripping
     mail headers and the like].  He uses the 'patch' program to
     update his copy of "list.c":

          $ cd src
          $ patch < ../list.patch

     John and I now have the same version of list.c.

NOTES:
     (1) The patch file is 'diff' output, and cannot be compiled.
     (2) The 'patch' program must be run in the directory where the file or files being updated are located.
     (3) You must, Must, MUST start with the same version(s) of the same file(s); otherwise, the 'patch' will either refuse to work at all, or if it does run, it has a good chance of giving you garbled output.

Joseph S. D. Yao <jsdy@cospo.osis.gov>