Главная Windows, Без рубрики, Новое Active Directory : “Активная директориЯ” – от А до Я (Рассказ 1й)
  • Active Directory : “Активная директориЯ” – от А до Я (Рассказ 1й)

    audrey4_thumb1 – Эх, Петька, Петька, – сказал Чапаев, – знавал я одного китайского коммуниста по имени Цзе Чжуан. Ему часто снился один сон – что он красная бабочка, летающая среди травы. И когда он просыпался, он часто не мог взять в толк, то ли это бабочке приснилось, что она занимается революционной работой, то ли это подпольщик видел сон, в котором он порхал среди цветов. Так вот, когда этого Цзе Чжуана арестовали в Монголии за саботаж, он на допросе так и сказал, что он на самом деле бабочка, которой все это снится. Поскольку допрашивал его сам барон Юнгерн, а он человек с большим пониманием, следующий вопрос был о том, почему эта бабочка за коммунистов. А он сказал, что она вовсе не за коммунистов. Тогда его спросили, почему в таком случае бабочка занимается подрывной деятельностью. А он ответил, что все, чем занимаются люди, настолько безобразно, что нет никакой разницы, на чьей ты стороне.
    – И что с ним случилось?
    – Ничего. Поставили его к стенке и разбудили.
    – А он?
    Чапаев пожал плечами.
    – Дальше полетел, надо полагать

    (ц) “Чапаев и Пустота”

    Рассказ 1й. Настраиваем DNS Server.

    В предыдущий раз мы остановились на такой ситуации:

    image_thumb1

    Продолжаем. Так как никаких вопросов нам не зададут, то смело доходим до финальной части – нажатия кнопки Install

    image_thumb6

    Нажимаем Install и дожидаемся финала установки. Он будет выглядеть как-то так:

    image_thumb8

    Нас немножко ругают за то, что не включен Windows Update. Ругают правильно, но всему своё время. В остальном – DNS-сервер готов к работе. Перезагрузка не понадобилась.

    Равно как и не понадобился дистрибутив. Начиная с Windows Server 2008 дистрибутив не нужен – все файлы копируются локально при установке ОС. Хотите проверить? Запустите утилиту SFC и посмотрите – ушли даже ключи /PURGECACHE и /CACHESIZE=x, где x – количество мегабайт, зарезервированных на диске для кэширования файлов с системных дистрибутивов. Раньше, чтобы освободить место от “запасных” файлов, делались два действия – очистка кэша – “sfc /PURGECACHE”, а после – установка его размера в нуль – “sfc /CACHESIZE=0”. Теперь это не нужно – всё есть локально.

    Закрываем окно и заходим в настройку DNS Server. Для начала – общая настройка сервера.

    Настройка DNS Server Properties

    Привязка к интерфейсам

    Первое, с чем должен определиться сервер – на каких интерфейсах он будет прослушивать трафик.

    image_thumb10

    Существуют два варианта – прослушивать на всех интерфейсах либо только на выбранных.

    В терминологии DNS Server интерфейсом будет называться любая точка “терминирования” трафика – т.е. адрес протокола 3го уровня, поверх которого умеет работать DNS Server. Поэтому интерфейс у нас в системе один, а с точки зрения DNS Server их два – обозначающийся IPv6 адресом и IPv4.

    Мы оставляем вариант “All IP Addresses”. Делается это из простых соображений – далее мы будем назначать частный адрес IPv6, и если мы сейчас выберем “прослушивать только на выбранных IP адресах”, то при его добавлении придётся повторно настраивать DNS-сервер – включать прослушивание на новом адресе, соответственно. Нам это не нужно.

    Я специально вывел справа окно с результатом выполнения команды ipconfig. Сделано это затем, чтобы было видно, что сервер by default прослушивает те адреса, которые на нём настроены. Кроме одного – адреса туннельного  псевдоадаптера 6to4. Хорошо видно, что адрес и интерфейс – есть, а вот в окне “где прослушиваем трафик” у DNS-сервера его нет. Почему так и откуда вообще это берется?

    Дело в том, что 6to4 – это одна из технологий, позволяющая упростить переход на IPv6 путём упрощения использования данного протокола в IPv4 сетях. Схема её работы достаточно несложная.

    Первое – во всей IPv6 адресации (все 128 бит) выделяется часть, характеризуемая префиксом 2002::/16 . Т.е. все IPv6 адреса, которые начинаются с 2002::, являются адресами гибридной схемы 6to4.

    Второе – для каждого IPv4 адреса, заданного на интерфейсе, создаётся парный ему IPv6 адрес – путём прибавления к префиксу 2002:: 32х бит от уникального IPv4 адреса хоста.

    От уникального – это от адреса классов A,B,C. IPv4 адреса класса D, используемые для многоадресных рассылок, не обязательно должны подвергаться этому преобразованию и иметь парные 6to4. Как в этом убедиться? Да легко. Запускаете командный процессор netsh и вводите interface ip show joins. Видите адреса класса D, которые есть на данном узле, и убеждаетесь, что парных им адресов 6to4 в выводе ipconfig нет.

    Кстати, скорее всего Вы увидите 2 адреса: это 224.0.0.1 (“all hosts”) и 224.0.0.252. Последний – очень интересная штука; этот адрес используется новой технологией, появившейся в NT 6.0 – LLMNR (Link-local Multicast Name Resolution). Microsoft потихоньку добивает NetBIOS, в частности в данном случае – довольно-таки известную функцию оного – разрешение имен броадкастом. Теперь это делается сразу на сетевом уровне, без надстройки в виде NetBIOS, разрешаются не только NetBIOS-имена, но и любые FQDN, а также поддерживается IPv6. Хотя, в общем-то, при живом DNS это не очень нужно. Но, по факту – фиксируйте; начиная с Vista / Server 2008 – броадкаст NetBIOS Name Service – это 137 UDP – можно не включать; поиск имён соседних узлов реализован лучше и без него.

    Третье – получив IPv6 префикс (это, в общем случае, первые 64 бита IPv6 адреса) – у нас он 2002:5ee4:246f::/64, в идентификатор хоста в качестве “нижней” половины – это младшие 32 бита – добавляется тот же IPv4 адрес.

    Результат – полный адрес 6to4 вида 2002:5ee4:246f::5ee4:246f . Вид хорошо запоминается, т.к финальная формула простая:

    IPv6 6to4 = “2002” (16 бит) + “IPv4 адрес” (32 бита) + “пусто” (48 бит нулей) + “IPv4 адрес” (32 бита)

    Не ошибетесь, в общем.

    Зачем же нужен этот адрес? Для того, чтобы передавать IPv6 трафик поверх существующих IPv4 сетей, будет использоваться простейший способ – IPv6 пакет будет вкладываться напрямую, как вложение 4го уровня, в пакет IPv4. Код протокола, используемый при этом – 41. Безусловно, все преимущества IPv6 в такой ситуации работать не будут, но для совместимости с сетевым оборудованием, работающим только с IPv4 – крайне подходящая ситуация. IPv6 пакет, сформированный одним конечным узлом, будет “завёрнут” в IPv4 и успешно дойдёт до получателя, где IPv4 пакет будет “развёрнут” и данные, содержащиеся в IPv6, будут обработаны. В силу такого подхода протокол, да и сам “виртуальный адаптер”, называются или просто “туннельными” или псевдотуннельными.

    Очень похоже на IPSec tunnel mode, где целевой IP-пакет будет вместе с заголовком попадать внутрь ESP-вложения; точно так же, как в этом случае, у IPv6 пакета, находящегося внутри, например, не будет “тикать” TTL.

    Продолжим. Следующая вкладка – настройки перенаправления запросов на уровне сервера.

    “Forwarders”

    В этой вкладке мы будем настраивать поведение сервера в случае, если запрашиваемое FQDN-имя не удаётся разрешить через: (в порядке опроса)

    • – Файл hosts / локальный кэш dns-клиента
    • – Указанные в настройках интерфейса DNS-сервера (это, как ранее предполагалось, мы сами)
    • – DNS-зоны на данном сервере
    • – Условные перенаправления запросов (conditional forwarders)

    Т.е. только в случае, если сервер никак не смог разрешить запрос локально, плюс используя условные перенаправления, он попробует спросить у “взрослых” DNS-серверов. Ну, либо запустить полный рекурсивный запрос, используя список корневых серверов (root hints).

    Выглядит это примерно так:

    image_thumb13

    Я только добавил сервер системы OpenDNS (208.67.222.222) 🙂 Он, как заметно, успешно прошёл проверку (тестовый запрос на разрешение DNS-имени).

    Внизу есть поле – время тайм-аута запроса к одиночному серверу, в секундах.

    На самом деле, под одним IP-адресом может быть несколько серверов, работающих в схеме round-robin.

    За это время сервер должен прислать хоть какой-нибудь ответ на запрос, или будет осуществлен запрос следующего сервера. Замечу, что максимальное время опроса всех серверов в списке, соответственно, и будет составлять максимальное время работы сервера. Т.е. если Вы ставите в форвардеры 3 сервера, то не удивляйтесь, что если последний работает, то ответ сервера в 5 секунд не помещается. Всё логично – 3+3=6 секунд сервер ждёт, соответственно, неработающий первый и второй forwarding-серверы.

    Логично, как понятно, будет поставить первым самый шустрый и доступный по времени наработки на отказ сервер. Обычно это сервер провайдера – он побеждает всех остальных по расстоянию от Вас by design, ну, плюс к этому у него в кэше будет множество полезной информации для быстрого разрешения имён, т.к. обслуживать он будет более 1го клиента.

    Зафиксируйте для себя – переход от forwarder к следующему forwarder будет только в случае, когда сервер за установленное время не вернул или никакого ответа, или вернул “Server Failure”. В случае, если сервер просто не нашёл запрашиваемый хост – Вам вернут ответ, что хост не найден. Предполагается, что все сервера одинаково вменяемые, и не будет ситуации “сервер X не нашёл существующий хост, а вот сервер Y поднапрягся и нашёл”. Первый не нашёл – других не спрашивают.

    Добавим, кстати, IPv6 форвардеры. Это не добавит новых возможностей по разрешению запросов; просто мы сможем запрашивать разрешение имён сразу по IPv6, используя преимущества IPv6 в части скорости и экономии трафика.

    Трафик экономится, потому что заголовок IPv6 меньше, чем у IPv4. Сам же DNS-запрос, понятное дело, будет таким же.

    Ещё раз – мы добавляем IPv6 форвардер не потому что хотим получить возможность разрешения FQDN в AAAA-записи. Разрешение в AAAA-запись будет и в случае попадания запроса к DNS-серверу по протоколу IPv4 – т.е. с точки зрения механизма разрешения – без разницы, как до сервера доберётся запрос.

    Как выбрать, какой сервер добавить? Вообще лучше спросить провайдера, через которого идёт подключение. Но вообще – можно воспользоваться сайтом www.root-servers.org и выбрать ближайший к себе. Сайт, конечно, тоскливый, но для примера пойдёт. Я вот нашёл в Москве такой сервер:

    image_thumb22

    Ну, было бы странно ожидать, чтобы московский корневой сервер F не работал по IPv6, но не суть. Проверяем с домашнего хоста – работает:

    image_thumb28

    Добавляем в настройку DNS server – не работает:

    image_thumb36

    Почему? Да потому что IPv6 адреса у нас нет глобального.

    Q: Как же так, а 6to4 адрес-то есть?!!

    A: Дело в том, что перед включением механизма “работаем по 6to4” узел проверяет – а находится ли искомый адрес тоже в 6to4 сети? (т.е. в 2002::/16). Если нет, то преобразования не происходит. Ну, говоря проще, в этой логике – 6to4 – замкнутая на себя система, и пакет пойдёт по туннелю только в том случае, если с той стороны – тоже оконечник туннеля такой же технологии. Залезть в 6to4, а вылезти из Teredo не очень получится – логики композиции IPv6 адреса вообще и адресации в частности – разные.

    Мы на интерфейс его не добавили. А динамически нам его провайдер не выдал. Вот и “неоткуда” запрос отправить. Ну, если продолжить, то мы ещё и на IPv6-интерфейсе не установили, что DNS-сервер у нас есть локальный, а полагаемся на автонастройку, которой нет.

    На IPv4 интерфейсе ОС проверяет настройки DNS и ругает, если ничего не указать, а в случае с IPv6 – нет.

    Оставим сервер в такой ситуации – первая ссылка и так будет отрабатывать в любом случае, и продолжим.

    Заметим, что после добавления серверов и нажатия кнопки ОК разблокируется настройка “использовать root hints, если нет форвардеров”. Это логично – пока форвардеров не было, root hints использовались в любом случае, а сейчас можно это отключить. Не будем так поступать и продолжим.

    Расширенные настройки – “Advanced”

    Вот уж где много интересного, так это здесь. Сюда отнесены все те настройки, которые не удостоились чести отдельной вкладки.

    image_thumb38

    Теперь по порядку.

    Версия сервера – ну, здесь всё предсказуемо. У нас Windows Server 2008 R2 RTM, поэтому она – 6.1.7600 .

    Отключение рекурсии – в случае выбора этого пункта наш сервер разучится спрашивать информацию у других DNS-серверов. Т.е. DNS пакет с запросом QUERY и флагом “хочу рекурсию” будет обрабатываться (важно! не сбрасываться, а пытаться обработаться), но лишь на поиск информации в локальных для сервера зонах. Так как мы хотим, чтобы этот сервер обрабатывал рекурсивные запросы (например, разрешал имена Интернет-узлов), то этот пункт мы не ставим.

    Включенная рекурсия опознаётся сканерами уязвимостей как misconfiguration в случае, если сервер доступен из Интернет. Причина? Возможная DoS-атака; сервер могут загрузить запросами на разрешение имён, которые ему будет трудно выполнять (в частности – трудно ему будет не их выполнять, а выделять ресурсы под отслеживание текущего статуса пачки параллельно обрабатывающихся запросов). Атака не то чтобы сильно актуальная, но всё же – если не хотите, чтобы Ваш сервер обрабатывал чьи-то произвольные запросы – отключите рекурсию.

    Когда данный механизм будет включаться? Например, когда мы будем делать доступный снаружи сервер имён, на котором будет располагаться внешняя зона DNS. В этом случае на сервере будет только само содержимое этой зоны (или нескольких подобных) и рекурсия ему не нужна – к нему будут (т.е. должны будут) приходить только запросы на разрешение имён в тех зонах, которые и так находятся на нём. Проще говоря, сервер будет отвечать только на такие запросы, которые будут касаться зон, где он может отвечать авторитетно. На прочие (итеративные про несуществующие локально зоны) он будет отвечать, что не может ответить на запрос.

    МикроFAQ про дополнительные тонкости

    Q: Почему не упоминается кэш? Ведь к локально доступным для сервера данным также относятся данные кэша.

    A: Это так, но дело в том, что предполагается, что если у сервера выключена рекурсия, то ему совсем неоткуда узнать про содержимое зон, которых на нём нет. Соответственно, и в кэше им взяться неоткуда.

     

    Q: Влияет ли содержимое файла hosts на указанную функцию?

    A: Файл hosts дружит с кэшем локального клиента DNS, а не с сервером. У сервера – свой кэш; там те записи, которые он смог успешно разрешить сам. А у узла – те, которые ему удалось запросить у сервера, притом с любым результатом – DNS-клиент также умеет кэшировать негативные ответы.

     

    Q: Обозначает ли отключение рекурсии то, что наш сервер вообще не будет общаться с другими?

    A: Только с другими DNS-серверами. ;). Дело в том, что один способ общения с другими серверами останется – это случай, когда внутри какой-либо зоны есть запись про WINS Lookup – т.е. для данной конкретной зоны действует логика “не нашёл запись в своём списке – поищи у сервера WINS по IPv4 адресу такому-то”.

     

    Q: Мы когда-нибудь доберемся до Active Directory?

    A: Да.

    BIND secondaries – включение данного пункта говорит о том, что в качестве secondary-серверов могут выступать сервера с BIND. На что повлияет наличие этих серверов в инфраструктуре?

    Во-первых – если в Ваших зонах DNS есть настройка WINS Lookup (или в обратных зонах – WINS-R), надо поставить у неё отметку – Do not replicate this record. Почему? Потому что при виде записи WINS/WINS-R в тексте файла DNS-зоны сервер BIND может заболеть, а если совсем слабый, то и погибнуть.

    Во-вторых – при передаче зоны будет использоваться полная передача (AXFR), а не частичная/инкрементальная – IXFR.

    Это повлияет только на передачу зон DNS стандартным способом. В случае, когда используются зоны DNS, хранящиеся в Active Directory, реплицироваться они будут так же, как и другие LDAP-данные – по мультимастерной схеме и поверх защищённого канала. Никаких текстовых файликов поверх TCP 53 .

    Соответственно, устанавливая этот пункт, Вы снижаете КПД zone transfer и делаете необходимой дополнительную настройку сервера и зон. Поэтому просто так его устанавливать не надо.

    Ну, в общем, говоря объективно, Microsoft в этой настройке лукавит – серверами BIND тут считаются сервера версий 4.x , а сейчас уже давно 9.x . Да и всё вышеописанное в части записей уже в формате BIND 8 было поправлено. Но в случае наличия в организации некрофилов вида “у нас DNS-сервер годами электричество зря потребляет и уязвимостями в Интернет светит нормально работает и ничего хорошего при таком подходе в принципе не будет” – вполне возможен сюрприз в виде BIND 4.9.4 , например.

    Fail on load if bad zone data – Пункт определяет поведение сервера в случае, если в любом файле зоны попались неизвестные серверу данные. Логика простая – либо проигнорировать данные и продолжить загрузку, либо остановить сервер. Ну, мол, если попались неверные данные в DNS-зоне, то ситуация критическая и нужно внимание администратора, притом срочно. Что тут поставить – зависит от Вашего личного предпочтения, на работу сервера это не влияет, разве что на запуск.

    Кстати, к источникам “bad zone data” тут относятся не только файлы с данными DNS-зон, но и файл с root hints – который находится по адресу %SYSTEMROOT%\System32\dns\CACHE.DNS

    Понятно, что в случае с загрузкой данных из Active Directory этот пункт не имеет смысла.

    Enable round robin & Enable netmask ordering – будет ли сервер поддерживать механизм ротации записей внутри ответа (RR). Если эта настройка включена, то будет следующий эффект. Допустим, имеется несколько одноименных записей (например, у сервера 3 интерфейса и на каждом из них по 1 IPv4 адресу). Как-то так:

    trollserver   IN   A   192.168.1.15

    trollserver   IN   A   192.168.2.15

    trollserver   IN   A   192.168.3.15

    Вот если RR включен, то первому спрашивающему вернется что-то такое:

    trollserver   IN   A   192.168.1.15

    trollserver   IN   A   192.168.2.15

    trollserver   IN   A   192.168.3.15

    А второму – что-то такое:

    trollserver   IN   A   192.168.2.15

    trollserver   IN   A   192.168.3.15

    trollserver   IN   A   192.168.1.15

    И так далее. Это позволит на уровне DNS-ответов начать балансировку нагрузки.

    В ряде случаев это не нужно. Или нужно частично. В случае, если не нужно – отключайте, и клиенту всегда будет возвращаться перечень в том виде, в котором он есть изначально. Если хотите, чтобы механизм работал, но ограничено – например, хотите отключить RR только для определенного типа записей – есть секретный ключик реестра по адресу:

    HKLM\System\CurrentControlSet\Services\DNS\Parameters\DoNotRoundRobinTypes

    Тип имеет REG_SZ, синтаксис прост – указанные в этой строке типы (A, AAAA, MX) не будут подпадать под RR. Указывать типы записей надо через пробел. Если этого ключа нет (обычно его нет), то его нужно создать. Не забудьте только после изменения его (ключа) настроек перезапустить службу DNS Server.

    Если в ответе есть записи, IPv4-адреса которых подпадают под классовую сеть со стороны клиента, то они будут выставлены выше всех. Это называется local subnet ordering и практически непобедимо. Хотя в ряде ситуаций – не совсем полезно.

    Т.е. смотрите – допустим, ЕОТ есть один сервер – с тремя интерфейсами и адресами 192.168.15.1, 10.1.0.1 и 10.2.0.1. Нормальная ситуация вполне – взяли 10.0.0.0/8 и порезали на подсети. Теперь – есть клиент с адресом 10.1.0.162. Этот клиент посылает запрос серверу. Сервер смотрит на Source IPv4 у пакета и, (внимание!) исходя из того, что сеть 10.0.0.0/8 (он же НЕ может узнать, какая маска используется на интерфейсе у клиента) – понимает, что адреса 10.1.0.1 и 10.2.0.1 клиенту “ближе”. И ставит их первыми в ответ. Вот эта операция – перемещение “локальных с точки зрения классического деления IPv4 адресов на сети” адресов в начало ответа – и есть local subnet ordering. Она проводится до RR.

    Q: Можно ли выдать приоритет одному из адресов в ответе сервера – вот, мол, этот пусть будет первым всегда?

    A: В общем случае – нет. В случае SRV-записей – есть ряд механизмов, частично решающих эту задачу.

     

    Кстати, в Windows Server 2003 все адреса считаются как Class C – т.е. с маской /24

    А в Windows 2000 Server эти функции вообще одновременно не работали. Или список статический, но впереди “ближние” ответы, или RR, но без приоритета локальной сети.

    Эта опция управляема, но тоже хитро – через утилиту dnscmd. В графическом интерфейсе рулей от таких тонкостей в DNS Server нет, но это не значит, что этого функционала нет в природе. Вы можете задать, какой будет считаться маска подсети, используемой узлом, при помощи команды вида:

    dnscmd /Config /LocalNetPriorityNetMask 0x0000FFFF

    , где 0x0000FFFF – wildcard mask (т.е. “инвертированная маска”) у IPv4 адресов со стороны клиента. Т.е. если сделать так, то сервер будет отбирать из перечня IPv4 адресов как “локальные” те, кто будет в одной /16 сети с клиентом.

    Если после экспериментов всё погибло – можно сбросить настройки этой же командой, подав как параметр маску 0xFFFFFFFF

    Secure cache against pollution – смешная настройка, сам не пойму – почему так. Что же она делает? Если она включена, то сервер защищается от попадания в свой кэш ложных или вражеских данных. В частности, обрабатывается такая ситуация:

    1. Сервер спрашивает у другого сервера – “скажи мне, что ты знаешь про узел www.itband.ru” ?
    2. Ему отвечают – “я знаю, что”:
      1. .ru – это запись с такими-то IP-адресами
      2. itband.ru – это запись с такими-то IP-адресами
      3. www.itband.ru – это запись с такими-то IP-адресами
      4. www.microsoft.com – это запись с IP-адресом 127.0.0.1

    В данной ситуации часть ответа – которая под пунктом 4 – это как раз cache pollution. В случае включения механизма она будет проигнорирована. Критерий прост – про неё ничего не было в стартовом запросе. Целесообразно всегда держать её включенной – наврят ли Вы попадёте на добрый сервер, который зачем-то будет добавлять то, что Вы не запрашивали, и при этом – оно будет полезным.

    Name checking

    В данной настройке будет указываться, как сервер будет анализировать само тело запросов – т.е. FQDN. Возможны следующие варианты:

    Strict RFC (ANSI) – в запросе допускаются только символы, явно указанные в RFC 1035.

    Non RFC (ANSI) – в запросе допускаются любые ASCII-символы (конечно, кроме служебных последовательностей – т.е., например, при подаче явно неверного запроса – типа www.,.itband.,.ru сервер откажется его обрабатывать, хотя все символы – ASCII)

    Multibyte (UTF8) – запрос может быть в формате UTF8. Заметьте – не в любом, который подпадает под название “Unicode”, а в UTF8.

    All names – запросы не фильтруются вообще и доходят до сервера в авторском варианте.

    Оставим Strict RFC.

    Load zone data on startup

    Эта настройка покажет, откуда, и в каком порядке DNS Server будет загружать данные зон. Какие будут возможны варианты?

    From Active Directory and registry – самый лучший и определенно подходящий нам вариант. Он говорит о том, что DNS Server будет действовать так:

    1. Проверит Active Directory на предмет наличия зон и загрузит их оттуда (понятно, что такое случится только в случае, если DNS Server физически совмещен с контроллером домена).
    2. Зайдёт в ключик реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\ и, заходя в каждый подключ (который будет содержать описАние одной зоны) прочитает из него параметр типа REG_SZ с названием DatabaseFile, после чего прочитает указанный файл из локации %SYSTEMROOT%\system32\dns\
    3. Пункт 2 будет повторяться, пока или не кончатся зоны, или, при параметре Fail on load if bad zone data, в случае, если при загрузке очередного файла не будет обнаружена ошибка.

    From registry – аналогично предыдущему, но без обращения к Active Directory. Скажем так – нормальный выбор для standalone DNS-сервера (например, стоящего в DMZ и держащего внешние DNS-зоны).

    From file – специальный “миграционный” вариант. Нужен в случае, когда Вы мигрируете с сервера, хранящего данные в формате BIND 8, на Microsoft DNS. В этом случае Вы поступаете так:

    1. Устанавливаете Microsoft DNS Server
    2. Ставите ему эту настройку
    3. Останавливаете сервис DNS Server
    4. Разово копируете все файлы от BIND в каталог %SYSTEMROOT%\system32\dns
    5. Включаете сервис DNS Server

    Идея в том, что прочитав файлы зон и конфигурационный файл от BIND, сервер создаст в реестре записи, соответствующие фактически существующим зонам. Т.е. операция эта – разовая, и настройка эта нужна только в данной ситуации. Штатно она не нужна совсем.

    Enable automatic scavenging of stale records

    Эту настройку рассмотрим в контексте конкретных зон DNS – это и ощутимо нагляднее, да и её глобальное конфигурирование, мягко говоря, не совсем удачное решение.

    Корневые сервера – “Root Hints”

    В нашем случае вкладка выглядит как-то так:

    image_thumb40

    Серверов, как видим, очень много. Они берутся из файла cache.dns, идущего в дистрибутиве Windows Server. В принципе, мы можем поудалять лишние, основываясь на географическом принципе (оставить один, который ближе), но это, по сути, нам не очень нужно. Дело в том, что использоваться root hints будут в самом крайнем случае – когда отвалится всё, что только можно, а у нас DNS Server, в общем-то, под Active Directory, а не под задачу обеспечения работы провайдера в условиях ядерного конфликта мировых держав. Поэтому можно как оставить один root hint – тот самый F (я из Москвы сужу, от меня он ближе), либо оставить так, как есть – честно, оптимизировать скорость работы аварийных сервисов, конечно, можно, но просто подумайте – насколько часто они понадобятся (в процентах от суммарного рабочего времени)?

    Журналирование – “Event Logging”

    Данная вкладка, по сравнению с предыдущими, достаточно скудна по части настроек.

    image_thumb43

    Честно говоря, всё, что мы здесь сделаем – это выставим переключатель в положение Errors and warnings. Причина? На данный момент нет смысла в попадании в журнал сообщений категории Information – мы просто не будем рассматривать ситуации, когда будет проводиться тщательный анализ этих сообщений. Равно как не будем акцентироваться на отладке и мониторинге – сейчас мы готовимся к подъёму сервиса Active Directory, а не изучаем подробно функционал службы DNS Server.

    Проверка подписи DNSSEC – Trust Anchors

    Trust Anchors – нововведение в Microsoft Windows Server 2008 R2. Что это за технология и зачем она нужна? Ситуация достаточно проста. Существует класс технологий DNSSEC, который используется для:

    В случае отношений “сервер-сервер” –

    1. Дополнительной гарантии того, что содержимое DNS-зоны не модифицируется в процессе передачи.
    2. Также, что зона создана на доверенном узле.

    А в случае отношений “сервер-клиент” –

    1. Что ответ сервера пришёл со стороны доверенного узла.

    Всё это обеспечивается путём добавления новых типов записей (DNSKEY, RRSIG, NSEC, DS) и других моментов, опИсанных в RFC с номерами от 4033 по 4035.

    Почему этого не сделали раньше? Ну, во-первых, у Microsoft уже 10 лет как информация о зонах DNS передаётся в трафике репликации Active Directory, что гарантирует уровень безопасности даже более высокий, нежели DNSSEC. Во-вторых, если уж так хочется общаться поверх Интернета используя AXFR/IXFR поверх TCP53, то можно воспользоваться протоколом IPSec, который замечательно решит задачу защиты информации от изменения/подделки/прочтения. А в третьих – и это главное – поддержка DNSSEC стала одним из обязательных пунктов в новом федеральном стандарте США – рекомендации NIST под кодом SP 800-53.

    Кстати, DNSSEC в данной реализации не совместим с вариантом 2 – защитой DNS-трафика через IPSec.

    Кстати-2, в случае рабочего DNSSEC проблемы вида cache poisoning не возникают.

    В случае с сервером это настраивается как раз в текущей вкладке, а в случае с клиентом – через Name Resolution Policy Table (NRPT), которую можно настроить через group policy.

    Серверная часть настроек выглядит как-то так:

    image_thumb45

    Т.е. мы сможем указать имя/алгоритм хэширования/открытый ключ, чтобы в случае получения zone transfer с использованием DNSSEC иметь возможность проверить, действительно ли зона создана тем узлом, который это декларирует.

    В нашем случае пока что зоны принимать неоткуда, поэтому мы ничего не добавляем в настройки.

    Что ж, сервер готов, теперь будем добавлять зоны DNS. Но про это – отдельный рассказ.

    Ruslan V. Karmanov  11

