[asterisk-bugs] [Asterisk 0017902]: Asterisk 1.8.0-beta3 DNSMGR address corruption

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17902 
====================================================================== 
Reported By:                afried
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17902
Category:                   Core/PBX
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.8.0-beta3 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-23 11:51 CDT
Last Modified:              2010-08-23 16:24 CDT
====================================================================== 
Summary:                    Asterisk 1.8.0-beta3 DNSMGR address corruption
Description: 
This may be related to 0017496.  DNSMGR appears to be assigning the wrong
ip addresses to host names that appear in iax.conf and "forgettting"
previous lookups.

This is causing inbound calls from contexts with hostnames to be handled
by the default context.

====================================================================== 

---------------------------------------------------------------------- 
 (0126241) afried (reporter) - 2010-08-23 16:24
 https://issues.asterisk.org/view.php?id=17902#c126241 
---------------------------------------------------------------------- 
I changed the dnsmgr refresh interval to 30 seconds and set a few minutes
worth of logs in under asterisk-rpt1.txt.  There is a definite pattern that
might help with debugging:

The first entry shows an existing ip as null, which is probably an
uninitialized variable.  It then pulls the correct address via dns. 

The next message indicates that the existing dns value is the same as the
one found in the previous dns resolution.  It then does a lookup and
returns the correct value. 

The next message also shows the previous lookup value as the current ip
for the host name being looked up.

If I were to guess, it appears that the "changed from" address always
reflects the previous dns lookup rather than whatever should be stored.

Getting pcaps of the dns traffic is going to be difficult since the
servers all run bind locally and have quite a steady stream of lookups.

As for the zone file, nothing out of the ordinary:

[voipjet-deteque]

type=peer
context=default
host=east.voipjet.com
username=[redacted]
auth=md5
secret=[redacted]
accountcode=voipjet
dtmfmode=rfc2833
disallow=all
allow=ulaw


[pbx-deteque]

type=friend
context=guest
host=asterisk.deteque.com
auth=rsa
inkeys=asterisk.deteque.com
outkeys=sip.fried.us
accountcode=PBX
dtmfmode=rfc2833
encryption=yes
disallow=all
allow=ulaw 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-23 16:24 afried         Note Added: 0126241                          
======================================================================