Перейти из форума на сайт.

Новости • Файловые архивы
Поиск • Активные темы • Топ лист
Правила • Кто в on-line?
Вход • Забыли пароль? • Первый раз на этом сайте? • Регистрация
Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Кеширующий DNS сервер для локальной сети на основе BIND 9

Модерирует : lynx, Crash_Master, dg, emx, ShriEkeR

 Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12

Открыть новую тему     Написать ответ в эту тему

articlebot



Administrator		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
   Этот документ описывает установку и начальную конфигурацию    пакета BIND 9 для работы в качестве кэширующего DNS сервера    для локальной сети.
 
 
Читать
Всего записей: 366 | Зарегистр. 25-05-2001 | Отправлено: 18:07 16-06-2004
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
vlary
всё верно, я просто отвечал в контексте вопроса
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 21:09 02-07-2017
dvk54

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Chupaka
vlary
Спасибо!
Теперь понятно.
 
Прошу ещё помочь в чтении логов bind, не могу найти, как их читать.
вот пример(домен заменён на _mydomain.ru_, ип - на x.x.x.1)
Включен dnssec, рекурсия разрешена только для свой "серой" сети, ipv6 нет.

Код:
01 info: client 84.200.69.80#5606 (_mydomain.ru_): query: _mydomain.ru_ IN NS -EDC (x.x.x.1)
02 info: client 84.200.69.80#42499 (ns2._mydomain.ru_): query: ns2._mydomain.ru_ IN AAAA -EDC (x.x.x.1)
03 info: client 84.200.69.80#39514 (mail.actus-ilw.co.uk._mydomain.ru_): query: mail.actus-ilw.co.uk._mydomain.ru_ IN A -EDC (x.x.x.1)
04 info: client 84.200.69.80#59546 (powered-by.xenosite.net._mydomain.ru_): query: powered-by.xenosite.net._mydomain.ru_ IN A -EDC (x.x.x.1)
05 info: client 94.23.206.89#36133 (_mydomain.ru_): query: _mydomain.ru_ IN SPF +E (x.x.x.1)
06 info: client 91.230.121.184#41813 (1x1.cz): query: 1x1.cz IN ANY +E (x.x.x.1)
07 info: client 74.82.47.38#28452 (dnsscan.shadowserver.org): query: dnsscan.shadowserver.org IN A + (x.x.x.1)
08 info: client 46.108.55.36#47632 (.): query: . IN ANY +E (x.x.x.1)
09 info: client 51.254.101.95#36532 (ns1._mydomain.ru_): query: ns1._mydomain.ru_ IN AAAA + (x.x.x.1)
10 info: client 139.162.108.129#55886 (www.qq.com): query: www.qq.com IN A + (x.x.x.1)
11 info: client 74.82.47.2#49966 (dnsscan.shadowserver.org): query: dnsscan.shadowserver.org IN A + (x.x.x.1)
12 info: client 109.234.37.60#56389 (mail._mydomain.ru_): query: mail._mydomain.ru_ IN TXT + (x.x.x.1)
13 info: client x.x.x.1#10828 (_mydomain.ru_): query: _mydomain.ru_ IN TXT +E (x.x.x.1)
14 info: client x.x.x.1#43543 (_mydomain.ru_): query: _mydomain.ru_ IN SPF +E (x.x.x.1)

Вопрос1: о чём говорят "+E", "-EDC" ?
Вопрос2: в строке 01, как я понял, спрашивающий узел определён как МОЙ ЖЕ СЕРВЕР! Но ип - левый. КАК? Или я не верно интерпретирую?
Вопрос3: строка 03: спрашивающий узел на этот раз вроде бы определён как мой же субдомен. Но почему? У меня таких записей нет.
Вопрос4: в строке 8 попытка получить все записи зоны. Мне не очевидна необходимость такого функционала с точки зрения безопасности. Можно ли это (и как) запретить и НУЖНО ЛИ? (это, случайно, не  allow-transfer?)
Вообще, с этого узла (84.200.69.80) много таких вот непонятных (мне) запросов. Это какой-то из видов атаки?
Всего записей: 178 | Зарегистр. 18-06-2005 | Отправлено: 23:59 28-07-2017 | Исправлено: dvk54, 00:16 29-07-2017
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
dvk54

Цитата:
о чём говорят "+E", "-EDC" ?

