[asterisk-dev] RFT: Expanded DNS SRV handling in Asterisk 1.4

[John Todd]

>I have just made an attempt to improve the DNS SRV record handling in
>Asterisk 1.4, so that it will now sort the received answers by priority
>(but not weight... yet) and choose one of the lowest-priority answers.
>
>I would like some assistance from the community in getting this tested,
>and we also need some feedback on whether this should actually get
>merged into Asterisk 1.4 or not. It could be classified as either a
>bugfix (since we don't implement SRV record handling properly) or as an
>enhancement (since it is at least partially usable now).
>
>The changes are in
>http://svn.digium.com/asterisk/team/kpfleming/SRV-priority-handling. I
>wrote this code sitting in the speaker prep room at Interop New York, so
>right now all I know is that it compiles and looks correct... I have not
>yet tested it at all :-)
>
>--
>Kevin P. Fleming
>Director of Software Technologies
>Digium, Inc. - "The Genuine Asterisk Experience" (TM)

Any SRV usage improvement would be welcome.

Since I can't see that URL right now from my perspective on the 
Internet, here are a few questions:

   - if there are multiple SRV records, and the first one times out, 
will * cascade through the subsequent records one at a time?  I 
assume "yes" to this, though "no" would be OK, too.

   - if yes to #1, is there any way to short-circuit this from within 
the dialplan and avoid certain SRV responses?

   - if yes to #1, will Asterisk "remember" bad attempts to SRV records?

Here's why I ask: I've had first-hand experience with 
prioritized/weighted SRV records that cause serious problems. 
Someone puts "10 10 _sip._udp.inside-proxy.foo.com" as their first 
SRV record for foo.com, and "20 20 _sip._udp.outside-proxy.foo.com" 
as their second preference SRV record for foo.com.  The host 
"inside-proxy" isn't reachable from the Internet.  Therefore, every 
call attempt that goes to their domain goes first to a proxy that 
times out (wait... wait... wait...) and then goes to the second one 
that completes.  This leads to unacceptable timeouts, and eventually 
leads to hard-coded SRV record data put into a local resolving 
nameserver (can you say "domain hijacking for operational purposes?") 
to avoid the delay.  This is Very Bad, and leads to User Anger.

I guess I'm saying that SRV record lookups should be able to be 
turned off within Dial (which does exist today, despite my approval 
of SRV lookups being "on" by default) and a function that performs 
SRV lookups should be created so that the local administrator can 
start to create a good/bad list of possible SRV response entries for 
future use.  This would not change the way * behaves today; it would 
simply provide an alternative for the more sophisticated 
administrator to control their own fate.

I'm all for SRV automation behind-the-scenes as the default behavior. 
However, I am less happy when there are no alternatives to letting an 
administrator do things in a better way.  I'm sure I'm not alone here 
when I say that I dislike programs that think they're smarter than me 
and won't let me change the settings.  If the patch doesn't 
sequentially attempt different SRV response destinations, then this 
isn't a big deal (though it still means that SRV methods don't/can't 
work with Asterisk in the way the RFCs intended.)

I believe Otmar Lendl suggested (in mantis? on the list?) a more 
general DNS lookup process for Asterisk within the dialplan and/or 
the manager.

Summary: I'd love to see a function that resolves and returns an 
array-like set of SRV lookup results for a domain.  Let the 
administrator write a routine that then runs through the various 
possible destinations.

I look forward to seeing it go in right after the session-timers 
bugfix/enhancement is made, which has been tested and awaits 
inclusion in TRUNK.


JT