if the authoritative nameserver (the real one) for that domain let you do zone transfer, you can create a local fake slave dns for that domain, so each time they change a record, your slave dns get automatically updated.
For both workarounds you should use 127.0.0.1 as a primary nameserver in resolv.conf
Yes, I am using the latest Distro, which includes Asterisk 126.96.36.199. I’ve also tested on the prior version of the Distro (using Asterisk 1.8.6).
I also have the workaround set-up on my system. The only reason that I found out that the bug still exists is that I didn’t realize that enabling SRV lookup (as required by Callcentric’s set-up instructions) essentially negates the hosts file entry for Callcentric and causes Asterisk to have to do DNS lookups. The other day, my internet went down and all the Aastra phones reported “no service.”
No it really is a bug. What happens is chan_sip is blocking so when it can not resolve the FQDN it blocks all inbound SIP request until it can resolve it. They have stated it is fixed in Asterisk 1.8 but I have yet to test it since all of our systems have work arounds built in for this and it would take break those.
Can you give a step-by-step explanation of how to make your local nameserver to be authoritative for the external domain?
I disagree with your contention that this is not a bug. Most programs that utilize DNS do not hang when DNS is absent. Rather, they are programmed to understand that DNS is not present, and to carry on with whatever they can accomplish in the absence of DNS resolution.
By way of example, my router continues to route local traffic, even when DNS services are down. My browser can continue to browse to local HTTP servers, even when DNS and the internet are down.
Asterisk’s behavior in the face of failed DNS resolution, which involves just repeating the attempt to lookup the failed DNS (instead of moving on to another task that doesn’t require it) is, in my view, a bug.
My current workaround is to set all trunks using IP addresses. I believe that the hosts file is too hidden and too easy to forget about.
If, for example, your trunk provider changes its IP address, it is easy to remember that you’re using IP addresses if you programmed them in the trunk settings, because they’ll jump out at your when you examine the trunk settings, and when you ping your provider by name, the IP won’t match.
My future workaround is going to involve changing nsswitch.conf so that CentOS uses DNS first and then the hosts file (instead of the other way around, which is the default).
My theory is that if DNS is down, I don’t really care what IP address Asterisk tries to reach because it won’t get anywhere until internet access is restored. If DNS is up, I’d rather that the system use the current, real DNS entry, than a hosts file that I set-up two years ago (and which may no longer be current).
I’m sure this all seems obvious to you, but it isn’t to me. I’ve never installed or configured Bind and never used Webmin. While this is a good starting point, it isn’t the step-by-step instruction I’d need. I’m willing to write a set of good instructions on how to install and configure Bind and webmin (as I’ve done with the FreePBX Distro), but I need someone to walk me through how to do it first.
The FreePBX Distro doesn’t include Bind9 (as far as I can tell) or Webmin. So, for a step-by-step set of instructions, I’d want you to start with how to install Bind9, and then how to configure it.
I’m also pretty sure that we’ll need to modify /etc/resolv.conf to change it so that the only listed nameserver is 127.0.0.1. If you wanted to consult your local nameserer and then some external servers, I’m guessing that you’d also want to enable the “strict-order” feature in dnsmasq.conf. I’m not sure, however, because I don’t really understand the relationship between dnsmasq.conf and named.conf - it may be that named.conf override dnsmasq.conf.
And again, it’d be soooo much better if Digium just fixed Asterisk!
Yes, that would be ideal. In fact, if the internet is down, I don’t even care if Bind gives the correct answer. When the internet is down, any answer is fine. If we could configure Bind to simply forward when the internet is up, and provide a dummy answer (like 188.8.131.52) when the internet is down, that would completely resolve the problem, for now.