https://deepthought.isc.org/article/AA-00434/0/What-do-EDC-and-other-letters-I-see-in-my-query-log-mean.html
 

Цитата:
в строке 01, как я понял, спрашивающий узел определён как МОЙ ЖЕ СЕРВЕР!

это не спрашивающий узел, это сам запрос.
 

Цитата:
строка 03: спрашивающий узел на этот раз вроде бы определён как мой же субдомен. Но почему?

см. предыдущий абзац + у клиента, видимо, настроен search в вашем домене, поэтому резолв имени exam.ple начинается с поиска "exam.ple._mydomain.ru_", а потом уже идёт "exam.ple."
 

Цитата:
 в строке 8 попытка получить все записи зоны

не "все записи зоны", а всю информацию о корневой зоне (".")
 

Цитата:
много таких вот непонятных (мне) запросов

Насколько много? Похоже на DNS Amplification с подставным IP-адресрм (когда 84.200.69.80 - атакуемая машина)?
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 10:45 31-07-2017
dvk54

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Chupaka
1. Спасибо, исчерпывающе!  
4. Спс, понял.
 
2.

Цитата:
это не спрашивающий узел, это сам запрос.  

client 84.200.69.80#5606 (_mydomain.ru_): query: _mydomain.ru_ IN NS -EDC (x.x.x.1)
т.е., после айпишника клиента идёт не его fqdn, а запрашиваемое значение?
Я полагал, что сам запрос это query: _mydomain.ru_ IN NS
 

Цитата:
Насколько много?

Ну, конечно, не те ужасы, что на хабре описывают, но штук по 100 в сутки.
Причём, стучат не на DNS-держатель домена, а на slave-dns (ns2). И многие "клиенты"(это - судя по ip) несмотря на отлуп, от трёх до 10 раз в месяц повторяют прозвонку. (хотя, если это мультпликативная атака c подменой ip- атакующий же и не увидит, что запрос отклонён?)
 
Ещё есть странные запросы: имя домена и/или субдомена мои, но клиент играет регистром, примерно так:mAiL._mYdOmAiN.rU_
в этом есть какой-то смысл, или просто повы..делываться?
 
Прошу прощения, если вопросы элементарные - свои первые сервера поднял недавно и многих нюансов ещё не знаю. Пытаюсь предусмотреть максимум угроз.
Всего записей: 178 | Зарегистр. 18-06-2005 | Отправлено: 14:55 31-07-2017
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
dvk54

Цитата:
т.е., после айпишника клиента идёт не его fqdn, а запрашиваемое значение?

ну, как вижу, все значения слева и справа от "query:" совпадают
 
по "непонятным запросам" я уже написал:
 

Цитата:
у клиента, видимо, настроен search в вашем домене, поэтому резолв имени exam.ple начинается с поиска "exam.ple._mydomain.ru_", а потом уже идёт "exam.ple."

 
не может такого быть?
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 15:14 31-07-2017
dvk54

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
ну, как вижу, все значения слева и справа от "query:" совпадают

хм. Я ступил. Мои собственные запросы именно это и показывают. Сбила с толку логика написания ip(name).

Цитата:
не может такого быть?

У меня один клиент пока - я, свой собственный.
И для каких причин кому-то настраивать search в моём домене - для меня тайна.  
Я сам так не настраиваю - не знаю, зачем оно надо и не знаю как это делается. (хотя, что-то такое в форточках на вкладке днс вроде было..)
Собственно, исходя из того, что случайно так настроить нельзя - меня интересует: для каких целей может служить такой запрос. Как-то это "ж-ж-жж" неспроста.
 
Собственно, это не отвлечённый интерес - меня беспокоит безопасность. Особенно потому, что именно в настройке bind я новичок. Паранойя спать спокойно не даёт.
 
На данный момент сделано следующее:
Сокрыта отдача версии софта
настроен/включен DNSSEC
рекурсия разрешена только для одного IP - клиента VPN.(в теории дыра, знаю, но рассказывать провайдеру/гуглу о своих любимых варезниках/порносайтах не хочется)
 
Благодаря Вам, я несколько успокоился по поводу строки +-EDC в логах - я полагал, что это результат ответа на запрос и "плюсик" меня реально напрягал.
 
