[sr-dev] dns resolver issue (RFC3263)

[MÉSZÁROS Mihály]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20121130/e2b9f033/attachment.htm>