Reviews:
 ·Start Communicat..
 ·Cogeco Cable
 ·voip.ms
| [Asterisk] Temporary failure in name resolutionanyone have any idea how to fix this error?
It doesn't seem to cause any problems just kind of annoying.
[2013-03-10 06:00:04] ERROR[3043] netsock2.c: getaddrinfo("toronto.voip.ms", "(null)", ...): Temporary failure in name resolution
[2013-03-10 06:00:04] WARNING[3043] acl.c: Unable to lookup 'toronto.voip.ms'
[2013-03-10 06:00:09] ERROR[3043] netsock2.c: getaddrinfo("toronto.voip.ms", "(null)", ...): Name or service not known
[2013-03-10 06:00:09] WARNING[3043] acl.c: Unable to lookup 'toronto.voip.ms'
|
|
| The issue tracker mentioned toronto2.voip.ms as being unreachable and redirected to toronto.voip.ms early today.
Both now resolve to different addresses (199.21.149.36, 198.144.158.125), so hopefully this is no longer appearing in your log. |
|
|
|
| well this has been happening for a log time i always see it a few times a day in the log file. I never noticed any issues so i just have been ignoring it.
Now im wondering what is causing it so maybe i can fix it. |
|
| reply to rudeboy24
I wonder if the ISP occasionally has trouble servicing DNS requests?
If so, this is easily remedied by using public DNS servers as backup.
64.140.120.22 Start Communications
64.140.120.21 Start Communications
198.53.64.7 Northern Telephone Ontario CA
208.67.222.222 OpenDNS
208.67.222.220 OpenDNS
8.8.4.4 Google
8.8.8.8 Google
My personal preference is to set up a caching DNS server on the PBX system, and use it as the DNS server for the rest of the devices in the house.
The forwarders section in /etc/named.caching-nameserver.conf would resemble this:
forwarders { 64.140.120.22;
64.140.120.21;
198.53.64.7;
208.67.220.222;
208.67.220.220;
8.8.8.8;
8.8.4.4;
};
|
|
MartinMVoIP.msPremium,VIP
join:2008-07-21 | reply to rudeboy24
When this happen it's because the DNS daemon is unable to query the host for toronto.voip.ms
You can test like this when connected via SSH to the server
host toronto.voip.ms
It should return something like this:
toronto.voip.ms has address 199.21.149.36
Is the server under DHCP or Static IP? If Static IP, make sure /etc/resolv.conf has proper DNS IP Addresses that can handle DNS requests. If it's DHCP, make sure you have no firewall, nat rules etc blocking UDP port 53 (DNS). You could also try to use different DNS servers as in the example provided by scadageo by editing /etc/resolv.conf and adding lines like this "nameserver x.x.x.x" without the quotes, replacing the x.x.x.x by an actual DNS server.
Some might suggest to add the IP to /etc/hosts. Do not do that, this will break any fail over mechanisms over DNS that we might configure. Make sure you fix the DNS issue in the first place.
If you can't find the issue with your DNS, you could try to run a caching name server as suggested by Scadageo.
The temporary switch of IP we had with Toronto should not give you this type of issue. The only thing it does is return a different IP Address.
Let us know if you and how you resolve the issue.
Regards,
--
Martin - VoiP.ms |
|
Reviews:
·Start Communicat..
·Cogeco Cable
·voip.ms
1 edit | i added this to /etc/resolv.conf yesterday and still getting the error ..im going to try removing 192.168.1.1 (Smoothwall Router) and see if it fixes it.
127.0.0.1
192.168.1.1
64.140.120.22
64.140.120.21
208.67.222.222
208.67.222.220
8.8.4.4
8.8.8.8
|
|
MartinMVoIP.msPremium,VIP
join:2008-07-21 | said by rudeboy24:i added this to /etc/resolv.conf last yesterday and still getting the error ..im going to try removing 192.168.1.1 (Smoothwall Router) and see if it fixes it.
127.0.0.1
192.168.1.1
64.140.120.22
64.140.120.21
208.67.222.222
208.67.222.220
8.8.4.4
8.8.8.8
Remove 127.0.0.1 as well, unless there's a reason you have this there? Even with a caching DNS running you don't need that. --
Martin - VoiP.ms |
|
| removed the 127.0.0.1 as well ...will report back tomorrow with the results.
also forgot to mention the server is a static ip (192.168.1.3) behind a Smoothwall router |
|
| said by rudeboy24:removed the 127.0.0.1 as well ...will report back tomorrow with the results.
also forgot to mention the server is a static ip (192.168.1.3) behind a Smoothwall router
Perhaps it would be more efficient to configure the DNS server addresses in Smoothwall?
Smoothwall & OpenDNS. |
|
| That's how i have it done. been like that for years. 
i thought maybe that was why it was getting that error, but it seems to be still doing it . |
|
| said by rudeboy24:That's how i have it done. been like that for years. :)
i thought maybe that was why it was getting that error, but it seems to be still doing it .
Strange that the DNS fail-over isn't functioning.
Did this start happening after the switch to Start Communications?
Is there internet access when this occurs?
Out of curiosity, what do the following show?
dig @192.168.1.1 toronto.voip.ms
dig @192.168.1.3 toronto.voip.ms
|
|
Reviews:
·Start Communicat..
·Cogeco Cable
·voip.ms
1 edit | It was happening before Start.
no disconnects from Start.
dig @192.168.1.1 toronto.voip.ms
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @192.168.1.1 toronto.voip.ms
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 27794
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;toronto.voip.ms. IN A
;; ANSWER SECTION:
toronto.voip.ms. 66 IN A 199.21.149.36
;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Mar 14 00:12:45 2013
;; MSG SIZE rcvd: 49
dig @192.168.1.3 toronto.voip.ms
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @192.168.1.3 toronto.voip.ms
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;toronto.voip.ms. IN A
;; ANSWER SECTION:
toronto.voip.ms. 62 IN A 199.21.149.36
;; Query time: 5 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Thu Mar 14 00:12:48 2013
;; MSG SIZE rcvd: 49
|
|
| Currently, I'm wonder if that's an asterisk dnsmgr issue. |
|
| not sure where to find dnsmgr ..is there some config files for it?
I forgot to mention im running FreePBX 2.10.1.8 (Asterisk Ver. 1.8.12.0) |
|
| asterisk -rx "sip show registry"
The 2nd column will show if asterisk's dnsmgr is being used.
Config file is /etc/asterisk/dnsmgr.conf |
|
| reply to rudeboy24
1.8.12.0 - main/netsock2.c - line 264, gai_strerror(e) is returning the actual system error message.
It's not asterisk, and what's strange is the failure after the addition of the public DNS servers.
It's time to capture some packets to figure out what's really happening. |
|
Reviews:
·Start Communicat..
·Cogeco Cable
·voip.ms
| seems when the Asterisk box sends a dns query to the smoothwall it is sending a ICMP packet back and it shows unreachable.
51559 7737.397832 192.168.1.3 192.168.1.1 DNS Standard query A toronto.voip.ms
51560 7737.398476 192.168.1.1 192.168.1.3 ICMP Destination unreachable (Port unreachable)
|
|
| reply to rudeboy24
It shouldn't be an issue (many sites filter pings) as long as it answers the DNS request.
Was there an asterisk log entry at the same time?
Was there a DNS standard query response?
Here's a good link regarding tools for testing DNS servers:
» DNS Servers
Mele20's post references namebench.
It's a nice tool, but be aware that namebench's list IP addresses hasn't been updated in long time, so messages such as "www.google.com is hijacked" followed by a list of IP addresses will appear. |
|
Reviews:
·Start Communicat..
·Cogeco Cable
·voip.ms
| It shows the ERROR[3043] & WARNING[3043] in the asterisk log at the same time as Wireshark captures those errors.
Looks like it tries 4 times and doesn't get a dns query response.
Also I tried a nslookup from my windows 7 box and it gets query result.
Thanks SCADAGeo for taking the time to help me out |
|
| reply to rudeboy24
said by rudeboy24:seems when the Asterisk box sends a dns query to the smoothwall it is sending a ICMP packet back and it shows unreachable.
51559 7737.397832 192.168.1.3 192.168.1.1 DNS Standard query A toronto.voip.ms
51560 7737.398476 192.168.1.1 192.168.1.3 ICMP Destination unreachable (Port unreachable)
The "ICMP Destination unreachable (Port unreachable)" is telling. I know next to nothing about Asterisk, and exactly nothing about dnsmgr, but in general there are typically two things that could cause this. Either a firewall is rejecting (not dropping, but actively rejecting) the query to UDP port 53 (DNS) from the source machine (the Asterisk box) to the destination machine (the DNS server) for some reason, or there's no process on the destination machine (the machine that's supposed to be the DNS server) that has UDP port 53 open. None of this has anything to do with ping, unless dnsmgr sends pings, in which case all bets are off. Absent anything else strange that dnsmgr is doing, it's about UDP port 53 from the Asterisk box to the DNS server(s) that the Asterisk box knows about.
There was a lot of talk in this thread about multiple DNS servers, but also you say that you are (or were) using only the Smoothwall as a DNS server/forwarder for the Asterisk box.
If the Smoothwall is the only DNS server, then the firewalls in question are those on the Asterisk box and the Smoothwall, and the DNS server in question is the server/forwarder on the Smoothwall. In particular, it's not the DNS servers to which the Smoothwall forwarder forwards requests. The ICMP port unreachable is being delivered to the Asterisk box, and this wouldn't happen if the Smoothwall DNS forwarder received the query since, in that case, the port to which the Asterisk box sent the query was reachable; if the forwarded query (really a new query originating on the Smoothwall) caused the port unreachable, that ICMP message would be received by the Smoothwall but wouldn't go back to the Asterisk box. Assuming the firewalls aren't randomly getting confused, maybe there's an intermittent problem with the DNS forwarder on the Smoothwall. Maybe it's crashing and restarting, or reloading on a detected WAN IP address change, or otherwise misbehaving.
On the other hand, if the Asterisk box uses multiple DNS servers, then the firewalls in question also include any upstream firewalls, and the DNS server in question is the one to which the Asterisk box sent the query.
The point of all this is that, unless dnsmgr is somehow involved, the ICMP port unreachable message is a tipoff that the problem is about firewall rejects or DNS server(s) not being up, where the DNS server(s) are those which are known to the Asterisk box. |
|
