[sr-dev] dns resolver issue (RFC3263)

Sun Dec 16 13:28:33 CET 2012

Hi Daniel,

You have absolutely right, it has to be tested it without cache.
I thought someone is using it that way and will help to test it, anyhow 
I made the test myself now.

I have tested sip-router without DNS CACHE and after this correction:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=7ce7d6413b45e7e9df190167e7faba8c10f96492

Now it seems to be working correctly.
So I tested it, and i couldn't experience any issue with it.

It will be more safe if others (like IBC,Klauss) can apply it to any 
testing baranch and confirm that they have no issue with it.

If you want to Test it yourself i can wait for the next major release.
(After it please merge it to master.)

Many Thanks,
Misi

On 2012-12-10 10:26, Daniel-Constantin Mierla wrote:
> Hello,
>
> one thing keeps it back for now - you said that you didn't tested 
> without cache. So that has to be reviewed as well, it is a patch for 
> core and cannot be overlooked. If you can test it and report the 
> results, then it can speed up. For me it will take a bit of time to 
> get to testing it, but I will before the next major release.
>
> Cheers,
> Daniel
>
>
> On 12/10/12 9:37 AM, MÉSZÁROS Mihály wrote:
>> Hi All,
>>
>> Any other issue or comment or request for correction?
>> When can i expect to submit it to master tree?
>>
>> Thanks,
>> Misi
>>
>> On 2012-12-05 13:07, MÉSZÁROS Mihály wrote:
>>> Hi Daniel
>>>
>>> I wrote in my first patch announcing email, that i didn't test the 
>>> patched dns resolution without cache.
>>> I only tested with dns cache.
>>>
>>> This is the reason why i didn't recognize this problem.
>>> You are right I made a mistake, but now it is corrected.
>>>
>>> Many Thanks,
>>> Misi
>>>
>>> On 2012-12-04 17:47, Daniel-Constantin Mierla wrote:
>>>> Hello,
>>>>
>>>> I was looking to the patch and I spotted that you didn't assign 
>>>> anymore a value to he variable -- next is the specific part of the 
>>>> diff:
>>>>
>>>> -       /* fallback to normal srv lookup */
>>>> -       he=srv_sip_resolvehost(name, 0, port, proto, 0, 0);
>>>> +       /* fallback to srv lookup */
>>>> +       no_naptr_srv_sip_resolvehost(name,port,proto);
>>>>
>>>> Shouldn't be like: he = no_naptr_srv_sip_resolvehost(name,port,proto);
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 11/30/12 10:31 AM, MÉSZÁROS Mihály wrote:
>>>>> Hi,
>>>>>
>>>>> On 2012-11-30 09:07, Daniel-Constantin Mierla wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On 11/19/12 10:18 AM, MÉSZÁROS Mihály wrote:
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> On 2012-11-14 12:51, Daniel-Constantin Mierla wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I made some progress. As I stated before, I made a patch and 
>>>>>>>>> submitted to git branch misi/dns_srv.
>>>>>>>>> I tested with dns cache. It works for me.
>>>>>>>>>
>>>>>>>>> I made it also available for case if "no dns cache" is used too,
>>>>>>>>> but it isn't tested yet.
>>>>>>>>>
>>>>>>>>> Please review my commit, and let me know if any corrections 
>>>>>>>>> needed.
>>>>>>>> if nobody does it meanwhile, I can look over it next week and 
>>>>>>>> also check properly what's all about this discussion, currently 
>>>>>>>> being out of the office.
>>>>>>>>
>>>>>>> After you had time to review it, please let me know your thoughts.
>>>>>> unfortunately I had no time to look at it yet. Hopefully I will 
>>>>>> find some soon.
>>>>>>
>>>>>> Btw, is it complete? IIRC, I saw something like it still has to 
>>>>>> be extended.
>>>>>>
>>>>> It is complete and working patch.
>>>>> If there are no NAPTR records to a domain, then according to the 
>>>>> local protocol preference it orders protocols and it tries to 
>>>>> resolve SRV records according this ordered list. If there is no 
>>>>> order then the order is udp,tcp,tls,sctp,..
>>>>>
>>>>> SRV records are resolved in order Kamailio dns protocol preference.
>>>>> My algorithm picks and returns with the first protocol resolvable 
>>>>> SRV record, so it sets from SRV the port and protocol.
>>>>> (Of course if there are no SRV at all then it fallbacks to host 
>>>>> resolving so dns "A" record.)
>>>>>
>>>>> It is big step forward comparing to current Kamailio behavior 
>>>>> where it is using strictly udp only and after it stops searching 
>>>>> SRV records at all, and go for "A" record!
>>>>>
>>>>> As i wrote in my patch announcing email it is a step further on 
>>>>> the way to conforming with RFC3263, but my patch not handling 
>>>>> fallback if there are SRV-s  for multiple protocols in DNS.
>>>>> In such case only and only if the first protocol is temporary not 
>>>>> available or fails we are not falling back to other protocol but 
>>>>> falling back to host resolving so "A" record (and/or AAAA).
>>>>>
>>>>> Can you send meg the iirc message what was there exactly?
>>>>> Is there any other problem in it?
>>>>> I guess no just what i explained above.
>>>>>
>>>>> I am eagerly waiting your review and comment.
>>>>>
>>>>> Thanks in advance!
>>>>> Misi
>>>>
>>>> -- 
>>>> Daniel-Constantin Mierla -http://www.asipto.com
>>>> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> -- 
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20121216/445fdef3/attachment.htm>