[Home]

Summary:ASTERISK-09259: spurious DNS lookups / SRV record lookups
Reporter:Robert Lister (rlister)Labels:
Date Opened:2007-04-13 09:23:21Date Closed:2007-07-11 19:58:51
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:This might be two issues. My asterisk SIP stuff keeps grinding to a halt and this seems to occur when the DNS servers are not/slow to respond.

Asterisk seems to be making many many spurious DNS and SRV lookups for things (SIP registrations and apparently when there is a hint in the style of
"SIP/xxx&Local/xxx@agent_call")

I think there is a bug ID for the hints one, but it got closed:
http://bugs.digium.com/view.php?id=9057

In some cases I have put the SIP registration config as an IP address, which
implies no DNS lookup at all. (But I suppose it is still trying to find SRV
records for that specific service, despite the fact that I configured the port number explicitly in the register => statement.)

Is there a way to limit the SRV lookup behaviour only to outbound
Dial() command, rather than have it lookup in unexpected ways in sip.conf?

The problem I am seeing is that occasionally if asterisk is unable to lookup
these DNS requests, the SIP channel locks and processing of subsequent sip
registrations stops. If you have lots of "register =>" where "lots" is >
about 8 in our case, everything grinds to a halt and all the phones are
unable to register, asterisk marks all phones as UNREACHABLE, as although the
phones are sending the packets back, asterisk is not processing them.
(There is a comment in dns.h to this effect! So I am trying to minimise the chances of this problem occuring.)

I have tried to mitigate this by installing a local instance of BIND and
having it resolve locally to reduce reliance on remote DNS servers for all
these entirely spurious DNS lookups. We shall see how this affects
things.


****** ADDITIONAL INFORMATION ******


sip.conf registrations look like:

register => 5459*711:<pass>:5459*711@204.61.208.90:5060
register => 5459*713:<pass>:5459*713@204.61.208.90:5060
register => 5459*714:<pass>:5459*714@204.61.208.90:5060
register => 5459*716:<pass>:5459*716@204.61.208.90:5060
register => 5459*717:<pass>:5459*717@204.61.208.90:5060
register => 5459*718:<pass>:5459*718@204.61.208.90:5060

...etc.

Most SIP phones have "qualify=5000" or "qualify=20000" enabled in sip.conf

hints look like:

exten => 713,hint,SIP/713&Local/713@agent_call
exten => 714,hint,SIP/714&Local/714@agent_call
exten => 716,hint,SIP/716&Local/716@agent_call
exten => 717,hint,SIP/717&Local/717@agent_call
exten => 718,hint,SIP/718&Local/718@agent_call

Note that this works, but the "Local" channel always shows the user
as available, even when they are not.

Since AgentCallBackLogin() is being deprecated and I had
some problems with chan_agent anyway, we replaced that functionality with
dialplan logic, but that means we can no longer do a hint on Agent channels.
I have not found a workaround for this yet, or a way to dynamically update hints. This is problematic for us as it means that the SUBSCRIBE / busy lamp features do not work properly. That is a seperate issue though.

Here is a packet dump of the DNS requests from the box:

31.223254 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
31.223604 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
31.917844 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
31.918176 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
31.939929 192.168.10.1 -> 192.168.10.2 DNS Standard query A 736&SIP/43736.linx.net
31.940243 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
34.267517 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
34.267760 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
34.289817 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
34.290023 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
34.842002 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
34.842309 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
35.327746 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
35.328042 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
35.349502 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
35.349701 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
35.372156 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
35.372353 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
39.351008 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.361641 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.361947 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
44.362721 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.362921 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
44.363357 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.363550 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
44.364026 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.364222 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
44.364693 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.364889 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
44.365373 192.168.10.1 -> 192.168.10.2 DNS Standard query A agent_call.linx.net
44.365566 192.168.10.2 -> 192.168.10.1 DNS Standard query response, No such name
 0.000249    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
 0.000357    127.0.0.1 -> 127.0.0.1    DNS Standard query SRV _sip._udp.voiptalk.org.linx.net
 0.000484    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
 2.652306    127.0.0.1 -> 127.0.0.1    DNS Standard query SRV _sip._udp.204.61.208.90
 2.652472    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
 2.652707    127.0.0.1 -> 127.0.0.1    DNS Standard query SRV _sip._udp.204.61.208.90.linx.net
 2.652836    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
 3.652433    127.0.0.1 -> 127.0.0.1    DNS Standard query SRV _sip._udp.204.61.208.90
 3.652560    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
 3.652777    127.0.0.1 -> 127.0.0.1    DNS Standard query SRV _sip._udp.204.61.208.90.linx.net
