Multiple "named" instances

[Dr_Stein]

Greetings, all!

I'm moving a box to a colo facility, and I want to run 2 "named" instances, 1 listening on each card.

named-internal = eth1 (handling internal DNS)
named-external = eth0 (handling external DNS)

Each will have its own directory for zone files/etc. I don't want to use BIND views because this is a slave DNS server and views are a pain to set up.

What's the best way to do this? can I just re-name the startup scripts?

Anybody done something like this before?

[rtn]

Sure, it's really a piece of cake. Just make sure that you don't leave
ambiguous references around, like /etc/init.d/named and /etc/named.conf.
Rename everything to that they reflect the instance that they support, it will
really help in the long run to eliminate confusion. The other option, of course,
would be to put all of the config files in their own directory, like /var/named/eth0/
or something, and use the command-line to point named to the correct conf
file.

--rtn

[kashani]

I'd probably do something to similar to the following

/var/named
/var/named2/
/etc/bind/
/etc/bind2/
/var/log/named/
/var/log/named2/

In the config file I'd set the logging to specific dir and to bind to on of the the IP's. Otherwise you'll have two servers sending logs to /var/log/messages and you'll never be able to tell what's going on.

For a good logging config that auto-rotates check out
http://www.badapple.net/tech/bind-logging.html

the startup script should look roughly like
named -c /etc/bind2/named.conf

kashani

[gfdsa]

r u sure u need to binds? may be its internal options will suit you? did you hear about "views"?

[Dr_Stein]

Yeah, I don't want to use views because one of the interfaces is going to be on a site-to-site VPN while the other one is going to be a public interface (behind a static NAT..fw-1 box)

[vikwiz]

Don't you chroot named?

[Dr_Stein]

I suppose I could.
chrooting BIND isn't a foolproof solution, tho. Merely another step.

Honestly, I've never had *any* trouble with BIND. I have never personally met anyone that's had trouble with BIND. Those that I encountered elsewhere on the net that had BIND problems, were running waaay outdated versions.

It's also firewalled to the point where it really couldn't *do* anything. The only traffic that can go to/from the interface is DNS traffic anyway.

[vikwiz]

Honestly, I've never had *any* trouble with BIND. I have never personally met anyone that's had trouble with BIND. Those that I encountered elsewhere on the net that had BIND problems, were running waaay outdated versions.

I actualy had, and also I'm getting the habit to chroot everything I can easily, so less trouble I *can* have later. And bind was one of the most often used backdoor, together with sendmail. Hadn't you have the experience that after reading an advisory and check your machine, the man is already in? Last week my time was spent to clean up an infected machine, and it's still not fully functional. Yes, it was outdated (about 4 years , but even your developement machines are outdated. Keep in mind that when you see the advisory, it's already late. Your system was vulnerable then since it's existence, and I'm sure there are people who did know it. Yes, I'm not paranoid, and why should these people hunting me? but it's a fact you should know about: your system is always vulnerable fully, at least you don't know about

So these 'small steps' could have reasonable profit later.

But about the topic: I run multiple DNS on one machine, BIND on loopback interface with internal domains, and PDNS on external interfaces for the other servers (not publicaly available). PDNS queries BIND for internal domain requests. It works pretty well.

[mglauche]

a good solution is to run bind on an internal network machine and install dns-cache from the djb-dns tools on a border router .. so the external machines only access the dnscache client

[Dr_Stein]

I went ahead and chrooted named. Got bored. Fun project.