If you run Asterisk you may have encountered this issue: Your Internet connection goes down, and so does your ability to call from extension to extension, even between extensions on your local network. This is a long-standing bug in Asterisk (exactly the sort of bug that drives people to try alternatives such as FreeSWITCH) but let’s say that for whatever reason you need to stick with Asterisk, so you’d like to find a way to make that bug go away.  Without going into all the technical details, the reason that calls fail is that Asterisk can’t access a DNS server.  I’ve read several reports that say the easiest solution is to install the BIND DNS server  on the same machine as your Asterisk server.  If you are also running Webmin on the server, installing and configuring BIND is a relative piece of cake.  So here’s how it’s done.  Please note that most of the images below can be enlarged by clicking on them, and that I have installed the StressFree theme in Webmin, so if it looks a little different from what you’re used to seeing, that’s probably why.

To start with, log into Webmin, click on “Servers”, then click on “BIND DNS Server” (if you don’t find it there, try looking in “Un-used Modules”):

Assuming you have not previously installed BIND, you’ll get a screen like this.  Just click where it says “Click here”:

You will then see this screen come up as BIND is installed. Just let it run to completion and (assuming it installs successfully) click on “Return to BIND DNS Server” at the bottom of the page:

Next, because you don’t yet have an /etc/named.conf file, you’ll see this page.  Click the button for “Setup nameserver for internal non-internet use only” (don’t worry, we’ll fix it in the next steps), then click the bar that says “Create Primary Configuration File and Start Nameserver”:

At this point BIND is installed and running, but it probably isn’t doing what you want it to, and your system isn’t using it. So the first thing we need to do is tell it where to go when it needs to do a DNS lookup. You should be seeing a page that looks like this — click on “Forwarding and Transfers”:

When you get to the following screen, check “Yes” next to “Lookup directly if forwarders cannot?”  You also need to enter one or more addresses of DNS servers that BIND can access when it needs to pull a DNS record.  You might want to give some thought to which DNS servers you want to use, and in what order, before you start entering them. You can enter up to three IP addresses of DNS servers, and then click “Save”. This will throw you out to the previous screen, and if by some chance you want to enter even more DNS servers, you can click on “Forwarding and Transfers” again to come back and enter up to three more servers, until you are finished.  In this example, I have already entered the IP addresses of my router’s DNS Server as the top priority pick,  followed by two Google DNS Server addresses.

Once you have done this, you are through configuring BIND directly, but there are two more things we need to do. The first is to make sure that the BIND server starts each time we restart the machine. To do that, go to Webmin’s “System” page and then click on “Bootup and Shutdown”:

This is a long page so I’m not showing all of it — what you have to do is find the entry for named and check the box next to it:

Then go to the bottom of the page and click “Start on Boot”:

At this point BIND is running, and should be using the correct DNS servers, and is set to start at bootup, but your server still isn’t using it for its DNS queries. To get it to do that, go to Webmin’s “Networking” page and click on “Network Configuration”:

Once on the Network Configuration page, click on “Hostname and DNS Client”:

Once on the Hostname and DNS Client page, what you need to do is make the first entry in the DNS Servers list 127.0.0.1. If you trust BIND to always be operating, that’s the only entry you need. I didn’t quite trust BIND that much (actually, what I didn’t trust was my ability to set this up correctly) so I set the DNS server in the router as the secondary DNS address. You could use any DNS server as the secondary, or you could choose to just enter the 127.0.0.1 address to use BIND and let it go at that. Personally, I feel a lot more comfortable having a “fallback” DNS. Don’t forget to click “Save” when you are finished making changes here:

That’s all there is to it, as far as I know (if you think I’ve missed anything or done something wrong, the comment section is open!). If you’re like me, the next question you will have is, “How do I know it’s working?” And the easiest way to do that is to go to a Linux command prompt and “dig” some site you have not been to recently twice in a row. Here’s an example, using cnn.com — the part we are interested in is in red:

# dig cnn.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> cnn.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8274
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 9

;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                287     IN      A       157.166.224.25
cnn.com.                287     IN      A       157.166.224.26
cnn.com.                287     IN      A       157.166.226.25
cnn.com.                287     IN      A       157.166.226.26
cnn.com.                287     IN      A       157.166.255.18
cnn.com.                287     IN      A       157.166.255.19

;; AUTHORITY SECTION:
.                       76691   IN      NS      i.root-servers.net.
.                       76691   IN      NS      j.root-servers.net.
.                       76691   IN      NS      k.root-servers.net.
.                       76691   IN      NS      l.root-servers.net.
.                       76691   IN      NS      m.root-servers.net.
.                       76691   IN      NS      a.root-servers.net.
.                       76691   IN      NS      b.root-servers.net.
.                       76691   IN      NS      c.root-servers.net.
.                       76691   IN      NS      d.root-servers.net.
.                       76691   IN      NS      e.root-servers.net.
.                       76691   IN      NS      f.root-servers.net.
.                       76691   IN      NS      g.root-servers.net.
.                       76691   IN      NS      h.root-servers.net.

;; ADDITIONAL SECTION:
b.root-servers.net.     386178  IN      A       192.228.79.201
d.root-servers.net.     402826  IN      A       128.8.10.90
d.root-servers.net.     230000  IN      AAAA    2001:500:2d::d
f.root-servers.net.     370827  IN      A       192.5.5.241
g.root-servers.net.     463754  IN      A       192.112.36.4
h.root-servers.net.     374116  IN      A       128.63.2.53
h.root-servers.net.     517382  IN      AAAA    2001:500:1::803f:235
j.root-servers.net.     185528  IN      A       192.58.128.30
j.root-servers.net.     578747  IN      AAAA    2001:503:c27::2:30

