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

[Benny Amorsen]

>>>>> "JT" == John Todd <jtodd at loligo.com> writes:

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

Isn't that a case of "Doctor, it hurts when I..."?

I bet most SIP calls are between cooperating companies, so it should
be possible to fix the problem correctly instead of doing workarounds.

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

I believe that is complication for no good reason.

JT> I'm all for SRV automation behind-the-scenes as the default
JT> behavior. However, I am less happy when there are no alternatives
JT> to letting an administrator do things in a better way.

You can just ignore the SRV record and define your own IP-based peer.

JT> I'm sure I'm not alone here when I say that I dislike programs
JT> that think they're smarter than me and won't let me change the
JT> settings.

I have never heard of a mail server which allows you to ignore certain
MX records but obey the others. If you want to override MX for a
certain domain, you create a policy for sending mail to that domain,
and that ignores all the MX records.

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

That on the other hand makes sense. If you keep all SRV priority
handling out of asterisk itself, you can probably keep the asterisk
code simple. There is a risk that the dial plan code gets too
complicated though.


/Benny