DNS REFUSED означает, что DNS-сервер ответил на запрос, но отказался выполнять его. Это не доказательство отсутствующей A-записи: сначала нужно выяснить, кто отказал — рекурсивный резолвер, который ищет ответ для клиента, или авторитативный NS, который хранит зону домена.
Проверьте одно и то же имя через используемый резолвер и напрямую на каждом NS без рекурсии. Если отказ только у резолвера, проверяйте его доступ и политики; если у NS для собственной публичной зоны — загрузку зоны, делегирование и ограничения запросов. Перезагрузка веб-сервера здесь обычно не помогает.
Что означает REFUSED и чем он отличается от других ответов
В RFC 1035 REFUSED — код DNS-ответа 5: отказ выполнить операцию по политике сервера. Сам код не раскрывает конкретное правило.
| Результат | Что он говорит | | --- | --- | | REFUSED | Запрос отклонён; наличие нужной записи ещё не установлено | | NXDOMAIN | Получен ответ, что запрошенного имени не существует | | NOERROR без нужной записи | Возможен NODATA: имя существует, но запрошенного типа записи нет | | SERVFAIL | Сервер не смог обработать запрос | | Timeout | За время ожидания DNS-ответ не получен |
Пустой раздел ANSWER сам по себе не означает NODATA: возможны, например, перенаправление к другим NS или промежуточный CNAME. Различие NXDOMAIN и NODATA описано в RFC 2308.
Не путайте DNS REFUSED с браузерным ERR_CONNECTION_REFUSED: последний относится к отказу в подключении, а не к этому коду DNS-протокола.
1. Зафиксируйте имя, тип записи и сервер
На компьютере с установленным dig выполните:
dig example.com A
dig example.com AAAAЗдесь и ниже example.com — пример: замените его точным именем, которое не работает. Для почты нужен запрос MX, для проверки TXT — именно TXT; ответ на A не подтверждает исправность других типов.
Сохраните строку status, флаги, секции QUESTION и ANSWER, а также строку SERVER: она показывает адрес ответившего DNS-сервера. Не используйте только +short — короткий вывод скрывает диагностические детали.
Если сайт не открывается только в браузере, учитывайте защищённый DNS: браузер может обращаться к другому резолверу, чем системный dig. Сравнивайте одинаковое имя и тип записи, записывайте время с часовым поясом.
2. Отделите отказ резолвера от проблемы домена
Для публичного имени сравните ответы:
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AЕсли оба дают ожидаемый адрес, а используемый DNS возвращает REFUSED, это основание проверить именно этот резолвер: разрешён ли ваш клиентский IP, доступна ли рекурсия, нет ли фильтрации имени. Это рабочая гипотеза, а не доказательство причины: успешный ответ мог остаться в кэше.
Для внутренних корпоративных имён такая проверка не подходит: публичные резолверы не обязаны знать частную зону. Не отправляйте им приватные имена; сравните разрешённые корпоративные DNS и условия доступа к ним.
Владелец сайта не может исправить чужой резолвер правкой A-записи. Передайте результат администратору сети или DNS-провайдеру; временная смена резолвера, если она разрешена, не устраняет исходный отказ.
3. Запросите свою зону на каждом авторитативном NS
Получите NS из делегирования у регистратора, сверив их с панелью DNS-провайдера. Для публичного домена цепочку можно дополнительно посмотреть через dig +trace example.com NS; неудачный trace из сети с ограничениями сам по себе не доказывает поломку делегирования.
Для каждого адреса NS выполните:
dig @IP_NS example.com SOA +norecurse
dig @IP_NS example.com A +norecurseЗамените IP_NS реальным IP проверяемого NS, а имя в SOA — именем зоны. IP позволяет проверить сам сервер, даже если имя NS сейчас не разрешается.
Параметр +norecurse убирает просьбу искать ответ на других серверах; его поведение описано в документации dig. Для корректного ответа из собственной зоны ожидайте флаг aa, означающий авторитативность.
Как читать сочетание результатов
- Собственная зона отвечает без рекурсии, а запрос чужого домена отклоняется: сервер может штатно запрещать рекурсию посторонним. Открывать её всем ради устранения REFUSED не нужно.
- Один NS отдаёт ожидаемые записи, другой отказывает: проверьте, обслуживает ли второй нужную зону и принимает ли публичные запросы. Для сравнения данных пригодится инструкция по проверке каждого NS.
- Все NS отказывают для своей публичной зоны: сначала сверяйте делегирование, наличие зоны в панели, её загрузку и правила доступа. Код REFUSED не позволяет выбрать одну из этих причин без проверки.
4. Исправьте причину и проверьте результат
На собственном BIND-сервере администратор проверяет ограничения запросов allow-query, правила рекурсии allow-recursion и доступа к кэшу allow-query-cache, а также выбранную для клиента view — набор зон и правил для определённой группы запросов. Эти настройки разделены в справочнике BIND: разрешение публичных ответов своей зоны не требует открытого рекурсивного сервера.
Если DNS размещён у провайдера, передайте ему точное имя, тип записи, адрес отказавшего NS, время, сеть проверки и результаты с рекурсией и без неё. Перед отправкой уберите приватные имена и служебные данные; пароли и ключи доступа не нужны.
После исправления повторите ту же матрицу запросов с проблемной сети и внешней точки: каждый публичный NS должен отвечать за свою зону, а разрешённый клиент — получать нужную запись через резолвер. Затем проверьте HTTPS сайта: исправный DNS ещё не подтверждает работу приложения.
Регулярный контроль доступности в Web-Puls помогает заметить последствия DNS-сбоя и сохранить историю инцидента, но не меняет политики чужого резолвера и не воспроизводит каждую сеть посетителя. Если установить причину отказа не удалось, отправьте заявку на диагностику с публичным доменом и обезличенными результатами проверок: специалист оценит задачу и предложит формат работ.