;; Query time: 26 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 12:45:41 2011
;; MSG SIZE  rcvd: 512

# dig cnn.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> cnn.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8277
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 9

;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                223     IN      A       157.166.255.19
cnn.com.                223     IN      A       157.166.224.25
cnn.com.                223     IN      A       157.166.224.26
cnn.com.                223     IN      A       157.166.226.25
cnn.com.                223     IN      A       157.166.226.26
cnn.com.                223     IN      A       157.166.255.18

;; AUTHORITY SECTION:
.                       76627   IN      NS      c.root-servers.net.
.                       76627   IN      NS      d.root-servers.net.
.                       76627   IN      NS      e.root-servers.net.
.                       76627   IN      NS      f.root-servers.net.
.                       76627   IN      NS      g.root-servers.net.
.                       76627   IN      NS      h.root-servers.net.
.                       76627   IN      NS      i.root-servers.net.
.                       76627   IN      NS      j.root-servers.net.
.                       76627   IN      NS      k.root-servers.net.
.                       76627   IN      NS      l.root-servers.net.
.                       76627   IN      NS      m.root-servers.net.
.                       76627   IN      NS      a.root-servers.net.
.                       76627   IN      NS      b.root-servers.net.

;; ADDITIONAL SECTION:
b.root-servers.net.     386114  IN      A       192.228.79.201
d.root-servers.net.     402762  IN      A       128.8.10.90
d.root-servers.net.     229936  IN      AAAA    2001:500:2d::d
f.root-servers.net.     370763  IN      A       192.5.5.241
g.root-servers.net.     463690  IN      A       192.112.36.4
h.root-servers.net.     374052  IN      A       128.63.2.53
h.root-servers.net.     517318  IN      AAAA    2001:500:1::803f:235
j.root-servers.net.     185464  IN      A       192.58.128.30
j.root-servers.net.     578683  IN      AAAA    2001:503:c27::2:30

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 12:46:45 2011
;; MSG SIZE  rcvd: 512

Notice how on the first run, it takes 26 msec to do the lookup, because BIND doesn’t have that address cached yet, whereas on the second run it only takes 1 msec to do the lookup!  Could that perhaps improve system performance?  I’ll bet it could! And the SERVER line tells us that it is indeed using our BIND server (127.0.0.1) – if it were using, say, our router’s DNS server then that line would show this:

;; SERVER: 192.168.0.1#53(192.168.0.1)

The idea here is that when your Internet connection takes a dive, Asterisk will still be finding a working DNS server and therefore won’t tank.  That, at least, is the theory I’ve seen on several web sites.  The ONLY thing I am showing here is how to set up BIND using Webmin, and I won’t even guarantee that I’m doing that 100% correctly.  I definitely do not guarantee that it will actually work as intended — you’ll have to test that yourself.  Doing a real test would mean disconnecting your cable or DSL modem, etc. from your router for several hours or days to see if the phones continue to work, and in most households or businesses that idea will go over like a lead balloon.  However, feel free to give it a good test if you like and report the results in the comments.

You may wonder why I selected “Setup nameserver for internal non-internet use only” in the fourth screenshot.  Obviously, that description is not entirely accurate.  The real difference is that if you select that instead of the default “Setup as an internet name server, and download root server information”, it won’t create a “root” DNS zone, which you simply don’t need for this application.  You can use the other option if you want to, but it will download additional information and increase the complexity of your setup.  Either way, you should be able to access the Internet, because we set up DNS forwarding.  If by some chance this BIND server is going to act as a nameserver for your entire network, and you don’t mind the additional traffic and complexity (and it’s the additional traffic that scares me the most, since I have no idea what it’s actually downloading nor how often it’s doing it), then by all means feel free to use the second option.  All I will say is that I used the first. and it works fine, and I’ve seen at least one instance where this same thing is set up using a method other than Webmin, and except for the order of statements it uses an /etc/named.conf file that is identical to what Webmin produces when configured as I have shown here (in other words, no “zones” at all).  I’m just waiting for some Linux purist to say this isn’t the “right” way to do this but keep the goal in mind here — all we are trying to do is work around a bug in Asterisk that should have been fixed years ago, not set up a DNS server to feed an entire subnet.  But again, you can feel free to use whichever of the options you like — it should work either way.

(By the way, if after reading the above you have “setup remorse” — you know, that feeling you get after you’ve installed something that you should have picked a different option — you can get a “do-over” by simply deleting or moving/renaming /etc/named.conf.  If you then exit Webmin’s BIND module and come back in, it should see that named.conf doesn’t exist and start you over at the fourth screen shown above.  Of course, you will lose anything you have already configured from within that module.  If you originally selected the option to download the root server information, I think that’s at least partly stored in the file /etc/db.cache, so you could move or remove that file to make sure it’s not used, however I’m not sure if any other files are or were also downloaded.  That particular file is very small so I’m not worried about that one per se, it’s just that the way things are worded on a couple of pages I read, I don’t know if that’s all it downloads, or if at some point in the middle of the night it rises up and tried to cache all the DNS information for the Internet, or just exactly what it does.  Sometimes I wish people would just give a sentence or two of additional information, so you have a better idea of what’s the right thing to do when you’re setting up something like this.)

Now, if you are a True Linux Geek who somehow stumbled across this article, and are disappointed that it isn’t much more complicated, I’ll refer you to this page.  If you can figure all THAT out, you should be getting paid the big bucks as the networking expert that you are! 🙂