Что ещё можно подкрутить/запретить?
Всего записей: 178 | Зарегистр. 18-06-2005 | Отправлено: 20:24 31-07-2017 | Исправлено: dvk54, 20:39 31-07-2017
BlackLabel



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Помогите разобраться пожалуйста ...  
Есть роутер с Debian GNU/Linux 7.11 (wheezy) на борту  
на нем же подняты isc-dhcp-server и BIND9
 
Настроен  DDNS  »  т.е хост при подключении получает ип адрес от  DHCP сервера и автоматически добавляються две записи одна в основную зону вторая в обратную .
Тут все работает но мне непонятно следующее ...  
 
Есть ли такая возможность как автоматическое удаление старых записей из зоны ? ...  
а то со временем собираеться много не нужных записей в DNS зонах ..
 
И если есть то в какую сторону копать и какие настройки нужно крутить ?  
Конфиги добавлю в этот же пост если будет нужно ...  
 
И в логах никаких ошибок ...    
Всего записей: 1031 | Зарегистр. 14-04-2004 | Отправлено: 16:34 19-04-2018 | Исправлено: BlackLabel, 16:36 19-04-2018
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
BlackLabel
Старые записи и должны удаляться после истечения TTL, который при создании записи должен устанавливаться равным времени аренды адреса в DHCP. А что dig показывает, какой TTL "старых" записей?
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 17:55 19-04-2018
BlackLabel



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Chupaka
Ну вот например  
mx17.office.loc.        3600    IN      A       192.168.10.57
 
1 час  , но хоста нету уже пару дней ...  
 
Вот какие запииси в файле зоны    

Код:
$ORIGIN .
$TTL 660        ; 11 minutes
office.loc              IN SOA  ns1.office.loc. root.office.loc. (
                                2017002154 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                2419200    ; expire (4 weeks)
                                86400      ; minimum (1 day)
                                )
                        NS      ns1.office.loc.
                        A       192.168.10.1
$ORIGIN office.loc.
$TTL 3600       ; 1 hour
 
mx17                    A       192.168.10.57
                        TXT     "002a25d1a3ff4ac2ba831a394e3514df33"

 
Добавлено:
BlackLabel
Так тут уже нестыковка получаеться ..  
на dhcp такие настройки глобальные  
default-lease-time 86400; сутки  
max-lease-time 172800; двое суток  
 
Но хост не удаляеться и через неделю  
 
Конфиг  DHCP сервера  
ТУТ
Всего записей: 1031 | Зарегистр. 14-04-2004 | Отправлено: 18:02 19-04-2018 | Исправлено: BlackLabel, 18:15 19-04-2018
karavan



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Есть два сервера bind9 с адресами 192.168.18.51 и 192.168.25.8
192.168.18.51 - просто рекурсивный сервер для некоторых клиентов, у него есть доступ к сети сервера 192.168.25.8  
192.168.25.8 - рекурсивный сервер для сети 192.168.25.0/24 и в т.ч. держит зоны:
                        dev.domain.ru, test.domain.ru       (среды тестов и разработки, снаружи невидимы)  
 
Задача: сервер 192.168.18.51 должен правильно ресолвить адреса сред тестов и разработки на запросы клиентов из сети 192.168.18.0/24  
Условия: у клиентов сети 192.168.18.0/24 нет маршрута к сети 192.168.25.0/24,
                у зоны domain.ru есть запись *.domain.ru. IN CNAME domain.ru., а NS-ом выступает cloudflare
 
В принципе, задачу я решил. Осталось все "причесать". И вот тут вопрос.
Две конфы на сервере 192.168.18.51, но на стороне клиентов отличий никаких - оба адреса абсолютно одинаково ресолвятся.:

Код:
zone "dev.domain.ru" {
        type static-stub;
        server-addresses { 192.168.25.8; };
};

 

Код:
zone "test.domain.ru" {
        type forward;
        forwarders { 192.168.25.8; };
};

 
Что будет правильнее, static-stub или forward?
Если клиенту разницы нет, то в чем смысл разности этих типов?
Всего записей: 1962 | Зарегистр. 02-12-2011 | Отправлено: 17:24 26-06-2018 | Исправлено: karavan, 17:25 26-06-2018
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
karavan

Цитата:
Что будет правильнее, static-stub или forward?  
Если клиенту разницы нет, то в чем смысл разности этих типов?

