# Running multiple instances of BIND



## obamatronic (Nov 14, 2012)

I have just completed an ISC BIND class and would like to set up a test environment using one virtual machine.

I would like this virtual machine to run multiple instances of 'named' on different IP addresses.

FreeBSD will run 'named' in a chroot'd environment.

Do I just need to copy the existing named script it /etc/rc.d to another file called named1 and edit some of the entries?

If so, can anyone advise on what entries to edit?  I want both instances to use their own named.conf file.  Each named.conf file will have a unique name and directory.

Also, do I need to do something with the pid file location?  (I'm still learning FreeBSD...).


----------



## SirDice (Nov 14, 2012)

obamatronic said:
			
		

> Do I just need to copy the existing named script it /etc/rc.d to another file called named1 and edit some of the entries?


Never done this, never had the need, but this is how I would have done it.



> If so, can anyone advise on what entries to edit?  I want both instances to use their own named.conf file.  Each named.conf file will have a unique name and directory.


Probably all of them.



> Also, do I need to do something with the pid file location?


Yes, you need to make sure both instances use their own pid file. You don't want one overwriting the pid of the other.


----------



## usdmatt (Nov 14, 2012)

Named chroot's itself to /var/named when it starts. That path is a mirror or the root directory containing just the directories and files required to run named.

I would probably do the following:

Add something like the below to /etc/rc.conf


```
named_enable="YES"
named_chrootdir="/var/named" # this isn't actually needed as it's the default
named1_enable="YES"
named1_chrootdir="/var/named1"
```

I've left the conf & pid file as default but as they're chrooted, they should pick up the correct one automatically, you may have to confirm that though. (Edit: In fact you will need to change the pid file to something like /var/run/named/pid1 and change the named conf file to match as the rc system will rely on the copy not inside the chroot)

Also, the start script automatically tries to symlink /etc/namedb on start. I'm not sure whether this will cause a problem. You can disable with named_chroot_autoupdate="NO" but that also stops it mounting a devfs in the chroot which is most likely needed. If the symlink check does cause a problem, you're better off just removing that block of code from the start script.

You'll have to create /etc/rc.d/namedX scripts to start each process and you'll have to go through these making sure every reference to the $named_enabled & $named_chrootdir variables is changed to reference $namedX_... instead.

You'll also need to duplicate /var/named to /var/named1, obviously creating as many copies as you need.

Oh, and you'll need to make sure each copy is configured in named.conf to only listen on their ip as you'll get port in use errors otherwise. (In fact just go through named.conf and make sure there's nothing that stands out as being a problem. Remember that the paths will all be relative to the chroot so most (if not all) of those should be able to stay as they are.

At this point it still might not work, there may be stuff I've missed or it might not be possible at all.

Alternatively, you could look at running multiple jails inside your VM, effectively giving you multiple, completely independent FreeBSD installs. Using one of the jails management ports it may actually be easier.


----------



## mamalos (Nov 14, 2012)

Also, I would place the rc script in /usr/local/etc/rc.d in order to avoid issues with mergemaster(8) on updating. Not that it's crucial...


----------



## lockdoc (Nov 14, 2012)

Hey, just as an alternative to make things easier, you could setup multiple jails with bind inside.


----------



## obamatronic (Nov 14, 2012)

@usdmatt, that you so much for the detailed answer.

I like the jail idea.  I have been reading a FreeBSD book and there is a section on creating jails.  That may just be the simplest way to go.  I'll give that a shot first.


----------



## suntzu (Nov 15, 2012)

From my experience you cannot install the lastest version of BIND (ex. BIND 9.9) if the jail has already named install(which is in base).


----------



## chatwizrd (Nov 15, 2012)

suntzu said:
			
		

> From my experience you cannot install the lastest version of BIND (ex. BIND 9.9) if the jail has already named install(which is in base).



Why not? That doesnt make sense.


----------



## lockdoc (Nov 16, 2012)

suntzu said:
			
		

> From my experience you cannot install the lastest version of BIND (ex. BIND 9.9) if the jail has already named install(which is in base).



BIND 9.9.1-P3 is running in my Jail

When you install bind, you need to check the option

```
[*]    Replace base BIND with this version
```


----------

