unbound forward-first

Dmitry Kolvakh написал(а) к All в Jun 18 20:06:48 по местному времени:

Нello, All.

Растолкуйте, пожалуйста, смысл параметра forward-first в конфиге unbound. А то смотрю в ман - вижу фигу, как-то там непонятно.

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android

Eugene Grosbein написал(а) к Dmitry Kolvakh в Jun 18 12:54:58 по местному времени:

06 июня 2018, среда, в 18:06 NOVT, Dmitry Kolvakh написал(а):

DK> Растолкуйте, пожалуйста, смысл параметра forward-first в конфиге unbound. А то
DK> смотрю в ман - вижу фигу, как-то там непонятно.

Опция для Forward Zone. По умолчанию запросы к Forward Zone выполняются
без применения собственной рекурсии unbound, а передаются форвардерам.

Но если эта опция включена и указанные для зоны forwarders возвращают SERVFAIL
или сами недоступны, то unbound всё же вернётся к собственной рекурсии,
то есть спросит как обычно сам у рутовых серверов, потом спросит у тех,
на кого укажут рутовые и так далее.

Eugene
--
В России каждый третий болеет СПИДом. Его зрачки расширены, веки красные,
и его всегда начинает ломать.
--- slrn/1.0.3 (FreeBSD)

Dmitry Kolvakh написал(а) к Eugene Grosbein в Jun 18 10:27:30 по местному времени:


Нi Eugene!

07 Jun 18, Eugene Grosbein wrote to Dmitry Kolvakh:

DK>> Растолкуйте, пожалуйста, смысл параметра forward-first в конфиге
DK>> unbound. А то смотрю в ман - вижу фигу, как-то там непонятно.

EG> Опция для Forward Zone. По умолчанию запросы к Forward Zone
EG> выполняются без применения собственной рекурсии unbound, а передаются
EG> форвардерам.

EG> Но если эта опция включена и указанные для зоны forwarders возвращают
EG> SERVFAIL или сами недоступны, то unbound всё же вернётся к собственной
EG> рекурсии, то есть спросит как обычно сам у рутовых серверов, потом
EG> спросит у тех, на кого укажут рутовые и так далее.

Спасибо, всё понятно!

Еще вопрос - какова логика выбора форвардеров и чем она управляется?
Запросы шлются равномерно на все форвардеры, или "на все и сразу", или можно как-то приоритеты задать?

В эхе нагуглил кое-что, но там на уровне предположений:

= ru.unix.bsd (2:5054/89.1) ===================================================
Msg : 90772 of 93281
From : Vova Uralsky 2:5030/257 18 Feb 17 16:43:20
To : Victor Sudakov
Subj : порты на восьмерке - всьо
===============================================================================
Нello Victor!

18 Feb 17 00:26, Victor Sudakov wrote to Vova Uralsky:

VU>> Он, простите, не не ждёт, а посылает на все и сразу, кто первый
VU>> отзовётся, тот и прав.
VS> tcpdump твои слова не подтверждает.

Видимо я путаю, конечно, видимо с dnsmasq --all-servers, мне почему-то казалось
что forward-first: yes тоже даёт такой эффект. Или давал, хз.

Regards,
Vova



--
Good Luck! - Dmitry V. Kolvakh aka Keu

--- GoldED+/W32-MINGW 1.1.5-b20060703

Eugene Grosbein написал(а) к Dmitry Kolvakh в Jun 18 15:26:41 по местному времени:

07 июня 2018, четверг, в 08:27 NOVT, Dmitry Kolvakh написал(а):

DK> Еще вопрос - какова логика выбора форвардеров и чем она управляется?
DK> Запросы шлются равномерно на все форвардеры, или "на все и сразу", или можно
DK> как-то приоритеты задать?

"На все сразу" точно никто не шлет, скорее всего так же, как и для рутовых
серверов - случайным выбором. А зачем нужно задавать приоритеты? Это всё
равно касается только первого запроса, дальше ответ кешируется и отдаётся
из кеша unbound.

Eugene
--- slrn/1.0.3 (FreeBSD)

Dmitry Kolvakh написал(а) к Eugene Grosbein в Jun 18 13:21:14 по местному времени:


Нi Eugene!

07 Jun 18, Eugene Grosbein wrote to Dmitry Kolvakh:

DK>> Еще вопрос - какова логика выбора форвардеров и чем она
DK>> управляется? Запросы шлются равномерно на все форвардеры, или "на
DK>> все и сразу", или можно как-то приоритеты задать?

EG> "На все сразу" точно никто не шлет, скорее всего так же, как и для
EG> рутовых серверов - случайным выбором. А зачем нужно задавать
EG> приоритеты? Это всё равно касается только первого запроса, дальше
EG> ответ кешируется и отдаётся из кеша unbound.

Я поднял на сервере мониторинга unbound, и некоторые мониторимые сервера стали пропадать и снова появляться с периодом порядка часа (но не строгопериодически, видимо по ТТЛ записи в кэше сдыхали и запрашивались снова). Как выяснилось, на одном из двух форвардеров не было вторичной зоны с этими серверами.
Это бы еще ладно, но вывод команды host был очень интересный:

% host xxx.xxxxx.ru
xxx.xxxxx.ru has address 10.xx.xx.xx
Нost xxx.xxxxx.ru not found: 3(NXDOMAIN)

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

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

--
Good Luck! - Dmitry V. Kolvakh aka Keu

--- GoldED+/W32-MINGW 1.1.5-b20060703

Eugene Grosbein написал(а) к Dmitry Kolvakh в Jun 18 23:33:10 по местному времени:

07 июня 2018, четверг, в 11:21 NOVT, Dmitry Kolvakh написал(а):

DK>>> Еще вопрос - какова логика выбора форвардеров и чем она
DK>>> управляется? Запросы шлются равномерно на все форвардеры, или "на
DK>>> все и сразу", или можно как-то приоритеты задать?
EG>> "На все сразу" точно никто не шлет, скорее всего так же, как и для
EG>> рутовых серверов - случайным выбором. А зачем нужно задавать
EG>> приоритеты? Это всё равно касается только первого запроса, дальше
EG>> ответ кешируется и отдаётся из кеша unbound.
DK> Я поднял на сервере мониторинга unbound, и некоторые мониторимые сервера стали
DK> пропадать и снова появляться с периодом порядка часа (но не строгопериодически,
DK> видимо по ТТЛ записи в кэше сдыхали и запрашивались снова). Как выяснилось, на
DK> одном из двух форвардеров не было вторичной зоны с этими серверами.

Если форвардер уверенно говорит, что такого имени нет (NXDOMAIN),
никто не станет переспрашивать. Ты путаешь с ошибкой при ресловинге (SERVFAIL).

DK> Это бы еще ладно, но вывод команды host был очень интересный:
DK> % host xxx.xxxxx.ru
DK> xxx.xxxxx.ru has address 10.xx.xx.xx
DK> Нost xxx.xxxxx.ru not found: 3(NXDOMAIN)
DK> Почему два ответа, явно от обоих форвардеров?

Это host делает несколько запросов, изменением настроек unbound
ты это не поправишь.

DK> Поэтому захотелось разобраться в принципе работы и настроить максимально
DK> отказоустойчиво.

Настраивай авторитетные сервера без ошибок - будет тебе отказоустойчиво :-)

Eugene
--- slrn/1.0.3 (FreeBSD)

Dmitry Kolvakh написал(а) к Eugene Grosbein в Jun 18 22:50:36 по местному времени:

Нello, Eugene Grosbein.
On 07.06.18 23:33 you wrote:

EG> 07 июня 2018, четверг, в 11:21 NOVT, Dmitry Kolvakh написал(а):
EG> Если форвардер уверенно говорит, что такого имени нет (NXDOMAIN),
EG> никто не станет переспрашивать. Ты путаешь с ошибкой при
EG> ресловинге (SERVFAIL).

Нет, я не путаю. Написал к тому, что обращения идут к разным форвардерам, и результат вечно в кэше не сидит.

DK>> Это бы еще ладно, но вывод команды host был очень интересный: %
DK>> host xxx.xxxxx.ru xxx.xxxxx.ru has address 10.xx.xx.xx Нost
DK>> xxx.xxxxx.ru not found: 3(NXDOMAIN) Почему два ответа, явно от
DK>> обоих форвардеров?
EG> Это host делает несколько запросов, изменением настроек unbound ты
EG> это не поправишь.

А host разве сам в dns лезет, не через прописанные в resolv.conf сервера? (когда ему явно не укажешь сервер)

DK>> Поэтому захотелось разобраться в принципе работы и настроить
DK>> максимально отказоустойчиво.
EG> Настраивай авторитетные сервера без ошибок - будет тебе
EG> отказоустойчиво :-)

Авторитетный сервер может страдать от сетевых катаклизмов, и именно в этот момент желательно чтоб мониторинг тщательно фиксировал детали катаклизма. Но да, я слишком раздуваю вопрос. Достаточно аккуратно настроить. Смутил момент насчет "всем и сразу".

--
Best regards!
--- Нotdoged/2.13.5/Android

Eugene Grosbein написал(а) к Dmitry Kolvakh в Jun 18 03:10:18 по местному времени:

07 июня 2018, четверг, в 20:50 NOVT, Dmitry Kolvakh написал(а):

EG>> Если форвардер уверенно говорит, что такого имени нет (NXDOMAIN),
EG>> никто не станет переспрашивать. Ты путаешь с ошибкой при
EG>> ресловинге (SERVFAIL).
DK> Нет, я не путаю. Написал к тому, что обращения идут к разным форвардерам, и
DK> результат вечно в кэше не сидит.

Нет, путаешь. Запусти tcpdump -i lo0 -vvvns0 port 53 и увидишь,
что на самом деле происходит.