Static-stub шлёт нерекурсивные запросы, forward - рекурсивные (ставит флаг RD в запросе).
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 17:44 26-06-2018
karavan



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Chupaka
Спасибо за подсказку.
 
Еще есть вопрос к описанной выше схеме.
Сервер 192.168.25.8 является авторитарным для зоны domain.lo, зона неподписана ключами.
На сервере 192.168.18.51 есть опция dnssec-validation auto;, при которой клиенты сети 192.168.18.0/24 не могут получать адреса зоны domain.lo.
На каждый рекурсивный запрос из сети 192.168.18.0/24 к этой зоне в лог сервера 192.168.18.51 падает такое:
июн 26 19:40:51 karavan-xiaomi named[7469]: insecurity proof failed resolving 'domain.lo/A/IN': 192.168.25.8#53
июн 26 19:41:28 karavan-xiaomi named[7469]:   validating domain.lo/SOA: got insecure response; parent indicates it should be secure
июн 26 19:41:28 karavan-xiaomi named[7469]: no valid RRSIG resolving 'repo.domain.lo/DS/IN': 192.168.25.8#53
июн 26 19:41:28 karavan-xiaomi named[7469]: no valid DS resolving 'repo.domain.lo/A/IN': 192.168.25.8#53
 
У клиентов сети 192.168.25.0/24 проблем с этим нет.
Что можно сделать без подписывания зоны, ведь любые другие неподписаные зоны ресолвятся успешно?
 
P.S.: про dnssec-validation no; я знаю, но хочется понять природу этой ошибки.
 
Добавлено:
Что удалось нарыть. Родительская зона обязывает валидатора проверять дочернюю зону.
Это ж кто является родителем для зоны domain.lo, если домен первого уровня .lo просто не существует?
Если предположить, что '.' всех принуждает к dnssec, то почему я продолжаю наблюдать неподписанные зоны второго уровня?
 
 
 
Задача решена сменой опции dnssec-validation на yes.
Всего записей: 1962 | Зарегистр. 02-12-2011 | Отправлено: 19:49 26-06-2018 | Исправлено: karavan, 12:57 27-06-2018
SomeStupidUsername

BANNED		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
зачем так усиратся ?
вот же
https://pi-hole.net/
ставится одной командой и еще и рекламу вырежет.
Всего записей: 4 | Зарегистр. 14-04-2018 | Отправлено: 00:36 07-07-2018
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
SomeStupidUsername
Что за минутка рекламы и какое отношение она к теме имеет?
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 11:49 07-07-2018
pavik

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Нашел непонятку с настройками RPZ.
 
Если в файл с зоной RPZ дописать вот такие строки
*.proxy.com  A  1.1.1.1
*.proxy.org A  1.1.1.1
*.proxy.ru  A  1.1.1.1
*.proxy.ry  A  1.1.1.1
*.proxi.ru  A  1.1.1.1
то работают все, кроме  *.proxy.ru
 
При проверке
nslookup qw.proxy.ru 127.0.0.1
bind должен вернуть 1.1.1.1, а он вместо этого лезет в интернет искать реальный ip.
 
Проверено на разных версиях bind, на разных ОСях.
Это у всех так?
Всего записей: 34 | Зарегистр. 20-12-2005 | Отправлено: 14:40 05-02-2019
pavik

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Сам спросил, сам отвечу -
в файле named.conf в опцию response-policy надо добавить параметр qname-wait-recurse no
Всего записей: 34 | Зарегистр. 20-12-2005 | Отправлено: 07:46 04-03-2019
newhk



BANNED		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Приветствую!
Настраиваю BIND первый раз.
Прошерстил много разных статей, в итоге получил такую конфигурацию:
cat /etc/bind/named.conf
Подробнее...
 
cat /etc/bind/nets
Подробнее...
 
cat /etc/bind/named.conf.options
Подробнее...
 
Пингую какой-либо хост из данных зон, все ОК.
Перехожу в браузере по адресу, который находиться в локалке, все ОК.
Но, если я хочу перейти по какому-либо адресу в интернете, на тот же яндекс, получаю фигу...
 
Что у меня не так? Или что нужно добавить?
 
Добавлено:
cat  /var/log/named/query.log

Код:
 
