forum.opennet.ru

Форум Открытые системы на сервере (DNS / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Делегирование реверсной зоны c DDNS, teegor (ok), 01-Апр-20, (0) [смотреть все]

В смысле, интервал 172 16 50 192-254 внутри подсети 172 16 50 0 24, или у вас дв, Licha Morada (ok), 04:45 , 01-Апр-20, (1) //

Спасибо что обратили внимание на проблемы топологии и маршрутизации, но в данный, teegor (ok), 22:29 , 01-Апр-20, (2) //

Ради бога Слона правильно есть по частям Рекомендую на каждый чих отслеживать, , Licha Morada (ok), 23:14 , 01-Апр-20, (3) //

Ну если верить tcpdump то сервера в общем то между собой общаются и находят друг, teegor (ok), 02:37 , 02-Апр-20, (4)

Это вы на каком хосте tcpdump делали, и где dig запускали , Licha Morada (ok), 03:11 , 02-Апр-20, (5)

tcpdump на controller а dig на клиентской системе, teegor (ok), 03:46 , 02-Апр-20, (6)

Тогда надо логи BIND смотреть, почему он не получил ответ PTR addc1 ad wsvirt h, Licha Morada (ok), 03:54 , 02-Апр-20, (7)

Нашёл я где собака порылась Bind 9 не умеет работать с DNSSEC когда используетс, teegor (ok), 16:34 , 02-Апр-20, (8)

Сообщения [Сортировка по времени | RSS]

1. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от Licha Morada (ok), 01-Апр-20, 04:45

> есть сеть 172.16.50/24
> Для домена AD я решил выделить подсеть 172.16.50.192/26
В смысле, интервал 172.16.50.192-254 внутри подсети 172.16.50.0/24, или у вас две (пересекающихся) сети находятся в одном и том-же широковещательном домене?
Какие маски сети на у controller.wsvirt.home и у addc1.ad.wsvirt.home? Вывода "ip route" будет достаточно.
> В реальности все клиентские системы должны быть в одном широковещательном домене.
В одном домене друг с другом, или в одном домене вместе с controller, controller2 и addc1?
Если все в одном широковещательном домене, то у вас, кажется, будет race condition между dhcpd развёрнутом на controller и на addc1. Они оба будут пытаться отвечать одному и тому-же клиенту.
Оставьте всех в одной сети /24 (например 172.16.50.0/24), или разнесите на 2 или более сети /26 (например 172.16.50.0/26 и 172.16.50.192/26) в разных широковещательных доменах. Но не перемешивайте разные сети в одном домене, а то будут трудно предсказуемые результаты.

По существу делегирования обратной зоны, соответствующей classless CIDR (то есть сети не /0, /8, /16 или /24). Так можно, но через костыли. Дело в том что DNS умеет в иерархию обратных зон используя десятичную нотацию адресов IP и точку как разделитель. Он может отличить, например, 172.16.50.0/24 от 172.16.51.0/24. А 172.16.50.0/25 от 172.16.50.128/25 не может, так как на половине последнего октета, в десятичной нотации, точку не поставишь.
Но, я полагаю, вы об этом уже всё прочитали и не устрашились.
> Мне нужно чтобы Linux клиенты из домена wsvirt.home могли разрешать реверсные имена
> в домене ad.wsvirt.home. Как это можно сделать и можно ли вообще
> это сделать?
Собственно, ваш "$GENERATE 193-254" эти костыли и есть. Оно вам надо? Не проще ли будет вашу лабораторию разнести на разные classful подсети?
У вас лаборатория по Самбе, или по экзотическим случаям делегирования обратных зон DNS?

Я однажды делал примерно так:
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...)

Говорят, по RFC2317 можно и так:
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.
192/26                  IN      NS      addc1.ad.wsvirt.home.
$GENERATE 193-254 $     IN      CNAME   $.192/26.50.16.172.in-addr.arpa.
(подсмотрел на https://superuser.com/questions/1450158/bind-create-reverse-...)
Но читаем https://www.ietf.org/rfc/rfc2317.txt:
Some DNS implementations are not kind to special characters in domain names, e.g. the "/" used in the above examples.

Я подозреваю, что в вашей конфигурации кто-то непрвильно обрабатывает ответ CNAME от controller.
Что будет если
dig ns 50.16.172.ddns @controller.wsvirt.home
?
Ещё можно попробоать как-то обозначить зону 50.16.172.ddns на controller. Есть гипотеза что он не знает что делать с запросами о *.ddns.
Например, задать её в качестве slave или forward.

Ответить | Правка | Наверх | Cообщить модератору

2. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от teegor (ok), 01-Апр-20, 22:29

> Оставьте всех в одной сети /24 (например 172.16.50.0/24), или разнесите на 2
> или более сети /26 (например 172.16.50.0/26 и 172.16.50.192/26) в разных широковещательных
> доменах. Но не перемешивайте разные сети в одном домене, а то
> будут трудно предсказуемые результаты.
Спасибо что обратили внимание на проблемы топологии и маршрутизации, но в данный момент я бы не хотел затрагивать эту тему - она заслуживает отдельного топика. Данная схема прошла обкатку "в поле" и вроде без замечаний, если будут проблемы буду решать их по мере поступления.

> Собственно, ваш "$GENERATE 193-254" эти костыли и есть. Оно вам надо? Не
> проще ли будет вашу лабораторию разнести на разные classful подсети?
> У вас лаборатория по Самбе, или по экзотическим случаям делегирования обратных зон
> DNS?
Костыль и есть - костыль из RFC 2317, конечно проще было бы вынести AD в другой бродкаст домен и выделить ему сеть класса C, но задача у меня сделать так как я описал. Лаборатория в основном для обкатки связки DNS+DHCP+Samba и за исключением описанной проблемы всё работает хорошо.

> Я однажды делал примерно так:
> 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.

> Что будет если
> dig ns 50.16.172.ddns @controller.wsvirt.home
Если я сейчас выполняю команду
dig ns 50.16.172.ddns @controller.wsvirt.home
то получаю такое:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> ns 50.16.172.ddns @controller.wsvirt.home
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16226
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;50.16.172.ddns.                        IN      NS
;; AUTHORITY SECTION:
.                       10771   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2020040101 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 172.16.50.2#53(172.16.50.2)
;; WHEN: Wed Apr 01 22:16:02 IDT 2020
;; MSG SIZE  rcvd: 118

> Ещё можно попробоать как-то обозначить зону 50.16.172.ddns на controller. Есть гипотеза
> что он не знает что делать с запросами о *.ddns.
> Например, задать её в качестве slave или forward.
Мысль о том чтобы явно указать Бинду на сервере controller.wsvirt.home использовать зону 50.16.172.ddns с сервера addc1.ad.wsvirt.home мне тоже приходила в голову и пытался сделать форвардинг, добавив в named.conf на controller.wsvirt.home:

zone "50.16.172.ddns." {
    type forward;
    forwarders { 172.16.50.193; };
};
Однако это не помогло, я даже попробовал сделать addc1.ad.wsvirt.home авторитетным мастером для зоны 50.16.172.ddns, но и это тоже бесполезно - реверсные имена из этой зоны тогда вообще не резолвятся.

Ответить | Правка | Наверх | Cообщить модератору

3. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от Licha Morada (ok), 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 находится в другой сети и к нему надо ходить через шлюз.

Ответить | Правка | Наверх | Cообщить модератору

4. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от teegor (ok), 02-Апр-20, 02:37

> А controller в принципе может достучаться до addc1? А наоборот?
> Подозреваю, что ваша топология шлёт вам привет. Пакеты controller->addc1 доходят, а обратно
> теряются, т.к. addc1 считает что controller находится в другой сети и
> к нему надо ходить через шлюз.
Ну если верить tcpdump то сервера в общем то между собой общаются и находят друг друга:

# tcpdump -vvvnni eth0 port 53 and host 172.16.50.193
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:45:46.748934 IP (tos 0x0, ttl 64, id 53368, offset 0, flags [none], proto UDP (17), length 75)
    172.16.50.2.35597 > 172.16.50.193.53: [bad udp cksum 0xbd2c -> 0xd63d!] 101+% [1au] PTR? 193.50.16.172.ddns. ar: . OPT UDPsize=4096 DO (47)
23:45:46.751086 IP (tos 0x0, ttl 63, id 14698, offset 0, flags [none], proto UDP (17), length 109)
    172.16.50.193.53 > 172.16.50.2.35597: [bad udp cksum 0xbd4e -> 0x21cf!] 101* q: PTR? 193.50.16.172.ddns. 1/0/1 193.50.16.172.ddns. [15m] PTR addc1.ad.wsvirt.home. ar: . OPT UDPsize=4096 (81)
23:45:47.070016 IP (tos 0x0, ttl 64, id 53531, offset 0, flags [none], proto UDP (17), length 75)
    172.16.50.2.53475 > 172.16.50.193.53: [bad udp cksum 0xbd2c -> 0xb0ec!] 57280+% [1au] DS? 193.50.16.172.ddns. ar: . OPT UDPsize=4096 DO (47)
23:45:47.072165 IP (tos 0x0, ttl 64, id 15002, offset 0, flags [none], proto UDP (17), length 142)
    172.16.50.193.53 > 172.16.50.2.53475: [bad udp cksum 0xbd6f -> 0x2d30!] 57280* q: DS? 193.50.16.172.ddns. 0/1/1 ns: 50.16.172.ddns. [1h] SOA addc1.ad.wsvirt.home. hostmaster.ad.wsvirt.home. 3 900 600 86400 3600 ar: . OPT UDPsize=4096 (114)

Это я сделал дамп во время выполнения команды
dig -x 172.16.50.193 @controller.wsvirt.home

Ответить | Правка | Наверх | Cообщить модератору

5. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от Licha Morada (ok), 02-Апр-20, 03:11

>> А controller в принципе может достучаться до addc1? А наоборот?
>> Подозреваю, что ваша топология шлёт вам привет. Пакеты controller->addc1 доходят, а обратно
>> теряются, т.к. addc1 считает что controller находится в другой сети и
>> к нему надо ходить через шлюз.
> Ну если верить tcpdump то сервера в общем то между собой общаются
> и находят друг друга:
> ...
> Это я сделал дамп во время выполнения команды
> dig -x 172.16.50.193 @controller.wsvirt.home
Это вы на каком хосте tcpdump делали, и где dig запускали?

Ответить | Правка | Наверх | Cообщить модератору

6. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от teegor (ok), 02-Апр-20, 03:46

> Это вы на каком хосте tcpdump делали, и где dig запускали?
tcpdump на controller а dig на клиентской системе

Ответить | Правка | Наверх | Cообщить модератору

7. "Делегирование реверсной зоны c DDNS" +/–

Сообщение от Licha Morada (ok), 02-Апр-20, 03:54

>> Это вы на каком хосте tcpdump делали, и где dig запускали?
> tcpdump на controller а dig на клиентской системе
Тогда надо логи BIND смотреть, почему он не получил ответ "PTR addc1.ad.wsvirt.home." а клиенту не сказал.
И заодно tcpdump ответа клиентской системе, на controller и на ней самой, а то вдруг он сказал.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Делегирование реверсной зоны c DDNS"	+/–
Сообщение от Licha Morada (ok), 01-Апр-20, 04:45
> есть сеть 172.16.50/24 > Для домена AD я решил выделить подсеть 172.16.50.192/26 В смысле, интервал 172.16.50.192-254 внутри подсети 172.16.50.0/24, или у вас две (пересекающихся) сети находятся в одном и том-же широковещательном домене? Какие маски сети на у controller.wsvirt.home и у addc1.ad.wsvirt.home? Вывода "ip route" будет достаточно. > В реальности все клиентские системы должны быть в одном широковещательном домене. В одном домене друг с другом, или в одном домене вместе с controller, controller2 и addc1? Если все в одном широковещательном домене, то у вас, кажется, будет race condition между dhcpd развёрнутом на controller и на addc1. Они оба будут пытаться отвечать одному и тому-же клиенту. Оставьте всех в одной сети /24 (например 172.16.50.0/24), или разнесите на 2 или более сети /26 (например 172.16.50.0/26 и 172.16.50.192/26) в разных широковещательных доменах. Но не перемешивайте разные сети в одном домене, а то будут трудно предсказуемые результаты. По существу делегирования обратной зоны, соответствующей classless CIDR (то есть сети не /0, /8, /16 или /24). Так можно, но через костыли. Дело в том что DNS умеет в иерархию обратных зон используя десятичную нотацию адресов IP и точку как разделитель. Он может отличить, например, 172.16.50.0/24 от 172.16.51.0/24. А 172.16.50.0/25 от 172.16.50.128/25 не может, так как на половине последнего октета, в десятичной нотации, точку не поставишь. Но, я полагаю, вы об этом уже всё прочитали и не устрашились. > Мне нужно чтобы Linux клиенты из домена wsvirt.home могли разрешать реверсные имена > в домене ad.wsvirt.home. Как это можно сделать и можно ли вообще > это сделать? Собственно, ваш "$GENERATE 193-254" эти костыли и есть. Оно вам надо? Не проще ли будет вашу лабораторию разнести на разные classful подсети? У вас лаборатория по Самбе, или по экзотическим случаям делегирования обратных зон DNS? Я однажды делал примерно так: 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...) Говорят, по RFC2317 можно и так: 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. 192/26 IN NS addc1.ad.wsvirt.home. $GENERATE 193-254 $ IN CNAME $.192/26.50.16.172.in-addr.arpa. (подсмотрел на https://superuser.com/questions/1450158/bind-create-reverse-...) Но читаем https://www.ietf.org/rfc/rfc2317.txt: Some DNS implementations are not kind to special characters in domain names, e.g. the "/" used in the above examples. Я подозреваю, что в вашей конфигурации кто-то непрвильно обрабатывает ответ CNAME от controller. Что будет если dig ns 50.16.172.ddns @controller.wsvirt.home ? Ещё можно попробоать как-то обозначить зону 50.16.172.ddns на controller. Есть гипотеза что он не знает что делать с запросами о *.ddns. Например, задать её в качестве slave или forward.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Делегирование реверсной зоны c DDNS"	+/–
	Сообщение от teegor (ok), 01-Апр-20, 22:29
	> Оставьте всех в одной сети /24 (например 172.16.50.0/24), или разнесите на 2 > или более сети /26 (например 172.16.50.0/26 и 172.16.50.192/26) в разных широковещательных > доменах. Но не перемешивайте разные сети в одном домене, а то > будут трудно предсказуемые результаты. Спасибо что обратили внимание на проблемы топологии и маршрутизации, но в данный момент я бы не хотел затрагивать эту тему - она заслуживает отдельного топика. Данная схема прошла обкатку "в поле" и вроде без замечаний, если будут проблемы буду решать их по мере поступления. > Собственно, ваш "$GENERATE 193-254" эти костыли и есть. Оно вам надо? Не > проще ли будет вашу лабораторию разнести на разные classful подсети? > У вас лаборатория по Самбе, или по экзотическим случаям делегирования обратных зон > DNS? Костыль и есть - костыль из RFC 2317, конечно проще было бы вынести AD в другой бродкаст домен и выделить ему сеть класса C, но задача у меня сделать так как я описал. Лаборатория в основном для обкатки связки DNS+DHCP+Samba и за исключением описанной проблемы всё работает хорошо. > Я однажды делал примерно так: > 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. > Что будет если > dig ns 50.16.172.ddns @controller.wsvirt.home Если я сейчас выполняю команду dig ns 50.16.172.ddns @controller.wsvirt.home то получаю такое: ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> ns 50.16.172.ddns @controller.wsvirt.home ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16226 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;50.16.172.ddns. IN NS ;; AUTHORITY SECTION: . 10771 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020040101 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: 172.16.50.2#53(172.16.50.2) ;; WHEN: Wed Apr 01 22:16:02 IDT 2020 ;; MSG SIZE rcvd: 118 > Ещё можно попробоать как-то обозначить зону 50.16.172.ddns на controller. Есть гипотеза > что он не знает что делать с запросами о .ddns. > Например, задать её в качестве slave или forward. Мысль о том чтобы явно указать Бинду на сервере controller.wsvirt.home* использовать зону 50.16.172.ddns с сервера addc1.ad.wsvirt.home мне тоже приходила в голову и пытался сделать форвардинг, добавив в named.conf на controller.wsvirt.home: zone "50.16.172.ddns." { type forward; forwarders { 172.16.50.193; }; }; Однако это не помогло, я даже попробовал сделать addc1.ad.wsvirt.home авторитетным мастером для зоны 50.16.172.ddns, но и это тоже бесполезно - реверсные имена из этой зоны тогда вообще не резолвятся.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Делегирование реверсной зоны c DDNS"	+/–
	Сообщение от Licha Morada (ok), 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 находится в другой сети и к нему надо ходить через шлюз.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Делегирование реверсной зоны c DDNS"	+/–
	Сообщение от teegor (ok), 02-Апр-20, 02:37
	> А controller в принципе может достучаться до addc1? А наоборот? > Подозреваю, что ваша топология шлёт вам привет. Пакеты controller->addc1 доходят, а обратно > теряются, т.к. addc1 считает что controller находится в другой сети и > к нему надо ходить через шлюз. Ну если верить tcpdump то сервера в общем то между собой общаются и находят друг друга: # tcpdump -vvvnni eth0 port 53 and host 172.16.50.193 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 23:45:46.748934 IP (tos 0x0, ttl 64, id 53368, offset 0, flags [none], proto UDP (17), length 75) 172.16.50.2.35597 > 172.16.50.193.53: [bad udp cksum 0xbd2c -> 0xd63d!] 101+% [1au] PTR? 193.50.16.172.ddns. ar: . OPT UDPsize=4096 DO (47) 23:45:46.751086 IP (tos 0x0, ttl 63, id 14698, offset 0, flags [none], proto UDP (17), length 109) 172.16.50.193.53 > 172.16.50.2.35597: [bad udp cksum 0xbd4e -> 0x21cf!] 101* q: PTR? 193.50.16.172.ddns. 1/0/1 193.50.16.172.ddns. [15m] PTR addc1.ad.wsvirt.home. ar: . OPT UDPsize=4096 (81) 23:45:47.070016 IP (tos 0x0, ttl 64, id 53531, offset 0, flags [none], proto UDP (17), length 75) 172.16.50.2.53475 > 172.16.50.193.53: [bad udp cksum 0xbd2c -> 0xb0ec!] 57280+% [1au] DS? 193.50.16.172.ddns. ar: . OPT UDPsize=4096 DO (47) 23:45:47.072165 IP (tos 0x0, ttl 64, id 15002, offset 0, flags [none], proto UDP (17), length 142) 172.16.50.193.53 > 172.16.50.2.53475: [bad udp cksum 0xbd6f -> 0x2d30!] 57280* q: DS? 193.50.16.172.ddns. 0/1/1 ns: 50.16.172.ddns. [1h] SOA addc1.ad.wsvirt.home. hostmaster.ad.wsvirt.home. 3 900 600 86400 3600 ar: . OPT UDPsize=4096 (114) Это я сделал дамп во время выполнения команды dig -x 172.16.50.193 @controller.wsvirt.home
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Делегирование реверсной зоны c DDNS"	+/–
	Сообщение от Licha Morada (ok), 02-Апр-20, 03:11
	>> А controller в принципе может достучаться до addc1? А наоборот? >> Подозреваю, что ваша топология шлёт вам привет. Пакеты controller->addc1 доходят, а обратно >> теряются, т.к. addc1 считает что controller находится в другой сети и >> к нему надо ходить через шлюз. > Ну если верить tcpdump то сервера в общем то между собой общаются > и находят друг друга: > ... > Это я сделал дамп во время выполнения команды > dig -x 172.16.50.193 @controller.wsvirt.home Это вы на каком хосте tcpdump делали, и где dig запускали?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Делегирование реверсной зоны c DDNS"	+/–
	Сообщение от teegor (ok), 02-Апр-20, 03:46
	> Это вы на каком хосте tcpdump делали, и где dig запускали? tcpdump на controller а dig на клиентской системе
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Делегирование реверсной зоны c DDNS"	+/–
	Сообщение от Licha Morada (ok), 02-Апр-20, 03:54
	>> Это вы на каком хосте tcpdump делали, и где dig запускали? > tcpdump на controller а dig на клиентской системе Тогда надо логи BIND смотреть, почему он не получил ответ "PTR addc1.ad.wsvirt.home." а клиенту не сказал. И заодно tcpdump ответа клиентской системе, на controller и на ней самой, а то вдруг он сказал.
	Ответить \| Правка \| Наверх \| Cообщить модератору