DNS setup on machine serving lan and internet

I have a dns server behind a firewall, serving a private lan and a FQDN domain. The domain on the private lan and the FQDN happens to be the same.. lets say host.com

Whats the ideal setup for a box like this... should I run 2 instances of named.. 1 to serve host.com on the private lan and 1 that only answer to internet queries for the FQDN host.com

... i think i'm confusing myself


if anyone understands what i'm trying to ask, i'd appreciate any feedback.

Thanks

>> The domain on the private lan and the FQDN happens to be the same

This is so-called Split Horizon in DNS term.

>> Whats the ideal setup for a box like this

The ideal way for doing this is to ditch the highly insecure software - BIND and go for tinydns. However, for starters, it's fine to start out with BIND. Once you are familiar with BIND, then you should migrate to djbdns immediately, without a doubt.

>> should I run 2 instances of named

For tinydns, yes, you need to run 2 instances of tinydns, one for internal and one for external. For BIND, everything is built into one useless and huge daemon, therefore, you just need to run 1 named.

>> i think i'm confusing myself

If you are a beginner to BIND, just run an authoritative DNS server for your external domain, not for internal, as it will get you more confused. I suggest you to use /etc/hosts file for internal. When you followup this message, please tell me how much you know about DNS, then I can assist you with futher details.
For now, here is what you need:

1) one zone file, eg. host.com.ext.db
2) one zone file -> host.com.int.db
3) one zone file -> 192.168.0.db
4) named.boot (contains the root zones) this file is not for authoritative DNS server but for DNS cache.
5) named.conf

somewhat familiar... I understand pretty much dns side.. the what, where, why of DNSing, but interms of configuring the thing.. I'd say I was "decent". I've managed to configure conf file and zone files for @ FQDNs, with MXs, the bare basics.


As for using /etc/hosts for the the internal.. you mean editing the hosts file on each lan machine?

>> you mean editing the hosts file on each lan machine?

Yes. For home users, it's waste of resource to run an authoritative DNS sever for your LAN, especially when uing BIND, which doesn't even know how to cache.

Anyway, assuming your host.com.ext.db is properly configured and you just want to do the same for LAN:

1) Create host.com.int.db or whatever you want it to be named, set the SOA to point to your internal FQDN, usually the one that maps to 192.168.0.1. Then create an NS record and point host.com to, say localfqdn.host.com. Next, add each 192.168.0.x an A record, including 192.168.0.1 itself.

2) Create 192.168.0.db and add SOA, something like:

0.168.192.in-addr.arpa. IN SOA localfqdn.host.com. hostmaster.host.com. plus all the serial, retry and expire.
Next add an NS record like so:

0.168.192.in-addr.arpa. IN NS localfqdn.host.com.

Now add all available PTR:

1.0.168.192.in-addr.arpa. IN PTR localfqdn.host.com.
2.0.168.192.in-addr.arpa. IN PTR winxp.host.com.
...
...

3) Tell named where to locate these zone files by adding appropriate entry to named.conf.

4) Don't mess with localhost and 127.0.0.1, just leave them intact in /etc/hosts.

Since you said you are somewhat familiar with DNS, you really should give djbdns a try and ditch named from now on. In production environment, dnscache (a package of djbdns) consumes about 0.01% of memory use of Bind's cache. dnscache is roughly 500% faster than Bind's cache. Note, Bind's cache will grow without bound, where in dnscache you can configure the cache size easily and efficiently. When the cache grows without bound, your box running BIND in a production environemnt is no way to get an uptime longer than 2 weeks. Not to mention when Bind doesn't even have a good security record. To put it simple, BIND's authoritative DNS server could be great, but its cache mechanism is far from useable.

sounds cool, i'll check out tinydns


Ok so from both of your posts, here is what I've got;

To do this "split-horizon" dns setup.

1. I'll need 2 instances of tindy dns
2. With the host.com.ex already setup, create a zone for host.com.in

Now, maybe I missed this, but how does tinydns know to differentiate between internal and external when answering queries for host.com, for ex. I'll have 2 www.host.com, for external it goes to a internet website, for internal it should goto local intranet.

I need to specifiy the rules in the config file correct?



Thanks free.

>> but how does tinydns know to differentiate between internal and external when answering queries

Good question. Here is how to do it to differentiate int/ext:

1) Say you have djbdns installed (it comes with dnscache, rbldns, tinydns and axfrdns), you still need to decide which component you need to configure, unlike BIND which put everything together, and often confuse people authoritative DNS server and cache-only is.
2) To install tinydns, you need to decide whether it's for ext or int. Say for ext, run this:

tinydns-conf tinydns dnslog /var/djb/tinydns 12.34.56.78

You need to mkdir /var/djb directory manually. The command above will mkdir tinydns and its subdirs for you automatically, and bind to your ext IP 12.34.56.78 on udp 53. /var/djb directory is my own preference because I have installed so many other djbware so keeping a centralize location for djb stuffs.

3) If you also need to run a ns2 (slave), you then need to install axfrdns:

axfrdns-conf axfrdns dnslog /var/djb/axfrdns /var/djb/tinydns 12.34.56.78

axfrdns listens to tcp 53, not udp. Its purpose is to do zone transfering and answering dns queries via tcp. DNS queries by default use udp 53. When it's larger than 512 bytes (non-RFC compliance), like AOL been using previously, then axfrdns is to be used to answer dns queries.

4) Now let say you also need to run a tinydns on 192.168.0.1 udp 53. Then run:

tinydns-conf localdns dnslog /var/djb/localdns 192.168.0.1

Note, you can't bind localdns to 12.34.56.78 because it's in use. BTW, there is no such thing as localdns, I invented this name just to differentiate it with int/ext.

5) Of course, the SOA and NS for internal host.com is different. You can't use ns1.host.com but you need to use localns1.host.com or whatever hostname that maps your 192.168.0.1.

6) For external, 99% of the time you don't need to setup your PTR record (even with BIND) because you will not be authoritative for your reverse. For internal, instead, you will also need to setup your 0.168.192.in-addr.arpa block.

7) Q So how does tinydns/localdns know when I query winxp.host.com (int) and www.host.com (ext)?

A tinydns/localdns doesn't know but your DNS resolver, that's dnscache.
To install dnscache:

dnscache-conf dnscache dnslog /var/djb/dnscache 127.0.0.1

or

dnscache-conf dnscache dnslog /var/djb/dnscache 192.168.0.2

Q Why can't I install dnscache on 192.168.0.1?

Because udp 53 is already in use by localdns. Therefore you either need to install it on loopback or on another computer like the example with 192.168.0.2 as shown above.

8) To tell dnscache which hosthost.com is int/ext, you need to add /var/djb/dnscache/root/servers/host.com containing 192.168.0.2 and /var/djb/dnscache/root/servers/0.168.192.in-addr.arpa as well containing 192.168.0.2.
Then a @ file /var/djb/dnscache/root/servers/@ containing root-server IPs.
So whenever you query host.com, it will ask 192.168.0.2 for the answer, if it's not found, it will try @.
Basically one server can't do these all, you need at least 2 servers.

So please google and try first, followup if you have further questions.

Thanks free for takin the time to explaining it to me.

Much appriciated. I'll let you know how it works out.