Ошибка query_getzonedb(): ошибка зоны не загружена в журналах DNS

При расследовании инцидента я заметил ошибку в моем системном журнале, которая выглядит так (анонимно):

Feb  3 21:59:59 ns1 named[18824]: client xxx.xxx.xxx.xxx#2091 (us-east1-aws.api.snapchat.com): view MyView: rpz QNAME rewrite us-east1-aws.api.snapchat.com via us-east1-aws.api.snapchat.com.rpz.vendorsite.com query_getzonedb()failed: zone not loaded

Feb  3 21:59:59 ns1 named[18824]: client yyy.yyy.yyy.yyy#27720 (time-ios.apple.com): view MyView: rpz QNAME rewrite time-osx.g.aaplimg.com via time-osx.g.aaplimg.com.rpz.vendorsite.com query_getzonedb()failed: zone not loaded

Feb  3 21:59:59 ns1 named[18824]: client yyy.yyy.yyy.yyy#27720 (time-ios.apple.com): view MyView: rpz QNAME rewrite time.apple.com via time.apple.com.rpz.vendorsite.com query_getzonedb()failed: zone not loaded

У нас включено ведение журнала запросов. Под капотом это BIND 9. Мы используем поставщика для служб DNS, и этот поставщик использует Spamhaus в качестве канала угроз. Мы подписываемся на эту услугу. Такое сообщение странно для этого сервиса. Служба реализуется путем подчинения RPZ, размещенного поставщиком.

Заметил:

  • "Rpz" в домене, похоже, относится к проблеме зоны политики ответа
  • Сайты, которые должны были быть заблокированы этой службой, не были заблокированы
  • почти каждый DNS-запрос, не включенный в белый список, появлялся с этим же сообщением
  • Похоже, что сообщение об ошибке означает, что служба RPZ не загружается с мастера

Что означает это сообщение журнала? И почему это произошло в середине февраля?

Источник

2 ответа

Решение

Получается, что сообщение журнала означает - зона в сообщении не была загружена.:-). В частности, ведомой зоне RPZ не удалось получить обновления. Теперь для очевидных последующих вопросов: почему? И в чем здесь реальная проблема?

Хотя, возможно, есть несколько причин, по которым RPZ не может быть загружен (главный сервер не работает, изменение правил FW и т. Д.) Оказывается, наша проблема заключалась в том, что мы никогда не применяли новую годовую лицензию. Именно здесь был ключ TSIG, который позволил нам подписаться на услугу.

Наши лицензии соответствуют солнечному календарному году, так почему же это произошло в середине февраля? Оказывается, у продавца был существенный льготный период! (После чего он, вероятно, достиг предела обновления или истечения срока действия и, наконец, "умер".)

Я приобрел лицензию, применил, развернул, и мы вернулись к работе - больше не было странных сообщений в журнале (по крайней мере, не больше, как описано выше).

Источник

Еще один возможный ответ на это я нашел в Pastebin:

https://pastebin.com/NCwum7up

По какой-то причине перезапись RPZ на моей установке продолжала давать сбой dns querylog показывают следующее:

18 апреля 12:26:28 Внутренний DNS-DHCP с именем [7257]: клиент 172.16.11.17#58306: rpz QNAME перезаписывает gateway.fe.apple-dns.net через gateway.fe.apple-dns.net.rpz.local.net query_getzonedb() не удалось: зона не загружена 18 апреля 12:26:31 Internal-DNS-DHCP с именем [7257]: клиент 172.16.10.13#64377: rpz QNAME переписать teredo.ipv6.microsoft.com через teredo.ipv6.microsoft.com.rpz.local.net query_getzonedb() не удалось: зона не загружена

Ошибка: query_getzonedb() не удалось: зона не загружена

Исправление:

  1. Проверьте журнал запуска Bind DNS:

18 апреля 12:39:23 Internal-DNS-DHCP с именем [7551]: зона rpz/IN: загрузка из основного файла /etc/named/zone/response-override.db завершилась неудачно: разрешение запрещено

18 апреля 12:39:23 Internal-DNS-DHCP с именем [7551]: зона rpz/IN: не загружена из-за ошибок.

  1. Исправить ошибку разрешения файла зоны.
  2. Перезапустить по имени
  3. Готово.
Источник
Другие вопросы по тегам