[Serusers] Re: [Serdev] ENUM issues - req. for discussion

[Klaus Darilion]

Hi Andrei!

Andrei Pelinescu-Onciul wrote:
> On Jun 07, 2005 at 13:43, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>>If DNS is slow, or misconfigured (e.g. a zone is delegated to a 
>>nameserver which is down), the thread will be blocked for several 
>>seconds. E.g. if you use debian woody and 2 nameservers in 
>>/etc/resolv.conf, the timeout is 20 seconds. If you are lucky, the OS 
>>allows configuration of the DNS timeouts. Nevertheless, you have to 
>>consider that a ser thread will be blocked up to 20 seconds. This has 
>>impacts on your configuration:
> 
> 
> This could be fixed by limiting the ammount of time that a dns lookup
> can take in ser (e.g. a new config parameter).
> Right now the best practice is to use a caching dns server/proxy, that
> will cache also negative replies.

There is no caching for requests without answer. If the DNS response is 
SERVFAIL, this will be cached until the negative TTL times out. If the 
the authoritative NS does not answer, there is no answer which could be 
cached.

Limiting the time is the first step and will make ser more stable - 
nevertheless it is only the first step. To what time will you set the 
DNS timeout? Values > 0.5s still requries handling of the retransmissions.


> 
> 
> [...]
> 
>>3:
>>If the ENUM lookup succeeds, you never may trust the result. It may be a 
>>invalid SIP URI, or a tel: URI, or anything else a user puts into its 
>>NAPTRs. This may result in a failed transaction, or like revealed at the 
>>ENUM plugtest in failed accounting. Even worse, maybe it is possible to 
>>complete crash ser using realy bad formated URIs?
> 
> 
> No, it shouldn't be able to crash ser. ser survives bad uris.

Fine. What will be the response? 500? 4xx Bad URI? ...

>>In case of ser, I would do the URI parsing in the ENUM module, or maybe 
>>generate a dedicated function/module for checking SIP URIs inside the 
>>routing logic. Thus, I can also check the result of exec calls.
> 
> 
> This could be easily done, but as I said above, if the uri is bad
> forwarding will fail anyway.

But fetching the bad URI before relaying the call (which will fail) I 
can use revert_uri and send the call to the PSTN.

regards,
klaus