On Jun 07, 2005 at 13:43, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Hi all!
Some time of using ser with ENUM revealed several problems which I would
like to dicuss with you. Be aware - this email is long!
ENUM is a wonderful thing for call routing nevertheless, as it is DNS
based there are some important things an ENUM aware application has to
consider:
1. You never know how long the lookup takes
2. You never know if the lookup will fail or succeed
3. If the lookup was successful, you never may trust the result
I will explain this points in detail know:
1+2:
Using enum, the application is giving control to the DNS resolver of the
OS and the DNS infrastructure. Thus, the ser thread which performs the
ENUM lookup will be blocked until there is a result from the system's
DNS resolver.
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.
[...]
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.
Thus you can't avoid doing some URI checks against the URI received from
the ENUM lookup. Perfomance issues are no valid arguements! Once I give
control to external services (DNS, radius, exec), the perfomance
penalties due to parsing the SIP URI are much more less than due to the
ENUM lookup.
What kind of checks? Run parse_uri and if fails return an error?
This will happen any way at the first forward attempt that takes uri
into account (the forward will fail).
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.
Andrei