Перейти к содержимому

Звонки через SIP-транк Avantel пропадали — виноват был локальный DNS

BIND на PBX резолвил sip00.avantel.ru в SERVFAIL на каждом цикле перерегистрации Asterisk
14 июля 2026 г. от
Звонки через SIP-транк Avantel пропадали — виноват был локальный DNS

До и после: локальный DNS-резолвер на PBX получал SERVFAIL для sip00.avantel.ru, после включения forwarders резолвинг стабилен

Звонки через SIP-транк Avantel на нашем PBX-сервере периодически пропадали на пару минут — без явной системной ошибки, просто транк на время переставал принимать вызовы. Разобрались, что происходило, и починили.

Симптом: обрывы без видимой причины

В логе Asterisk на каждом цикле перерегистрации SIP-транка (примерно раз в 5 минут, весь день) повторялась одна и та же ошибка:

ERROR netsock2.c: getaddrinfo("sip00.avantel.ru", ...): Name or service not known

Пока у Asterisk оставался закешированный IP транка, регистрация висела «Registered» и звонки шли. Но в момент, когда для нового вызова требовался свежий DNS-лукап именно в момент неудачного резолвинга, — звонок через этот транк на время переставал проходить.

Причина: локальный DNS резолвил сам себя в тупик

На PBX-сервере крутится собственный DNS (BIND / named), и в его конфиге форвардинг на внешние резолверы был отключён — сервер пытался резолвить домены полностью самостоятельной рекурсией. Для sip00.avantel.ru (точнее, для CNAME-цели aphrodite.avantel.ru) такая рекурсия стабильно возвращала SERVFAIL, хотя через внешний резолвер (8.8.8.8) тот же домен резолвился без проблем.

Исправление

В /etc/named.conf включили обратно закомментированные форвардеры на рабочие резолверы (77.88.8.1, 8.8.4.4, 8.8.8.8) с forward first;. Простого rndc reload и rndc flush оказалось недостаточно — новые настройки резолвера подхватились только после полного перезапуска сервиса named (несколько секунд, сам Asterisk это не затронуло).

Проверка

15 резолвингов sip00.avantel.ru подряд — все NOERROR с корректным ответом. Все 5 SIP-регистраций Asterisk — Registered.

Итог

Причина обрывов звонков была не в Asterisk и не в самом SIP-транке, а в тихо сломанной DNS-инфраструктуре под ним. Транк резолвится стабильно, регистрации держатся, случайных обрывов больше нет.

Odoo 10: доработали статус документов СБИС ЭДО
Одна умная кнопка вместо четырёх — и точный статус вместо путаницы

Похожая задача в вашей компании?

Напишите намСмотреть услуги