Комментарии

  1. интересное повествование поскольку я сам всегда ленился узнать что такое Secure cache against pollution,про ipv6 ничего не понял -прочитал дважды и вроде я не самый тупой,если выяснится что кто-то еще не понял думаю будет лучше эту часть материала переработать поскольку отступления сбивают. Но это только в том случае если я неединственный кто её не понял.

  2. Уважаемый Руслан, прошу Вас, продолжайте так неспешно и дальше-не видел ни одной книги, где так подробно и по делу все было бы расписано.
    Что так все (cisco,ms,etc)взялись за ipv6. Наш домовой провайдер(от ЦТ) всем юзерам вон белые адреса выдает-и в ус не дует:)

  3. ROFL.
    Мне это больше всего понравилось:
    Users/Ruru/AppData/Local/Temp/WindowsLiveWriter1286139640/supfiles131C9BA6/image12.png
    Беспалева так.

  4. Теперь по статье:
    Я не понял фразу “Залезть в 6to4, а вылезти из Teredo не очень получится – логики композиции IPv6 адреса вообще и адресации в частности – разные.”
    Причём совсем не понял. Какая связь 6to4 и Teredo? Ну кроме того что оба IPv6 тунеллинг 🙂 И что значит “залезть” и “вылезти”?
    Проясните пожалуйста.

    Статья вроде получше чем предыдущая. Хотя хочется конечно продолжения другого цикла 🙂

  5. > Users/Ruru/AppData/Local/Temp/WindowsLiveWriter1286139640/supfiles131C9BA6/image12.png

    Это был научный эксперимент по изготовлению статьи с модными картинками, которые при нажатии “всплывают” до максимального размера. Поэтому он частично получился.

    > Я не понял фразу «Залезть в 6to4, а вылезти из Teredo не
    > очень получится – логики композиции IPv6 адреса вообще и
    > адресации в частности – разные.»

    Да то, что имея автосгенеренный адрес 6to4, мы не сможем использовать его для полноценного обмена трафиком с другими IPv6 узлами. Только с такими же, у кого 6to4 адреса есть. Цель – начать показывать, что в IPv6 – несколько параллельно существующих групп адресов, между которыми трафик не ходит, хотя все они – IPv6. Люди ж спрашивают – “а вон у меня адрес же ipv6 есть, т.е. она сама уже настроилась и всё должно работать?”. Им говоришь – нет, там не все адреса одинаково полезные. Как-то так.

  6. > Да то, что имея автосгенеренный адрес 6to4, мы не сможем использовать его для полноценного обмена трафиком с другими IPv6 узлами.

    Те же самые частные адреса получаются что и в ipv4. Естественно с ними мы в глобальную сеть выйти не сможем.

  7. > Те же самые частные адреса получаются что и в ipv4.
    > Естественно с ними мы в глобальную сеть выйти не сможем.

    Нет, Андрей. Притом совсем. Дело в том, что частные адреса IPv6 – это префикс fc00/fd00 . Совсем другой и формат адреса, и схема генерации, и логика работы. Именно как замена IPv4 private address. Тут – 6to4, это другое – самый простой способ туннелировать IPv6 трафик поверх IPv4 сети.

  8. Ну согласен. Просто я имел в виду, что автосгнерированные 6to4 адреса могут работать только с такимиже адресами в глобальной сети, но никак не с обычнми. Так?

  9. Да. В общем-то, Maximillian примерно про это же и спрашивал чуть выше. 🙂

  10. спасибо за труд. все доступно, все понятно. про ipv6, что бы уловить моменты, читал дополнительно. новый сервер и я с нетерпением ждем продолжения 🙂

  11. Руслан! Опять те же грабли с ДНС. Вы в этой статье советуете оставить прослушивание на всех интерфейсах. Во-первых, это противоречит вашим утверждениям с первой статье об однозначности интерпретации настроек для системы – т.е. тут мы всё оставляем на усмотрение ОС. (Причём просто из-за лени. А может еще вы считаете ДНС не стль важным компонентом?)
    Второе, из-за этого параметра (прослушивать на всех интерфейсах) – Best Pract. будет советовать первым в списке ДНС серверов в настройках интерфейсов указать 127.0.0.1 – который, ксттаи не виден командой ipconfig 🙂

  12. mikas,

    Я буду противоречить себе в каждой статье. И исходить из своей лени, а также вредности и подчеркнуто неполно предоставлять информацию. Этим я буду выгодно отличаться от тех, которые делают ещё хуже, а пишут – наоборот.

    DNS не только я считаю не столь нужным компонентом, а (тссс! не поверите) – все, кроме IT-шников. Идите, объясните гендиректору не-IT фирмы, что ему нужен DNS. Получилось? Вот как-то так, да… 😉

    “Вхождение в учение подразумевает собой ложь. Ученик должен быть обманут.” (ц) Чжуан Цзы

  13. Ок. Я буду по возможности Вас поправлять.
    Наконец я прочёл статью!
    И у меня есть замечание про “Secure cache against pollution”. Насколько мне известно, у Вас не совсем полный ответ. Точнее вашего варианта я никогда не встречал. Мне попадалась версия, что эта галка заставляет проверять то, что попадает в кеш, через корневые серверы. И даже есть рекомендация не ставить эту галку, чтобы не иметь замедления работы ДНС сервера. Это не утвержение.. скорее версия.
    Жду продолжения, становится интересно…

  14. А я поправлять человека, заведовавшего в специалисте направлениями ms-cisco,
    поправлять не буду:)Просто-требую(нет, прошу, конечно) продолжения банкета.
    Подобный сериал может заглохнуть ввиду нехватки рабочего времени автора

  15. Статья отличная! Толково и по делу. Но как вегда есть ложка дегтя, это комментарии, причем разделяют логическую сущность.

    Например, мы выращиваем помидоры, они красные (но не все красно есть помидоры) и сочные.

  16. Руслан, не намекнете, когда ждать “продолжение банкета”

  17. Руслан, планируется ли дальнейшее написание статей “Active Directory : “Активная директориЯ” – от А до Я”?

  18. А вот такой вопрос есть AD, Один контроллер домена с ролью DNS. Есть Отдельный dns, на нем создана основная зона этого домена, как из dc среплицировать зону в основнуб зону на стендэлон dns?