05-Apr-2020 21:17:36.961 client @0x7f005c042820 172.23.11.77#64021 (ya.ru): view nets: query: ya.ru IN A + (172.23.11.1)
05-Apr-2020 21:17:36.963 client @0x7f005c042820 172.23.11.77#57211 (ya.ru): view nets: query: ya.ru IN A + (172.23.11.1)
05-Apr-2020 21:17:36.966 client @0x7f005c042820 172.23.11.77#60496 (ya.ru): view nets: query: ya.ru IN A + (172.23.11.1)
05-Apr-2020 21:17:36.968 client @0x7f005c042820 172.23.11.77#61515 (ya.ru): view nets: query: ya.ru IN A + (172.23.11.1)
 

 
cat /var/log/named/misc.log

Код:
 
05-Apr-2020 21:17:36.961 security: info: client @0x7f005c042820 172.23.11.77#64021 (ya.ru): view nets: query (cache) 'ya.ru/A/IN' denied
05-Apr-2020 21:17:36.961 query-errors: info: client @0x7f005c042820 172.23.11.77#64021 (ya.ru): view nets: query failed (REFUSED) for ya.ru/IN/A at ../../../bin/named/query.c:6980
05-Apr-2020 21:17:36.963 security: info: client @0x7f005c042820 172.23.11.77#57211 (ya.ru): view nets: query (cache) 'ya.ru/A/IN' denied
05-Apr-2020 21:17:36.963 query-errors: info: client @0x7f005c042820 172.23.11.77#57211 (ya.ru): view nets: query failed (REFUSED) for ya.ru/IN/A at ../../../bin/named/query.c:6980
05-Apr-2020 21:17:36.966 security: info: client @0x7f005c042820 172.23.11.77#60496 (ya.ru): view nets: query (cache) 'ya.ru/A/IN' denied
05-Apr-2020 21:17:36.966 query-errors: info: client @0x7f005c042820 172.23.11.77#60496 (ya.ru): view nets: query failed (REFUSED) for ya.ru/IN/A at ../../../bin/named/query.c:6980
05-Apr-2020 21:17:36.968 security: info: client @0x7f005c042820 172.23.11.77#61515 (ya.ru): view nets: query (cache) 'ya.ru/A/IN' denied
05-Apr-2020 21:17:36.968 query-errors: info: client @0x7f005c042820 172.23.11.77#61515 (ya.ru): view nets: query failed (REFUSED) for ya.ru/IN/A at ../../../bin/named/query.c:6980
 

Пользователь добавил сообщение [time]1586108850[/time]:

Указал DNSы прова, та же хрень...
Логи выше.
 
Добавлено:
Еще наблюдается странное поведение...

Код:
 
C:\Users\xxxxxx>nslookup ya.ru
╤хЁтхЁ:  UnKnown
Address:  172.23.11.1
 
*** UnKnown не удалось найти ya.ru: Query refused
 
C:\Users\xxxxxx>nslookup mail.domain.ru
╤хЁтхЁ:  UnKnown
Address:  172.23.11.1
 
╚ь :     mail.domain.ru
Address:  172.23.11.55
 

 
Добавлено:
Перенастроил логирование и получил такое:

Код:
 
