|Summary:||ASTERISK-13070: [feature request] Asterisk does not respect DNS TTL in iax.conf|
|Date Opened:||2008-11-13 23:07:13.000-0600||Date Closed:||2011-06-07 14:02:53|
|Description:||This is probably not specific to IAX but I just tried it for IAX so I am not sure about the other channels.|
The problem is :
when you Dial and IAX channel either by direct dialing Dial(IAX2/@some_host_name/extension) or by referring to a section in iax.conf Dial(IAX2/@[section]/extension) and the host names are not IP addresses but DNS names, Asterisk does not care if the resolved address changes.
In other words, lets say you have a dynamic DNS that translates to IP_1 and you use this in your configuration in Asterisk. If this IP changes Asterisk would not respect it and keeps using the old IP until you reload.
It seems that Asterisk resolves the DNS and stores the IP in the memory (as oppose to having the DNS entry and resolving it each time)
****** ADDITIONAL INFORMATION ******
This is not the case in Realtime configurations. That works properly. You can also get around this issue by writing an AGI script that dials out: AGI(AGI_Dial,'IAX2/....') and in AGI_dial you just dial the first argument.
|Comments:||By: Tilghman Lesher (tilghman) 2008-11-13 23:48:06.000-0600|
While that's technically correct, it's not something we're likely to change anytime soon. You just have to deal with the fact that Asterisk caches IP addresses and will not attempt to re-lookup an address until reload/restart.
By: Tilghman Lesher (tilghman) 2008-11-14 09:15:26.000-0600
Please understand that we generally do not track feature requests on the bugtracker. I can allow this feature request to remain open for several days, to see if there is an enterprising developer who would like to contribute a patch for it immediately, but beyond that, I have to suspend this issue. Please note that there is a bounty page on the voip-info.org Wiki where more feature requests can be found, and that is usually where they are tracked.
By: ehsan (ehsan) 2008-11-14 18:15:58.000-0600
Asterisk seems to be violating DNS protocols and common practice of DNS by disregarding TTLs. So, IMO, its hard to call this a feature request.
The scenario I see is that:
Any normal program that makes new connections to a DNS-based name should resolve the name or ask the OS to resolve it for him. If it resolves and caches the result, in the case with Asterisk, it should honor the TTL, which seems to be missing here. As a result, Asterisk will be using an IP for connecting to e.g. call.xxxx.com that has been expired ...
By: Matt Riddell (zx81) 2008-11-16 18:02:00.000-0600
Are you using the dns manager?
By: Leif Madsen (lmadsen) 2008-11-19 11:55:26.000-0600
Assigned to seanbright as he said he'd try to solve the issue on IRC (as long as someone can point him in the correct direction).
This is still considered a feature request, and if he can't figure it out, we'll need to suspend this issue.
By: Farid (ffadaie) 2008-11-19 12:58:05.000-0600
/etc/asterisk/dnsmgr.conf does implement a workaround for this but it is not the 'solution'. The problem with dnsmgr is that, it kinda overwrites the TTL. It updates the DNS entries based on the time defined in the conf file and not based on the DNS TTL.
By: Farid (ffadaie) 2008-11-19 20:28:19.000-0600
A simple solution for this is to store the DNS address in the memory instead of the resolved IP address. Then, just like any other query resolve the address each time it needs to be called and let the DNS server handle the TTL.
I don't know how this is actually implemented in Asterisk so it may be difficult to patch it this way.
By: Sean Bright (seanbright) 2008-12-05 10:22:44.000-0600
I unfortunately am not going to have time to look at this.
By: Leif Madsen (lmadsen) 2008-12-15 10:33:53.000-0600
OK, lets try this again as someone else on IRC said they would take it. If they can't solve it this week, then I've requested they close it as a feature request, which aren't tracked on the bug tracker.
By: Michiel van Baak (mvanbaak) 2008-12-17 15:43:32.000-0600
Ok, here's the way I see we can fix this.
- The functionality as it is now remains.
- Instead of hardcoding the refreshtime in dnsmanager we are going to alter the refresh interval of it based on the lowest TTL returned by the lookups dnsmanager does for us.
So if you want results based on the TTL you have to use dnsmanager.
This way we fix it for all modules the same way, and the patch will be easy to review because it will only touch 1 maybe two files.
Discussion on IRC made seanbright and jsmith agree with this idea.
If you agree, or dont agree, please let me know.
By: Farid (ffadaie) 2008-12-17 16:29:54.000-0600
It sounds like a good idea. So, what you are going to modify dnsmanager to become a tiny dns server (BIND if you will as I am not that big of a MS fan).
The reason that I am saying it should somehow be a DNS server is that some parts of DNS protocol should be implemented. For example, if TTL changes, then dnsmanager should know about it. In other words, it cannot calculate the lowest TTL returned by the lookups at the beginning and uses that for ever. That would cause similar problems with what we have right now.
The following steps should be taken (in my opinion):
1- Resolve the names
2- Calculate the lowest TTL (lets call that LTTL)
3- wait LTTL
4- goto 1
I can't think of any other issues right now that could potentially be an RFC breaker.
I may have proposed the same idea as you did because of the lack of details in your comment. I apologize if that's the case.
By: Michiel van Baak (mvanbaak) 2008-12-17 16:39:53.000-0600
Sorry for not being verbose enough.
What you describe there is exactly what I was thinking about.
Right now, you set a refresh value in the configuration file, and dnsmanager will only update the hostname:ip pair once every refresh_timeout seconds.
What I want to do is alter dsnmanager to lookup everything needed, and keep track of the TTL's for those records.
The timeout will be set to the lowest TTL of all the records.
If the TTL is reached, dnsmanager will refresh and do the whole 'store and sort and use the lowest TTL' run again as part of the refresh function.
That way, if the TTL's changed, the refresh_timeout will be changed as well.
Thanks for the feedback.
By: Farid (ffadaie) 2008-12-17 17:10:17.000-0600
A tiny comment:
The only drawback I see here is the potentially redundant DNS traffic. If it were properly implemented within the Asterisk code, as opposed to being patched by dnsmanager, no DNS query would be made unless somebody wanted to make a call or receive one, etc. By using the dnsmanager this behavior is overwritten. We will always have DNS traffic.
By: Michiel van Baak (mvanbaak) 2008-12-19 13:52:05.000-0600
ffadale: I think that that is way better then the way we have it now.
I can live with the couple of extra packets. If you have a system where this will be an issue, you're prolly only making calls once a day or something so you be better off with a 'asterisk -rx "core restart when convenient"'
I'm going to implement it the way we agreed before. Beware that it can take up to two weeks because of the holidays season.
If someone else comes up with code it's fine by me and I'll review it.
Just letting you all know when I have time since this is a feature request :)
By: Michiel van Baak (mvanbaak) 2008-12-21 07:11:46.000-0600
Maybe I'm not going to implement it ;)
Let me explain why.
In the current code it's not that easy to grab the TTL for an A record.
And I'm not that interested to write a new resolver function in asterisk that grabs the TTL.
Maybe it's best to use dnsmgr with refresh of a minute and use a local dns cache that does handle the TTL.
Let me think about it for a couple of days and I'll decide wether I want to spend the time needed or not.
By: Farid (ffadaie) 2008-12-21 08:34:57.000-0600
This has caused us a lot of problem when we receive our service from the providers who are using Asterisk but does not have the required knowledge to implement a workaround.
We use dynamic DNS for our incoming calls. The TTL for our DNS is 30 sec (and we really cannot increase it). In our side, we have implemented the workarounds and it was just us, I wouldn't insist on this issue as much as I have so far ;) but some of our providers(the ones who use Asterisk), keep sending the messages to just one of our servers (to which the DNS is resolved at first).
This problem does not exists in Cisco IOS, Avaya, ...
By: Leif Madsen (lmadsen) 2009-01-06 11:27:11.000-0600
This issue is being suspended per mvanbaak as he does not have the time to implement this feature request. If you are able to provide a patch to get this issue moving forward, then please find a bug marshall on irc.freenode.net in #asterisk-bugs to re-open this for you.