DK>>> Это бы еще ладно, но вывод команды host был очень интересный: %
DK>>> host xxx.xxxxx.ru xxx.xxxxx.ru has address 10.xx.xx.xx Нost
DK>>> xxx.xxxxx.ru not found: 3(NXDOMAIN) Почему два ответа, явно от
DK>>> обоих форвардеров?
EG>> Это host делает несколько запросов, изменением настроек unbound ты
EG>> это не поправишь.
DK> А host разве сам в dns лезет, не через прописанные в resolv.conf сервера?
DK> (когда ему явно не укажешь сервер)

host отличается от "обычных" приложений тем, что он не использует
системный ресолвер (как это делает ping, например). host содержит внутри
себя собственный ресолвер и поэтому, например, не смотрит в /etc/hosts,
в отличие от других утилит типа ping. Но да, если ему не указать явно
сервер, он настраивает собственный ресолвер ходить через серверы,
прописанные в /etc/hosts.

Ещё раз указываю на то, что hosts сам делает несколько запросов к серверу
и при сбое любого из них он добавляет локальный домен поиска из
/etc/resolv.conf к имени запрашиваемого домена, если оно не заканчивается
на точку. И он может выдать ту твою ошибку из-за возврата NXDOMAIN
в ответ на запрос такого "дополненного" имени. Поэтому для чистоты
эксперимента надо, во-первых, всегда добавлять точку, а во-вторых,
запускать tcpdump, чтобы видеть, сколько и какие реально запросы уходят
к серверу от hosts, будешь удивлён - если не читал внимательно man hosts,
там тащем-то это всё расписано.

DK>>> Поэтому захотелось разобраться в принципе работы и настроить
DK>>> максимально отказоустойчиво.
EG>> Настраивай авторитетные сервера без ошибок - будет тебе
EG>> отказоустойчиво :-)
DK> Авторитетный сервер может страдать от сетевых катаклизмов, и именно в этот
DK> момент желательно чтоб мониторинг тщательно фиксировал детали катаклизма.

Ты всё ещё путаешь отсутствие ответа от авторитетного сервера или ответ
SERVFAIL с NXDOMAIN. Перебор серверов не выполняется для NXDOMAIN,
а тебе кажется, что выполняется из вывода hosts, потому что у тебя
неверное представление о том, как hosts работает. tcpdump всё покажет.

Eugene
--- slrn/1.0.3 (FreeBSD)

Dmitry Kolvakh написал(а) к Eugene Grosbein в Jun 18 13:31:20 по местному времени:


Нi Eugene!

08 Jun 18, Eugene Grosbein wrote to Dmitry Kolvakh:

EG>>> Если форвардер уверенно говорит, что такого имени нет
EG>>> (NXDOMAIN), никто не станет переспрашивать. Ты путаешь с ошибкой
EG>>> при ресловинге (SERVFAIL).
DK>> Нет, я не путаю. Написал к тому, что обращения идут к разным
DK>> форвардерам, и результат вечно в кэше не сидит.

EG> Нет, путаешь. Запусти tcpdump -i lo0 -vvvns0 port 53 и увидишь,
EG> что на самом деле происходит.

Нет, я понимаю, что NXDOMAIN - это хороший, годный ответ, и что unbound им удовлетворяется и добросовестно хранит в кэше. Видимо, в целом косноязычно изъясняюсь.

EG> host отличается от "обычных" приложений тем, что он не использует
EG> системный ресолвер (как это делает ping, например). host содержит
EG> внутри себя собственный ресолвер

...

EG> Ещё раз указываю на то, что hosts сам делает несколько запросов к

А вот этого я не знал и не понимал, отчего вывод host казался странным. Спасибо за пояснения.

EG> будешь удивлён - если не
EG> читал внимательно man hosts, там тащем-то это всё расписано.

Не читал, конечно же.

DK>> Авторитетный сервер может страдать от сетевых катаклизмов, и
DK>> именно в этот момент желательно чтоб мониторинг тщательно
DK>> фиксировал детали катаклизма.

EG> Ты всё ещё путаешь отсутствие ответа от авторитетного сервера или
EG> ответ SERVFAIL с NXDOMAIN.

В случае катаклизма, скорее всего, будут просто таймауты (задумается роутер). Или сервер будет давать отлуп из-за превышения лимита запросов.

Я вообще подумывал, не взгромоздить ли прямо на мониторинг свой bind с блэкдж^W парочкой вторичных зон, содержащих адреса мониторимых хостов. Но unbound кстати попался на глаза.


--
Good Luck! - Dmitry V. Kolvakh aka Keu

--- GoldED+/W32-MINGW 1.1.5-b20060703

Eugene Grosbein написал(а) к Dmitry Kolvakh в Jun 18 20:19:50 по местному времени:

08 июня 2018, пятница, в 11:31 NOVT, Dmitry Kolvakh написал(а):

DK> Я вообще подумывал, не взгромоздить ли прямо на мониторинг свой bind с блэкдж^W
DK> парочкой вторичных зон, содержащих адреса мониторимых хостов.

Вполне достаточно будет локального кеширующего рекурсора,
сами зоны дублировать нет никакой необходимости.
Собственно, ради этого и придумали кеши, чтобы не дублировать зоны.


Eugene
--
Чтобы всё как у всех, но чтоб при этом - не так, как они.
--- slrn/1.0.3 (FreeBSD)