База знаний PMTA›Код ошибки§ 5.8

Запрос имени не завершился — и вывод не делается

StatusDnsQueryFailed

Самый содержательный из пяти — он объясняет решение вендора

Имя приёмника не разрешилось. Обычно это истечение времени ожидания: либо местный резолвер не ответил, либо он сам не дождался ответа от других.

🔑 И MTA намеренно не отбивает письмо на таком отказе. В этом всё дело. Отсутствие ответа — не то же самое, что ответ «домена нет»: в первом случае мы ничего не узнали, во втором — узнали, что домена не существует.

Решение вендора правильное и стоит его повторять. Отбивать письмо, когда не удалось спросить, значит наказывать получателя за неполадку у нас или в сети.

Практический признак: такие отказы приходят пачками и по многим доменам сразу — резолвер один на весь узел. Отказ по одному домену при работающих остальных означает другое.

Главная ловушка — принять за проблему приёмника. Отказ выглядит как неполадка доставки к домену, а причина у нас: резолвер. Разбор, начатый со стороны приёмника, ничего не найдёт, потому что там всё в порядке.

Что делает Хаб. Отдельно не различает — отказ приходит в категорию транспорта.

⚠️ А различать стоило бы: это единственный из пяти отказов, который говорит о нашем узле, а не о приёмнике. Признак узнаваем — всплеск отказов сразу по многим доменам одного узла при том, что у соседних узлов их нет.

Требование к резолверу записано в подготовке узла: он должен быть доступен и рекурсивен (prepare-host). Проверка этого у Хаба в предполётной части отсутствует.

Рекомендуемые значения

Как узнать, что дело в резолвере:

Наблюдение	Вывод
отказы сразу по многим доменам одного узла	резолвер
у соседних узлов их нет	резолвер именно этого узла
отказ по одному домену, прочие идут	не резолвер, а сам домен

Письма при этом не теряются — MTA их не отбивает, и после восстановления резолвера они уйдут.

Проверять резолвер запросом с самого узла, а не наличием строки в настройках: прописанный, но нерекурсивный выглядит настроенным и не работает.

Таблица различения и совет проверять запросом наши. Из руководства здесь причина отказа и то, что MTA намеренно не отбивает на нём письма.

Пример в конфигурации

# проверять надо резолвер, а не приёмника
pmta resolve gmail.com MXdig +short @127.0.0.1 gmail.com MX

Выделенная строка спрашивает глазами самого MTA — это и есть окончательный ответ на вопрос, разрешает ли узел имена. Пустой ответ означает, что резолвер недоступен либо не рекурсивен.

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · платформа: любая

С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.

⇄

Связанные записи

3 связи

Зависит от

Узлу нужен резолвер, который делает всю работу самТребование к резолверу, невыполнение которого и даёт этот отказ. § 4.2.3

Работают в паре

Кэш имёнКэш имён узла: его состояние и решает, дойдёт ли запрос до внешних серверов. § 5.3

Где это видно

Разобраться, почему копится очередь к одному приёмникуОтказ, который первый же круг разбора и называет: имя приёмника не разрешилось. § 5.8

Сюда ссылаются

Разрешить имя и подключитьсяСмежная запись каталога. inference

◇

Что ещё почитать

3 статьи

◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Сторож, который перезапускает MTAПрисматривает за MTA и после падения поднимает его сам, отправляя отчёт о падении на адрес ответственного.◇Чем опасна виртуальная машинаРаботать на виртуальной машине можно, но руководство не рекомендует это без достаточного железа и выверенных настроек гипервизора: под нагрузкой узел может перестать отвечать.

В Хабе

Цена ошибки: обратимо: вредит, пока стоит
Сценарии: Классификация отказов · Разобрать зависшую очередь