Summary:	ASTERISK-28290: res_resolver_unbound.so: Failed to perform async DNS resolution
Reporter:	Mark (mpa)	Labels:	pjsip
Date Opened:	2019-02-14 02:52:49.000-0600	Date Closed:	2019-02-19 10:46:31.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_resolver_unbound
Versions:	16.1.1	Frequency of Occurrence	Occasional
Related Issues:
Environment:	OpenBSD 6.4 -current (amd64)	Attachments:	( 0) CLI.log
Description:	After upgrading asterisk 13.24.1 -> 16.1.1, i'm occasionally getting the following error which leads to asterisk not being able to register/re-register with my SIP provider. {quote}ERROR[-1]:res_resolver_unbound.c:306 unbound_resolver_resolve: Failed to perform async DNS resolution of 'tel.t-online.de'{quote} As soon, as this message appears - CPU usage is going up to nearly 100% - tcpdump shows no pkts on port 53 - registration fails (of course) As i said, there's no real timeframe when it happens. - multiple times in a row directly after restarting asterisk - after few minutes, so initial registration works, re-registration fails - after hours, so initial registration works, re-registration fails I can fully circumvent this error with asterisk running perfectly stable when unloading "res_resolver_unbound.so" via module.conf. I think this leads to asterisk using the system resolver? I've attached the console log and what i wonder about is, that although the res_resolver_unbound module is loaded during that test, i don't seen any resolver_unbound DEBUG messages here...only pjsip_resolver. Is that correct behaviour?
Comments:	By: Asterisk Team (asteriskteam) 2019-02-14 02:52:49.956-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: George Joseph (gjoseph) 2019-02-15 09:34:13.002-0600 >I think this leads to asterisk using the system resolver? Correct. >i don't seen any resolver_unbound DEBUG messages here...only pjsip_resolver. Is that correct behaviour? There should be debug messages from res_resolver_unbound when it starts but i don't think there are any others unless you set "debug" in resolver_unbound.conf to a positive number.  Doing that might give you more info. Can you correlate the times you have issues with any other events that might be going on in your environment? The unbound resolver can be a performance benefit in high volume situations but if the system resolver works fine for you, by all means, do a "noload" on res_resolver_unbound.so in modules.conf.   By: Mark (mpa) 2019-02-16 11:32:22.086-0600 {quote}There should be debug messages from res_resolver_unbound when it starts but i don't think there are any others unless you set "debug" in resolver_unbound.conf to a positive number. Doing that might give you more info.{quote} All tests were done with "debug = 99" in resolver_unbound.conf, but as you can see in the attached CLI.log, there are no resolver_unbound DEBUG messages {quote}Can you correlate the times you have issues with any other events that might be going on in your environment?{quote} No. Everything else works fine. Even when asterisk prints the ERROR, a "dig tel.t-online.de NAPTR" works flawlessly and shows correct results I never had performance issues in environments where asterisk runs, so right now it's definitely best to operate without res_resolver_unbound.so By: Chris Savinovich (csavinovich) 2019-02-18 15:04:06.023-0600 Hello Mark, are you satisfied with your solution of disabling res_resolver_unbound.so?  If you are we will close the issue but if you are not we will need a more concise list of your configuration. Thanks By: Mark (mpa) 2019-02-19 00:31:47.729-0600 Hi Chris, as it seems nobody else stumbled upon this and it works with unloading resolver_unbound, i'm fine with it. By: Chris Savinovich (csavinovich) 2019-02-19 10:46:31.738-0600 Not enough information to determine if it is an issue with their network.