> Не ради оффтопа - просто интересно решение проблемы и сама проблема )Да не проблема )
> Вот до этого момента в вашем пояснении
>> Поэтому я хочу сделать отдельный сервер DNS, который бы форвардил все запросы на DNS
>> провайдера, за исключением случая, когда запрос идёт про зону my.domainname.net.
>> Подскажите, пожалуйста, как это сделать.
>>
>> P.S. Создать зону и скопировать туда все записи из ActiveDirectory не подходит.
> было в принципе ясно, что вы резолвинг на клиенте неправильно настраиваете.
Да я нормально настраивал исходя из того, что было, далее поясню.
> Однако процитированное говорит о другом: вы не понимаете роли DNS AD в
> процессе взаимодействия клиента и сервера, поэтому очевидно решили просто дополнительно
> использовать bind для редиректа запросов клиентов нужному серверу имен (о расположении
> зон AD на этом bind-е очевидно никакой речи не идет) и
> своего рода решения проблемы с возможным перекрытием имен субдоменов производных от
> вашего (поскольку основной сервер AD их не резолвил).
Да, именно: "решили просто дополнительно использовать bind для редиректа запросов клиентов нужному серверу имен (о расположении зон AD на этом bind-е очевидно никакой речи не идет)" Ситуацию объясню далее.
> Кстати, поясните если не сложно: какую ("криво" спроектированную) структуру доменных имен
> вы имеете на текущий момент и какой вариант вы хотели бы
> использовать (если уже упомянули какие-то рекомендации) ?
> Выше вам посоветовали весьма разумное решение:
>>так и в бинде создать слейв зону для АД
> Имхо, не стоит опускаться до пионерства типа:
>> Человек, который развертывал домен, да, рекомендаций не читал.
> если в теме не приводить конкретику касательно того, что именно и кто
> именно не читал.
Ну а что Вы хотите, имя этого человека? Зачем?
Если имеется в виду документация по структуре AD
> и именовании внутренних/внешних зон, то надо в этом плане быть объективным:
> рекомендации микрософт касаются исключительно архитектуры, основанной на использовании
> только ее продуктов с учетом их специфики (выбор имени домена, проектирование
> структуры DNS с учетом наследования, невозможность расщепления зон на внешнюю и
> внутреннюю, роль DNS в клиент-серверном взаимодействии и т.д.). Включение в рассмотрение
> bind-а (как держателя зон AD со всеми возможными/невозможными последствиями для безопасности
> и функционирования на виндовом/невиндовом сервере) или других продуктов и возможных конфигураций
> не так прозрачно и логично, учитывая возможные нюансы взаимодействия и политику
> M$ в отношении OpenSource. Поэтому, имхо, было бы логично приводить конкретные
> примеры с учетом нагрузок и нюансов конфигурации, позволяющих избежать возможных проблем.
Итак, что было: в своё время (до меня) был развернут домен АД с именем <organistaion>.local.net. Человек, который это делал, по складу ума практик. На то время предполагалось организовать выход в интернет через прокси. Прямого доступа в интернет (типа NAT) не было и не предполагалось. В этом случае нет необходимости в разрешении имён интернет-хостов на клиентах, это делает прокси-сервер.
Что появилось: появился ещё один интернет-канал, я развернул прокси на нём, написал скрипт для переключения каналов, и у пользователей появился более стабильный интернет. Однако, поскольку этот канал имеет безлимитный трафик, я дополнительно организовал SNAT для прямого доступа отдельным гражданам (всякие интернет-игрушки). Вот тут и появилась проблема с неправильно названным доменом.
> И да, поясните таки магию решения:
>> Проблема решилась через зону "forward". Спасибо.
> Настроили на bind-е форвардинг на DNS AD и оставили на клиентах его
> вторым DNS-ом ?
Решение такое: на интернет шлюзе используется bind, который перенаправляет все запросы на ДНС провайдера + прописана форвард-зона, в ней запросы перенаправляются на ДНС АД:
options {
forwarders { x.x.x.x; 192.168.50.14; };
listen-on port 53 { 127.0.0.1; 192.168.48.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// recursion yes;
// dnssec-enable yes;
// dnssec-validation yes;
// dnssec-lookaside auto;
/* Path to ISC DLV key */
// bindkeys-file "/etc/named.iscdlv.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "organization.local.net" {
type forward;
forwarders { 192.168.50.14; };
};
У клиентов, которые пользуются прямым инетом прописывается данный сервер в качестве ДНС (единственный, в принципе).
> p.s. с архитектором my.domainname.net и Dmirtiy, если что, не знаком, и тем
> более не являюсь первым... )
> p.s. обсуждение вашей проблемы подняло в памяти одного престарелого шизофреника а-ля "не
> учите седые муди". если читает - пусть дернет себя за что-нибудь
> покрепче...))