05-Apr-2020 21:55:43.535 queries: info: client @0x7fb81c0aa9e0 172.23.11.77#51129 (1.11.23.172.in-addr.arpa): query: 1.11.23.172.in-addr.arpa IN PTR + (172.23.11.1)
05-Apr-2020 21:55:43.546 queries: info: client @0x7fb81c0aa9e0 172.23.11.77#51130 (ya.ru.l1.local): query: ya.ru.l1.local IN A + (172.23.11.1)
05-Apr-2020 21:55:43.547 security: info: client @0x7fb81c0aa9e0 172.23.11.77#51130 (ya.ru.l1.local): query (cache) 'ya.ru.l1.local/A/IN' denied
05-Apr-2020 21:55:43.547 query-errors: info: client @0x7fb81c0aa9e0 172.23.11.77#51130 (ya.ru.l1.local): query failed (REFUSED) for ya.ru.l1.local/IN/A at ../../../bin/named/query.c:6980
05-Apr-2020 21:55:43.548 queries: info: client @0x7fb81c0aa9e0 172.23.11.77#51131 (ya.ru.l1.local): query: ya.ru.l1.local IN AAAA + (172.23.11.1)
05-Apr-2020 21:55:43.548 security: info: client @0x7fb81c0aa9e0 172.23.11.77#51131 (ya.ru.l1.local): query (cache) 'ya.ru.l1.local/AAAA/IN' denied
05-Apr-2020 21:55:43.548 query-errors: info: client @0x7fb81c0aa9e0 172.23.11.77#51131 (ya.ru.l1.local): query failed (REFUSED) for ya.ru.l1.local/IN/AAAA at ../../../bin/named/query.c:6980
05-Apr-2020 21:55:43.550 queries: info: client @0x7fb81c0aa9e0 172.23.11.77#51132 (ya.ru): query: ya.ru IN A + (172.23.11.1)
05-Apr-2020 21:55:43.550 security: info: client @0x7fb81c0aa9e0 172.23.11.77#51132 (ya.ru): query (cache) 'ya.ru/A/IN' denied
05-Apr-2020 21:55:43.550 query-errors: info: client @0x7fb81c0aa9e0 172.23.11.77#51132 (ya.ru): query failed (REFUSED) for ya.ru/IN/A at ../../../bin/named/query.c:6980
05-Apr-2020 21:55:43.551 queries: info: client @0x7fb81c0aa9e0 172.23.11.77#51133 (ya.ru): query: ya.ru IN AAAA + (172.23.11.1)
05-Apr-2020 21:55:43.551 security: info: client @0x7fb81c0aa9e0 172.23.11.77#51133 (ya.ru): query (cache) 'ya.ru/AAAA/IN' denied
05-Apr-2020 21:55:43.551 query-errors: info: client @0x7fb81c0aa9e0 172.23.11.77#51133 (ya.ru): query failed (REFUSED) for ya.ru/IN/AAAA at ../../../bin/named/query.c:6980
05-Apr-2020 21:55:47.880 queries: info: client @0x7fb81c0aa9e0 172.23.11.77#55958 (win8.ipv6.microsoft.com): query: win8.ipv6.microsoft.com IN A + (172.23.11.1)
05-Apr-2020 21:55:47.880 security: info: client @0x7fb81c0aa9e0 172.23.11.77#55958 (win8.ipv6.microsoft.com): query (cache) 'win8.ipv6.microsoft.com/A/IN' denied
05-Apr-2020 21:55:47.880 query-errors: info: client @0x7fb81c0aa9e0 172.23.11.77#55958 (win8.ipv6.microsoft.com): query failed (REFUSED) for win8.ipv6.microsoft.com/IN/A at ../../../bin/named/query.c:6980
 

Почему он BIND ищет ya.ru в локальных зонах? И как это исправить?
Всего записей: 400 | Зарегистр. 02-02-2009 | Отправлено: 21:03 05-04-2020 | Исправлено: newhk, 21:20 05-04-2020
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
newhk
Вам allow-recursion { trusted; }; не мешает? Ваш 172.23.11.77, вроде как, не в trusted...
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 23:28 05-04-2020
newhk



BANNED		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Chupaka
Я уже писал, что это мой первый опыт.
Большое человеческое спасибо!
Добавил в trusted всю сеть.
Как я понимаю, так безопаснее, чем отключать данную настройку
Может еще посоветуете, как сделать, чтобы при запросе NSLOOKUPа не писал "не заслуживающий доверия ответ"? И как сделать работу BIND более безопасной?
Всего записей: 400 | Зарегистр. 02-02-2009 | Отправлено: 10:55 07-04-2020 | Исправлено: newhk, 10:56 07-04-2020
Chupaka



Silver Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
newhk
Всегда рад помочь. Увы, сто лет не работал уже с BIND'ом, так что по безопасности не подскажу.
 

Цитата:
как сделать, чтобы при запросе NSLOOKUPа не писал "не заслуживающий доверия ответ"?

Никак. Это не совсем удачный перевод фразы "Non-authoritative answer". Скорее, "неофициальный", чем "не заслуживающий доверия". Authoritative-ответы даёт сервер, обслуживающий доменную зону. Например, "nslookup ya.ru ns1.yandex.ru" не будет такого говорить. А если результат получен от стороннего сервера (например, локального или провайдерского) - то он по определению non-authoritative. Т.е. для вашего domain.ru он authoritative, а для внешних доменов - нет.
Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 12:14 07-04-2020
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12

Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Кеширующий DNS сервер для локальной сети на основе BIND 9


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru