Исходное сообщение
"Делегирование реверсной зоны c DDNS" Отправлено Licha Morada, 01-Апр-20 23:14
>> Оставьте всех в одной сети /24 (например 172.16.50.0/24), или разнесите на 2 >> или более сети /26 (например 172.16.50.0/26 и 172.16.50.192/26) в разных широковещательных >> доменах. Но не перемешивайте разные сети в одном домене, а то >> будут трудно предсказуемые результаты. > Спасибо что обратили внимание на проблемы топологии и маршрутизации, но в данный > момент я бы не хотел затрагивать эту тему - она заслуживает > отдельного топика. Данная схема прошла обкатку "в поле" и вроде без > замечаний, если будут проблемы буду решать их по мере поступления. Ради бога. Слона правильно есть по частям. Рекомендую на каждый чих отслеживать, не мешает ли это коммуникации между controller и addc1, между серверами и клиентами, и от правильного ли DHCP получают адрес склиенты. Я бы прямо сниффер поставил в нескольких терминалах, и смотрел, есть ли трафик везде где должен. А то мало ли... >[оверквотинг удален] >> controller:/var/named/50.16.172.db >> $ORIGIN 50.16.172.in-addr.arpa. >> 2            IN      PTR     controller.wsvirt.home. >> 3            IN      PTR     controller2.wsvirt.home. >> $GENERATE 193-254 $     IN     NS   addc1.ad.wsvirt.home. >> (но это не точно) >> (освежил здесь https://dnswatch.com/dns-docs/BIND-administration-guide/Bv9A...) > Да я тоже читал это руководство на сайте ISC https://kb.isc.org/docs/aa-01589 и ещё > массу других мануалов - во всех описывается один и тот же > рецепт с созданием CNAME. Обратите внимание, в моём примере нет CNAME. >> Что будет если >> dig ns 50.16.172.ddns @controller.wsvirt.home > получаю такое: > ;50.16.172.ddns.                       >  IN      NS Я думаю, этот неуспех прямо связан с проблемой. Чтобы узнать нужный адрес, клиенту требуется отрезольвить адрес в зоне 50.16.172.ddns, а не получается. > Мысль о том чтобы явно указать Бинду на сервере controller.wsvirt.home > использовать зону 50.16.172.ddns с сервера addc1.ad.wsvirt.home мне тоже приходила > в голову и пытался сделать форвардинг > ... > Однако это не помогло, я даже попробовал сделать addc1.ad.wsvirt.home авторитетным > мастером для зоны 50.16.172.ddns, но и это тоже бесполезно - реверсные > имена из этой зоны тогда вообще не резолвятся. А controller в принципе может достучаться до addc1? А наоборот? Подозреваю, что ваша топология шлёт вам привет. Пакеты controller->addc1 доходят, а обратно теряются, т.к. addc1 считает что controller находится в другой сети и к нему надо ходить через шлюз.

Ваше сообщение
Имя*:
EMail:	Для отправки новых сообщений в текущей нити на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> Оставьте всех в одной сети /24 (например 172.16.50.0/24), или разнесите на 2 >>> или более сети /26 (например 172.16.50.0/26 и 172.16.50.192/26) в разных широковещательных >>> доменах. Но не перемешивайте разные сети в одном домене, а то >>> будут трудно предсказуемые результаты. >> Спасибо что обратили внимание на проблемы топологии и маршрутизации, но в данный >> момент я бы не хотел затрагивать эту тему - она заслуживает >> отдельного топика. Данная схема прошла обкатку "в поле" и вроде без >> замечаний, если будут проблемы буду решать их по мере поступления. > Ради бога. Слона правильно есть по частям. > Рекомендую на каждый чих отслеживать, не мешает ли это коммуникации между controller > и addc1, между серверами и клиентами, и от правильного ли DHCP > получают адрес склиенты. > Я бы прямо сниффер поставил в нескольких терминалах, и смотрел, есть ли > трафик везде где должен. А то мало ли... >>[оверквотинг удален] >>> controller:/var/named/50.16.172.db >>> $ORIGIN 50.16.172.in-addr.arpa. >>> 2 IN PTR controller.wsvirt.home. >>> 3 IN PTR controller2.wsvirt.home. >>> $GENERATE 193-254 $ IN NS addc1.ad.wsvirt.home. >>> (но это не точно) >>> (освежил здесь https://dnswatch.com/dns-docs/BIND-administration-guide/Bv9ARM.ch06.xhtml#id2594682) >> Да я тоже читал это руководство на сайте ISC https://kb.isc.org/docs/aa-01589 и ещё >> массу других мануалов - во всех описывается один и тот же >> рецепт с созданием CNAME. > Обратите внимание, в моём примере нет CNAME. >>> Что будет если >>> dig ns 50.16.172.ddns @controller.wsvirt.home >> получаю такое: >> ;50.16.172.ddns. >> IN NS > Я думаю, этот неуспех прямо связан с проблемой. Чтобы узнать нужный адрес, > клиенту требуется отрезольвить адрес в зоне 50.16.172.ddns, а не получается. >> Мысль о том чтобы явно указать Бинду на сервере controller.wsvirt.home >> использовать зону 50.16.172.ddns с сервера addc1.ad.wsvirt.home мне тоже приходила >> в голову и пытался сделать форвардинг >> ... >> Однако это не помогло, я даже попробовал сделать [b]addc1.ad.wsvirt.home[/b] авторитетным >> мастером для зоны [b]50.16.172.ddns[/b], но и это тоже бесполезно - реверсные >> имена из этой зоны тогда вообще не резолвятся. > А controller в принципе может достучаться до addc1? А наоборот? > Подозреваю, что ваша топология шлёт вам привет. Пакеты controller->addc1 доходят, а обратно > теряются, т.к. addc1 считает что controller находится в другой сети и > к нему надо ходить через шлюз.
	Введите код, изображенный на картинке: