Don't configure Asterisk channels whose domain name cannot be resolved #793
Conversation
This should help a bit dealing with user entry errors while configuring channels. Regarding #783, 2 out of 3 channels which fail to resolve the IP address of the domain have a whitespace at the start/end of the domain, which makes the DNS query fail. Plus, we've had authentication errors in the past due to extra whitespace in the username and password.
If the domain name of the channel cannot be resolved when generating the configuration file for Asterisk, skip it entirely. Asterisk needs the resolved IP addresses for matching incoming calls from the channel (ie. the `identify` sections). Also, the domain needs to be resolvable for Asterisk to attempt the registration. We may consider relaxing this restriction if the channel should not be registered and is only used for outgoing calls. As of today, the broker doesn't care for the channel's direction.
If a channel is not configured in Asterisk due to the domain name resolution failing, report that error back to the UI.
I think we're regenerating the config file every once in a while, right? (DNS entries could change), so any outage with DNS service would be automatically fixed once the domains could be resolved again. Can we reuse the last known IP addresses in the meantime?
SRV lookups didn't work for incoming calls the last time I tried, and the Asterisk team confirmed that feature was not implemented. Doesn't relying on "From" headers make the system susceptible to relatively easy attacks? Given that Verboice doesn't relay on which Asterisk endpoint the call came through, can't we just replace all the endpoints configuration (except entries for SIP server channels) with only one wildcard endpoint accepting any incoming call? Once the call is forwarded to Verboice the broker will identify the call using the IP address and DID number. This wouldn't make any difference regarding DNS names resolution but at least should make the Asterisk configuration file much shorter. |
No. As of today, that only happens when a channel is created/updated/destroyed (reload is issued on an interval). But, since as you say, DNS entries can change, maybe we should do it periodically.
Ah, good to know. It's being implemented though: asterisk/asterisk@a7d856c It seems I've been reading the bleeding edge docs :)
Yeah, it doesn't sound secure. I don't like that option either.
I'm not sure if/how a wildcard endpoint can be configured. But yes, that would work I think. On the other hand, doesn't this open the system to easy attacks too? |
Considering this, we should add a task to periodically retry regenerating the config file, to ameliorate any DNS outage issues. |
Fixes #783
If the broker fails to resolve the domain name for a SIP channel, do not write the channel in the Asterisk configuration file.
There is a major caveat to this approach: if there is a transient DNS outage when regenerating the configuration, most (all?) channels will not be configured in Asterisk. Then again, in that case we cannot write a "good" configuration file at all.
Under normal circumstances, the name resolution fails due to a typo/extra whitespace in the user entered domain. We strip the domain name, username and passwords in the UI to alleviate this problem. Also, if the DNS query fails, the error is reported back to the UI for the user to see in the channels list.
Strictly speaking, we only need the resolved IP addresses for the
identifysections of PJSIP. If we don't have them, then Asterisk cannot identify an incoming call by matching the IP address to the originating domain, but it can be configured to perform SRV lookups or make the identification based on theFrom:header. See https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip_endpoint_identifier_ip and https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships#PJSIPConfigurationSectionsandRelationships-SectionTypes.If the channel is configured for registration, the domain name also needs to resolve to perform the registration.