bind9 странных журналов и много из них

Это мой журнал привязки, эти запросы не перестают приходить, а named использует много процессора

    27-Sep-2018 21:34:19.693 queries: info: client 217.107.34.85#25183 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:19.738 queries: info: client 109.148.129.56#15451 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:19.796 queries: info: client 217.107.34.85#22807 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:19.805 queries: info: client 74.99.171.161#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.242 queries: info: client 142.112.165.146#80 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.243 queries: info: client 122.114.207.223#80 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.302 queries: info: client 217.107.34.85#36681 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.368 queries: info: client 92.11.206.190#80 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.426 queries: info: client 74.99.171.161#80 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.438 queries: info: client 217.107.34.85#51622 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.570 queries: info: client 70.29.66.36#47689 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.794 queries: info: client 109.148.129.56#37777 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.918 queries: info: client 74.99.171.161#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.941 queries: info: client 217.107.34.85#16138 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.961 queries: info: client 74.99.171.161#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.145 queries: info: client 74.99.171.161#80 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.156 queries: info: client 92.11.206.190#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.381 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.382 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.417 queries: info: client 74.99.171.161#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.421 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.513 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)

я должен беспокоиться?

bind

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

Запись журнала запросов сначала сообщает идентификатор клиентского объекта в формате @ 0x. Затем он сообщает IP-адрес и номер порта клиента, а также имя, класс и тип запроса. Затем он сообщает, установлен ли флаг Recursion Desired (+, если установлен, - если не установлен), если запрос был подписан (S), EDNS использовался вместе с номером версии EDNS (E (#)), если TCP использовался (T), если был установлен DO (DNSSEC Ok) (D), если был установлен CD (проверка отключена) (C), если был получен действительный DNS-сервер COOKIE (V), или если параметр DNS COOKIE без действительный сервер COOKIE присутствовал (K). После этого сообщается адрес назначения, на который был отправлен запрос.

Глядя на одну из ваших записей (практически все одинаковые):

27-Sep-2018 21:34:19.796 queries: info: client 217.107.34.85#22807 (isc.org): query: isc.org IN ANY +E (192.168.0.200)

Мы видим + (желательна рекурсия) и E (EDNS) и что qtype ANY.
Также актуально отсутствие T (TCP).

Это комбинация, которая при выборе доменного имени, по которому они знают, что существует большое количество записей, по существу оптимизирует получение как можно большего ответа, отправленного обратно через UDP. (Рекурсия позволяет использовать любое доменное имя по выбору, EDNS позволяет получать ответы> 512 байт по UDP (легко подделать).)

Это более-менее идеально для отражение усиления DDoS атак, где злоумышленник рассылает большое количество крошечных запросов с IP-адресом своей жертвы в качестве адреса источника, при этом ваш сервер отправляет полученные большие ответы на адрес жертвы.

Очевидные вещи, которые нужно изучить, чтобы решить эту проблему:

У вас, вероятно, нет веских оснований разрешать рекурсию для широкой публики, если она вообще есть. Вы захотите отключить это! Видеть allow-recursion для ограничения доступа к рекурсии только для ваших предполагаемых клиентов или recursion чтобы полностью отключить рекурсию.
BIND также имеет Ограничение скорости ответа встроенный, который позволяет вам ограничивать скорость идентичных запросов от ваших разрешенных клиентов (см. предыдущий пункт). Либо вынуждайте клиентов, которые превышают настроенное вами пороговое значение, переключиться на TCP (что не является тривиальной подделкой), чтобы фактически получить фактические ответы, либо начать полностью отбрасывать ответы.

В целом интернет-провайдеры должны фильтровать исходный IP-адрес своих клиентов (см. BCP38), чтобы ограничить возможность того, что кто-либо просто заявит, что является любым IP-адресом (как это делается в этом типе спуфинга).

Фактически он использовался для атаки отражения и усиления DNS, как сказал @HBruijn. ограничить рекурсию для внутренних клиентов, установив ACL.