В одном из крупных гос. учреждений пришлось столкнуться с полным безобразием и грязью происходящей на кучи различных и разношерстных DNS. Всего около 10 DNS-серверов с кучей подответственных зон, поднятых под разными операционками начиная от запущенной FreeBSD 2004 года, заканчивая Win-server-ами, разбросанные по всей сложной сетевой инфраструктуре. Все очень грязно: каждый DNS может являться как мастером каких то зон, так и слейвом для других, а так же получилось что это пол беды - сервера работают без view-шек, то ли из-за не знания подобных вещей старыми админами, то ли из-за не желания, в общем даже за одну и ту же зону отвечают разные сервера один вроде как internal, другой external, зоны перехлестываются. Короче полная путаница.
Предложил я все это дело привести в порядок.
Для большей безопасности работы решил использовать схему STELS DNS.
Кто не совсем понял о чем я - это «невидимый» режим работы: информацию о master-сервере невозможно получить используя прямые запросы. Для этого требуется расположить Master (primary) DNS сервер в защищенной среде, тем самым оградить подъответственные зоны от атак, а так же обеспечить дополнительную защиту самого ПО сервера от взлома. Запросы клиентов на преобразование адресов происходит на Slave серверах, ведомых Master сервером. Прямой доступ к Master-DNS имеют только Slave-сервера, по установленному порту, контролируемые как политикой безопасности самой системы, так и внешним сетевым оборудованием.
Slave-сервера располагаются в менее защищенной зоне, доступной извне.
Что я и сделал. Поднял Master DNS на базе Debian 7 + BIND9 в chroot-e, перетащил все зоны этих серверов на него, устранил конфликты, разграничил view-шки по правилам для подсетей, что бы slave-сервера могли получать все зоны вьюшек воспользовался методом фильтрации по ключу (это для тех кто не знает что просто так с view-шками слейвы нормально получать ничего не будут).
Все бы ничего, но пока не назначен день X по запуску всего этого дела хотелось бы проверить функционирование этой связки. Проблема в том что slave сервера не получают зоны, ругаясь на то что master dns не авторитетный для этих зон.
Лог:
13-Aug-2013 00:52:36.169 general: zone ***.******.ru/IN/ext: refresh: non-authoritative answer from master 10.14.0.9#53 (source 0.0.0.0#0)
Авторитетным он станет тогда, когда отключатся старые сервера, а в настройках NS зон будет выставлен примари-сервером сам Master, я так понимаю.
Может у кого есть мысли по этому поводу, как проверить трансфер зон на слейвы, до внедрения на живую в продакшен.
