Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости от интерфейса, с которого пришёл запрос?
> Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости
> от интерфейса, с которого пришёл запрос?по моему нет, но могу и ошибаться.
может попробовать ip интерфейсов в match-destinations указывать, если конечно bind их слушает
> Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости
> от интерфейса, с которого пришёл запрос?Ну логично разным клиентам отдавать разные вьюхи.
Любопытно, зачем одному клиенту отдавать разные в зависимости от маршрута по которому он пришел?
>> Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости
>> от интерфейса, с которого пришёл запрос?
> Ну логично разным клиентам отдавать разные вьюхи.
> Любопытно, зачем одному клиенту отдавать разные в зависимости от маршрута по которому
> он пришел?некое подобие гео днс ;)
>>> Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости
>>> от интерфейса, с которого пришёл запрос?
>> Ну логично разным клиентам отдавать разные вьюхи.
>> Любопытно, зачем одному клиенту отдавать разные в зависимости от маршрута по которому
>> он пришел?
> некое подобие гео днс ;)посадите основной отдающий на лупбэк, а на каждый интерфейс -- кэширующий фровардер.
форвардер будет приходить к основному с адресом интерфейса, по нему и матчить.
правда, основной потеряет адреса конечных клиентов, будет матчить только интерфейс.
>>>> Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости
>>>> от интерфейса, с которого пришёл запрос?
>>> Ну логично разным клиентам отдавать разные вьюхи.
>>> Любопытно, зачем одному клиенту отдавать разные в зависимости от маршрута по которому
>>> он пришел?
>> некое подобие гео днс ;)
> посадите основной отдающий на лупбэк, а на каждый интерфейс -- кэширующий фровардер.
> форвардер будет приходить к основному с адресом интерфейса, по нему и матчить.
> правда, основной потеряет адреса конечных клиентов, будет матчить только интерфейс.Я думал насчёт кэширующего DNS, хотел его воткнуть на свич, но он и этого делать не умеет. Ваша идея очень хорошая, спасибо!
>> Можно ли сделать так, чтобы BIND выдавал определённый View зоны в зависимости
>> от интерфейса, с которого пришёл запрос?
> Ну логично разным клиентам отдавать разные вьюхи.
> Любопытно, зачем одному клиенту отдавать разные в зависимости от маршрута по которому
> он пришел?Всё очень просто. Есть l3 свич, который PBR переключается на резервный канал, если падает основной. При переключении меняется внешняя подсесть и часть обпубликованых сервисов становится извне недоступными. Т.е. нужно сделать, чтобы DNS выдавало актуальную инфу в зависимости от состояния каналов. Самый очевидный вариант - DDNS, но cat 3750x не умеет DDNS. Поэтому идея следующая - свич в зависимости от состояния каналов перенаправляет DNS-запросы на разные интерфейсы DNS, который в свою очередь в зависимости от интерфейса выдаёт разные view. В этой схеме не получится использовать source-адрес клиента, т.к. независимо от канала он будет одинаковый.
>[оверквотинг удален]
>> он пришел?
> Всё очень просто. Есть l3 свич, который PBR переключается на резервный канал,
> если падает основной. При переключении меняется внешняя подсесть и часть обпубликованых
> сервисов становится извне недоступными. Т.е. нужно сделать, чтобы DNS выдавало актуальную
> инфу в зависимости от состояния каналов. Самый очевидный вариант - DDNS,
> но cat 3750x не умеет DDNS. Поэтому идея следующая - свич
> в зависимости от состояния каналов перенаправляет DNS-запросы на разные интерфейсы DNS,
> который в свою очередь в зависимости от интерфейса выдаёт разные view.
> В этой схеме не получится использовать source-адрес клиента, т.к. независимо от
> канала он будет одинаковый.1) фиксировать факт смены канала на серваке
2) по факту менять конфигу сервера подсовыванием конфига с нужными ЗОНАМИ, а не видами
3) + установить небольшой TTL
>[оверквотинг удален]
>> он пришел?
> Всё очень просто. Есть l3 свич, который PBR переключается на резервный канал,
> если падает основной. При переключении меняется внешняя подсесть и часть обпубликованых
> сервисов становится извне недоступными. Т.е. нужно сделать, чтобы DNS выдавало актуальную
> инфу в зависимости от состояния каналов. Самый очевидный вариант - DDNS,
> но cat 3750x не умеет DDNS. Поэтому идея следующая - свич
> в зависимости от состояния каналов перенаправляет DNS-запросы на разные интерфейсы DNS,
> который в свою очередь в зависимости от интерфейса выдаёт разные view.
> В этой схеме не получится использовать source-адрес клиента, т.к. независимо от
> канала он будет одинаковый.Хотите выставить TTL 60 и потестировать тяжело нагруженный dns. (блин, звучит-то как по дурацки, не корень ведь). Не проще с провайдерами о bgp договориться?
>[оверквотинг удален]
>> сервисов становится извне недоступными. Т.е. нужно сделать, чтобы DNS выдавало актуальную
>> инфу в зависимости от состояния каналов. Самый очевидный вариант - DDNS,
>> но cat 3750x не умеет DDNS. Поэтому идея следующая - свич
>> в зависимости от состояния каналов перенаправляет DNS-запросы на разные интерфейсы DNS,
>> который в свою очередь в зависимости от интерфейса выдаёт разные view.
>> В этой схеме не получится использовать source-адрес клиента, т.к. независимо от
>> канала он будет одинаковый.
> Хотите выставить TTL 60 и потестировать тяжело нагруженный dns. (блин, звучит-то как
> по дурацки, не корень ведь). Не проще с провайдерами о bgp
> договориться?Хочу выставить TTL в 5 минут, причём не для всей зоны, а для конкретных записей. К большой нагрузке это не приведёт, а для наших задач вполне достаточно. Развернуть BGP мысль хорошая, но в наших условиях можно обойтись и более простым решением.
>[оверквотинг удален]
>>> который в свою очередь в зависимости от интерфейса выдаёт разные view.
>>> В этой схеме не получится использовать source-адрес клиента, т.к. независимо от
>>> канала он будет одинаковый.
>> Хотите выставить TTL 60 и потестировать тяжело нагруженный dns. (блин, звучит-то как
>> по дурацки, не корень ведь). Не проще с провайдерами о bgp
>> договориться?
> Хочу выставить TTL в 5 минут, причём не для всей зоны, а
> для конкретных записей. К большой нагрузке это не приведёт, а для
> наших задач вполне достаточно. Развернуть BGP мысль хорошая, но в наших
> условиях можно обойтись и более простым решением.возможно еще вариант проще сработает
1) пишете дублирущее записи для нужных:
domain.ru A 123.123.123.123 (основной канал)
domain.ru A 321.321.321.321 (резервный)
2) отключаете цикличный порядок выдачи записей
>[оверквотинг удален]
>> он пришел?
> Всё очень просто. Есть l3 свич, который PBR переключается на резервный канал,
> если падает основной. При переключении меняется внешняя подсесть и часть обпубликованых
> сервисов становится извне недоступными. Т.е. нужно сделать, чтобы DNS выдавало актуальную
> инфу в зависимости от состояния каналов. Самый очевидный вариант - DDNS,
> но cat 3750x не умеет DDNS. Поэтому идея следующая - свич
> в зависимости от состояния каналов перенаправляет DNS-запросы на разные интерфейсы DNS,
> который в свою очередь в зависимости от интерфейса выдаёт разные view.
> В этой схеме не получится использовать source-адрес клиента, т.к. независимо от
> канала он будет одинаковый.Давайте начнем с ответа на вопрос, почему при разных состояниях канала у вас в принципе будут идти запросы на один и тот же DNS-сервер.
разыграйте через iptables - DNAT, по условию интерфейса делайте DNAT в различные локальные/внутренние IP или порты. На разных айпи/портах обеспечьте поддержку нужных вам ответов (накрайняк можно несколько инстансов DNS-сервера поднять).