[Home]

Summary:ASTERISK-10532: Bad DNS lookups on ENUMLOOKUP - various problems
Reporter:John Todd (jtodd)Labels:
Date Opened:2007-10-15 12:54:26Date Closed:2008-01-15 20:28:18.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Functions/func_enum
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:1) ENUMLOOKUP apparently is doing an "A" record lookup on the domain in the From: header.  Why is this?  It's bad, slow, and leaks information.  Should not happen; no reason for it to happen.

2) Failures on ENUMLOOKUP on NAPTR records on ISN-style lookups.  The lookups just outright fail, though the DNS returns the correct NAPTR back to Asterisk.  Not sure if this is an ISN-style problem or if this is an issue with all NAPTRs.


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

client:
 Client is configured with a bogus domain name blahmoofoo.com in the From: header.  Shouldn't matter.


dialplan for test:

[sip-from-world3]
exten => _X.,1,Set(ENUM=${ENUMLOOKUP(${EXTEN},sip,,1,freenum.org)})
exten => _X.,n,Hangup


Dialed pattern:
 0*270@www2.freenum.org  (www2.freenum.org is the Asterisk server in question)


Console output from my tests:

 == Using TOS bits 0
   -- Executing [0*270@sip-from-world:1] Set("SIP/blahmoofoo.com-86f84000", "ENUM=0@mit.edu") in new stack
   -- Executing [0*270@sip-from-world:2] Hangup("SIP/blahmoofoo.com-86f84000", "") in new stack
 == Spawn extension (sip-from-world, 0*270, 2) exited non-zero on 'SIP/blahmoofoo.com-86f84000'
   -- Executing [h@sip-from-world:1] Hangup("SIP/blahmoofoo.com-86f84000", "") in new stack
 == Spawn extension (sip-from-world, h, 1) exited non-zero on 'SIP/blahmoofoo.com-86f84000'
[Oct 15 18:06:23] NOTICE[21920]: cdr.c:432 ast_cdr_free: CDR on channel 'SIP/blahmoofoo.com-86f84000' not posted

Comments:By: John Todd (jtodd) 2007-10-15 12:55:00

Enclosed tcap file with both DNS and SIP messages during call test.
By: John Todd (jtodd) 2007-10-15 13:05:32

OK, some incorrect debugging data in the "Additional Information" page.  The console on that example was not typical.  Here is the typical output during this failure mode:

*CLI>   == Using TOS bits 0
   -- Executing [0*270@sip-from-world:1] Set("SIP/blahmoofoo.com-870b6000", "ENUM=") in new stack
   -- Executing [0*270@sip-from-world:2] Hangup("SIP/blahmoofoo.com-870b6000", "") in new stack
 == Spawn extension (sip-from-world, 0*270, 2) exited non-zero on 'SIP/blahmoofoo.com-870b6000'
   -- Executing [h@sip-from-world:1] Hangup("SIP/blahmoofoo.com-870b6000", "") in new stack
 == Spawn extension (sip-from-world, h, 1) exited non-zero on 'SIP/blahmoofoo.com-870b6000'
[Oct 15 18:19:42] NOTICE[1539]: cdr.c:432 ast_cdr_free: CDR on channel 'SIP/blahmoofoo.com-870b6000' not posted


Additional notes:

  1) This is Asterisk running on an OpenBSD 4.1 system.

  2) My resolving nameservers are 204.91.156.197 and 192.148.252.133

  3) The "search" line in /etc/resolv.conf contains "freenum.org"
By: James Golovich (jamesgolovich) 2007-10-15 15:56:30

Looking into the first issue, the A record lookups by chan_sip.c

Are these INVITEs coming from a device that doesn't have a peer setup on the asterisk box?  If thats the case then the gethostbyname is happening in sip_devicestate.  That's the only way I've been able to get chan_sip to do a lookup on a hostname in the From field (there might be other ways, just not that I have found)

I'm not really sure how to "fix" this, just wanted to point out whats causing it.    If the names doesn't resolve then it returns INVALID and if it does resolve then it returns UNKNOWN.

Maybe someone that knows more about the devicestate system can shed some light on this
By: John Todd (jtodd) 2007-10-15 17:38:16

James: You are correct in your comments about the first issue ("A" record lookups).  The INVITEs are coming from devices which do not have a peer entry defined; they are being associated with the [general] settings in sip.conf.
By: John Todd (jtodd) 2007-10-15 18:01:42

Incomplete (fluff omitted) debug output from a test similar to the ones I performed in the packet trace included here:

[Oct 15 23:17:04] DEBUG[26239]: chan_sip.c:8928 build_route: build_route: Contact hop: <sip:Holda%20Johnson@204.91.156.9:47828;transport=udp>
[Oct 15 23:17:04] DEBUG[26239]: chan_sip.c:14938 handle_request_invite: SIP/blahmoofoo.com-833c3000: New call is still down.... Trying...
[Oct 15 23:17:04] DEBUG[26239]: devicestate.c:448 __ast_devstate_changed_literal: Notification of state change to be queued on device/channel SIP/blahmoofoo.com-833c3000
[Oct 15 23:17:04] DEBUG[26239]: devicestate.c:327 ast_device_state: No provider found, checking channel drivers for SIP - blahmoofoo.com
[Oct 15 23:17:04] DEBUG[26239]: chan_sip.c:16825 sip_devicestate: Checking device state for peer blahmoofoo.com
[Oct 15 23:17:04] DEBUG[26239]: enum.c:406 ast_get_enum: ast_get_enum(): n='0*270', tech='sip', suffix='e164.org', options='0', record='1'

*CLI> [here we wait... and wait...]
*CLI>
*CLI> [Oct 15 23:18:26] DEBUG[26239]: devicestate.c:437 do_state_change: Changing state for SIP/blahmoofoo.com - state 4 (Invalid)
[Oct 15 23:18:26] DEBUG[26239]: app_queue.c:617 handle_statechange: Device 'SIP/blahmoofoo.com' changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
[Oct 15 23:18:26] DEBUG[26239]: enum.c:452 ast_get_enum: ast_get_enum: ast_search_dns(0.270.e164.org) returned -1
[Oct 15 23:18:26] DEBUG[26239]: enum.c:478 ast_get_enum: No such number found: 0.270.e164.org (Undefined error: 0)
[Oct 15 23:18:26] DEBUG[26239]: pbx.c:1734 pbx_substitute_variables_helper_full: Function result is ''
By: Joshua C. Colp (jcolp) 2008-01-15 20:28:17.000-0600

I've fixed the DNS lookup as of revision 98954, and the other lookup I believe is a configuration thing. If you look at the debug output it's doing the lookup against e164.org, not freenum.org.