djbdns does lovely, easy, simple split-horizon DNS. I'll describe how to set it up. To make the example concrete, I'll do it for a fantasy firewall. The external addr on this firewall will be 1.2.3.4, that's the publicly-visible IP addr, and it'll be the public nameserver. The inside addr will be 192.168.0.1, for the 192.168.0/8 network used on the inside of the firewall. The firewall will be known publicly as gateway.example.dom, and will have alternate names ns1.example.dom and smtp.example.dom. In addition, it will serve private names including dreamwvr.example.dom and filesrv.example.dom to the inside network only, as well as firewall.example.dom for its own internal interface. NB: this is untested, off the top of my head, but I'm pretty sure it's pretty close. I do love djbdns; I've never met anyone who could do the equivalent to this off the top of their head for BIND:-). (1) Set up tinydns for the outside, serving public authoritative data tinydns-conf tinydns dnslog /etc/tinydns-public 1.2.3.4 cd /etc/tinydns-public/root cat <<-Eof >data .example.dom::ns1.example.dom @example.dom::smtp.example.dom =gateway.example.dom:1.2.3.4 +ns1.example.dom:1.2.3.4 +smtp.example.dom:1.2.3.4 Eof make ln -s /etc/tinydns-public /service (2) Set up private tinydns on localhost, with both the public data and additional records for the private net. Note that we want different NS for example.dom in the private server, so we'll make a controlled merge, grepping out the "." records from the public data before appending them to the private. Let's also make it self-documenting. tinydns-conf tinydns dnslog /etc/tinydns-private 127.0.0.1 cd /etc/tinydns-private/root cat <<-Eof >data-private .example.dom::localhost. .0.168.192.in-addr.arpa::localhost. =firewall.example.dom::192.168.0.1 =dreamwvr.example.dom:192.168.0.2 =filesrv.example.dom:192.168.0.3 Eof cat <<-Eof >hdr1 # Do __NOT__ edit this file. For the records # in this section, edit the file # data-private Eof cat <<-Eof >hdr2 # For the records in this section, edit the file # /etc/tinydns/root/data Eof cat <<'Eof' >Makefile prv=data-private pub=/etc/tinydns/root/data data: $(prv) $(pub) (cat hdr1 $(prv) hdr2;grep -v '^\.' $(pub))>data data.cdb: data /usr/bin/tinydns-data Eof make ln -s /etc/tinydns-private /service (3) Set up a dnscache for use within your private net, which will reference the private tinydns for your internal domains dnscache-conf dnscache dnslog /etc/dnscache 192.168.0.1 touch /etc/dnscache/root/ip/192.168.0 cd /etc/dnscache/root/servers echo 127.0.0.1 >example.dom ln example.dom 0.168.192.in-addr.arpa ln -s /etc/dnscache /service (4) If you need to support an external secondary, and they run tinydns, set up your script so whenever you rebuild data.cdb, you then rsync-over-ssh the data to the secondary. If your secondary doesn't run tinydns, just install axfrdns running alongside tinydns: axfrdns-conf tinydns dnslog /etc/axfrdns /etc/tinydns-public 1.2.3.4 cd /etc/axfrdns echo ':allow' >tcp make ln -s /etc/axfrdns /service (5) Now make sure everybody uses your shiny new servers. Tell your registrar of choice about ns1.example.dom on 1.2.3.4, and if applicable about your secondary. They create the NS records that external nameservers will chase through to arrive on your doorstep. Set up your internal resolv.conf files something like search example.dom nameserver 192.168.0.1 BTW, this is how I document when I setup a firewall for someone; this style of docs, together with the briefest of intros to the online docs for the software in use, seems to be very nice for letting people see what I've done, when they need to re-do it, or make changes. And to make sure my docs are accurate, I prepare 'em in advance, then do the work by cutting-n-pasting from them, fixing the docs if I have to fix any typos to make the cut-n-paste work. -Bennett