Comments:By: Olle Johansson (oej) 2007-04-16 09:28:29

There are several issues here, as you say
1. We should *not* issue SRV when there's a given port number
2. We should *not* issue DNS queries on IP addresses
3. Why are we issuing DNS queries on agent_call, which seems to be a context??

Can you trace down where the agent_call comes into play into DNS by setting a high debug level and trying to find out what happens in your dial plan? Also, try to locate this pattern
  "DNS Standard query A 736&SIP/43736.linx.net"

I'll put on my list to check 1 and 2 while waiting for feedback on 3.
By: Robert Lister (rlister) 2007-04-16 10:02:56

I can reproduce the hints problem described here.

If I have in hints, something like:

exten => 702,hint,SIP/702&Local/702@foobar
exten => 706,hint,SIP/706&Local/706@foobar
exten => 707,hint,SIP/707&Local/707@foobar
exten => 708,hint,SIP/708&Local/708@foobar
exten => 711,hint,SIP/711&Local/711@foobar
exten => 713,hint,SIP/713&Local/713@foobar
exten => 714,hint,SIP/714&Local/714@foobar
exten => 716,hint,SIP/716&Local/716@foobar
exten => 717,hint,SIP/717&Local/717@foobar
exten => 718,hint,SIP/718&Local/718@foobar
exten => 719,hint,SIP/719&Local/719@foobar
exten => 723,hint,SIP/723&Local/723@foobar
exten => 736,hint,SIP/736&SIP/43736

The DNS lookups only get attempted when a client (i.e. X-Lite) requests update about via SUBSCRIBE SIP messages, for example:

<-- SIP read from 192.168.1.240:39150:
SUBSCRIBE sip:707@192.168.1.35 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.240:39150;branch=z9hG4bK-d87543-494415720e372722-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:710@192.168.1.240:39150>
To: <sip:707@linx.net>;tag=as7a3249fc
From: "Robert Lister"<sip:710@linx.net>;tag=9c5fac62
Call-ID: MzNjODRjNjYyMGQwY2UzMDM4ZDYyZTQ5NTlkZTg3ZTg.
CSeq: 7 SUBSCRIBE
Expires: 60
User-Agent: X-Lite release 1006e stamp 34025
Authorization: <..this bit snipped..>
Event: presence
Content-Length: 0

Here are the DNS lookups seen:
237.289429    127.0.0.1 -> 127.0.0.1    DNS Standard query A 736&SIP/43736.linx.net

.. so it's not just the ones in @context, but seems to be anything that has
& in it.

235.874996    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
235.875650    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
235.896992    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
235.897370    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
235.940802    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
235.941180    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
235.962622    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
235.962858    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
235.984878    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
235.984982    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
236.051143    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
236.051250    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
236.118910    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
236.119026    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
236.154397    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
236.154504    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
236.229340    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net
236.229449    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
237.290004    127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name
238.053279    127.0.0.1 -> 127.0.0.1    DNS Standard query A foobar.linx.net

When I exit the client, the DNS lookups stop happening. (the other type of DNS lookups I mentioned relate to "register => " entries in sip.conf, and they continue to happen.)
By: Olle Johansson (oej) 2007-04-18 04:56:51

This is indeed an interesting bug report. A local channel context gets used in SIP DNS lookups. Wow.
By: Olle Johansson (oej) 2007-05-09 08:56:47

I haven't had time to check this lately, but weren't able to repeat it earlier on.
By: Joshua C. Colp (jcolp) 2007-05-09 11:56:15

Fixed in 1.2 as of revision 63610, 1.4 as of revision 63611, and trunk as of revision 63613.