Главная Windows, Без рубрики Миграция базовой инфраструктуры Microsoft. Часть 1.
  • Миграция базовой инфраструктуры Microsoft. Часть 1.

    Введение.

    Тема миграции базовой инфраструктуры Microsoft не нова. Но полной и самодостаточной информации о проведении этого процесса очень мало, если не сказать, что такой информации вообще нет. На просторах сети Интернет можно найти очень много статей, описывающих процесс миграции, но все эти статьи являются какими-то «огрызками» и полной картины не раскрывают. Если говорить о миграции на новые платформы, то здесь информации еще меньше.

    Мне хотелось бы раскрыть эту тему в большем объеме, рассказать об особенностях миграции в реальных инфраструктурах. Будет учитываться специфика работы различных информационных систем, как такие системы необходимо мигрировать, в какой последовательности.

    Одной статьи для рассмотрения материала не хватит (или это будет очень большая статья), поэтому будет несколько статей. Конечный объем материала пока не известен. Писать буду по мере возможностей, постараюсь не затягивать с этим процессом.

    Что будем считать базовой инфраструктурой, и что в нее будет входить?

    • Служба каталогов Active Directory. По праву AD можно назвать ключевым компонентом в базовой инфраструктуре;
    • DNS;
    • DHCP;
    • WINS;
    • Файловые серверы;
    • Принт-серверы;
    • Терминальные серверы и фермы терминальных серверов;
    • DFS и ее элементы;

    Сейчас все больше и больше организаций используют Exchange-сервер в качестве средства объединенных коммуникаций. Exchange напрямую зависит от Active Directory, и миграция службы каталогов безусловно повлияет на работу Exchange-пользователей. Документация по миграции Active Directory есть, но в этой документации не описывается процесс миграции AD совместно с Exchange. В свою очередь, в других документах описывается миграция Exchange, но она не рассматривается совместно с миграцией Active Directory. Примерно туже самую картину я наблюдал на проектах, в которых участвовало несколько архитекторов – один по AD, второй по Exchange. Зачастую их действия не были согласованы – миграция двух систем проходила несколько изолировано, особенности совместной миграции не учитывались. Получалось, что одна система (архитектор) мешала другой (другому).

    Есть определенные особенности миграции серверов Microsoft SQL Server. Включим в миграцию и их.

    Что будем считать миграцией? Миграцией будем считать перенос ресурсов из одного или нескольких лесов в целевой лес. Такая модель чаще всего встречается на практике.

    Сам процесс миграции это только полдела (скорее всего даже меньше). Миграция процесс сложный, долгий, включает в себя множество задач, распределенных во времени, выполнение которых позволит добиться какого-то результата, достичь поставленных целей. Я фактически назвал определение понятия проект. Для выполнения проекта требуется определенный подход. Методологий по управлению проектами много, тема большая, в этой статье рассматриваться не будет. Хорошие рекомендации по управлению проектами даны в методологии MSF (Microsoft Solution Framework). Некоторые считают, что эта модель подходит только для разработчиков и к инфраструктурным проектам не относится. На самом деле это не так. Материал методологии хорошо подходит и к инфраструктурным проектам, необходимо только немного поабстрагировать. В этой методологии не будет описано «как и что делать», в ней не будет жестких правил ведения проектов, но в ней даются ценные советы, которые вам помогут выполнить любой проект, не только ITшный.

    Также в проектировании помогут стандарты, например, ГОСТы.
    Из них вам также необходимо выбрать определенные рекомендации, которые вам помогут выполнить проект успешно. Найти ГОСТы для автоматизированных систем можно здесь – http://www.rugost.com/index.php?option=com_content&task=category&sectionid=6&id=22&Itemid=53

    Например, я для себя выработал некую методику, являющуюся гибридом ГОСТов и методологии MSF. Применяю ее на практике.

    Некоторые рекомендации по ведению проектов, а точнее по управлению проектной группой, можно подчерпнуть из книги Страуструпа «Язык программирования С++», второе и третье издание. В этой книге есть отдельная глава, посвященная проектированию.

    Контролировать ход проекта вам поможет Microsoft Project. Есть хорошая книга Гультяева А.К. по управлению проектами в Microsoft Project. Советую прочесть.

    Исходные данные.

    Какие у нас есть исходные данные?

    У нас есть исходная инфраструктура, состоящая из одного леса и нескольких доменов.

    Имя корневого домена – source.com/SOURCE. Дочерний домен – child1.source.com/CHILD1. Версии контроллеров доменов в source.com – Windows Server 2003 с SP2, в child1 – Windows 2000 Server с SP4. В доменах работают несколько пользователей. Рабочие станции – 2000, XP, Vista, Windows 7. Есть серверы Windows 2000 Server, Windows Server 2003/2008R1/2008R2.

    В каждом домене установлен Exchange-сервер версии 2003 с SP2. Если на Exchange-сервере не установлен SP2, то необходимо это сделать до миграции почтовых ящиков пользователей. Exchange 2010 поддерживает миграцию почтовых ящиков только с версий Exchange Server 2003 SP2 и Exchange Server 2007 SP2.

    Есть определенные требования к версиям контроллеров доменов при миграции почты на Exchange Server 2010 (или на Exchange 2007). Об этих особенностях немного позже.

    Мы уже спроектировали целевую инфраструктуру и даже ее внедрили. В качестве целевой инфраструктуры будет выступать домен target.com/TARGET. Версия контроллеров доменов Windows Server 2008 R2.

    На отдельном сервере установлен Exchange Server 2010. На этом сервере установлены все роли, а точнее роли Hub, CAS и Mailbox. За обработку внешней почты сейчас отвечает один из серверов в исходном домене. После миграции эту роль на себя возьмет еще один сервер в новой инфраструктуре – Exchange Server 2010 с ролью Edge Transport.

    У нас также будут разные типы серверов в исходном домене. Нам их тоже придется мигрировать в новую инфраструктуру. О миграции серверов немного позже.

    Интеграция.

    Миграция является процессом достаточно долгим и сам процесс подразумевает долгосрочное сосуществование двух систем – старой и новой.

    Поэтому нам необходимо интегрировать нашу текущую инфраструктуру с целевой.

    Разрешение имен.

    С чего начать интеграцию? Лучше всего с настройки разрешения имен между инфраструктурами. Нам необходимо, чтобы смигрированные ресурсы могли разрешать имена несмигрированных ресурсов, и наоборот. Наиболее популярные механизмы разрешения имен в Windows-сетях – это DNS и NETBIOS.

    Будем считать, что DNS-серверы развернуты на контроллерах доменов. Обслуживают эти DNS-серверы зоны для своего раздела и зону _msdcs.корневой_домен_леса. Зоны интегрированы в Active Directory.

    Как правило, хватает настройки разрешения только DNS-имен между инфраструктурами.

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

    Рассмотрим первый способ – пересылки:

    В общем-то, ничто нам не мешает использовать этот механизм. Сначала мы настраиваем в исходном домене пересылку для целевого домена. Для пересылки мы указываем ближайшие DNS-серверы целевого домена. Что означает ближайшие? Как правило, в многодоменной среде, для региональной площадки выделяется отдельный домен (в нашем случае это child1.source.com). Сейчас конечно от такой модели стараются отходить и переходить к однодоменной модели. Но не считайте однодоменную модель каким-либо правилом. Иногда она может вам не подойти. Все зависит от требований. При миграции в новый домен, компьютеры будут регистрировать A-записи на локальных контроллерах домена, то есть на контроллерах домена той же физической площадки, что и в исходном лесу (при условии, что мы правильно настроили конфигурацию сетевой карты клиентов DNS; об этом чуть позже). Поэтому было бы правильным настроить  пересылку именно на эти локальные контроллеры доменов.

    В целевом домене мы проделываем тоже самое – настраиваем пересылку для исходного домена между ближайшими DNS-серверами.

    Если исходные DNS-серверы – Windows 2000, необходимо использовать вторичные зоны или продумать способ разрешения имен совместно с глобальными пересылками на DNS-серверы целевого домена.

    Начиная с  Windows Server 2008, появилась возможность реплицировать записи пересылок между DNS-серверами. Можно воспользоваться этим механизмом, чтобы не делать одну и туже работу несколько раз.

    Второй механизм – использование вторичных зон:

    Здесь мы разрешаем пересылку зоны между серверами исходного и целевого доменов. Создаем вторичные зоны: на исходных DNS-серверах вторичные зоны для целевого домена, на целевых для исходного домена. В качестве master-сервера используем ближайший DNS-сервер. Настраиваем оповещение при изменениях. Число изменений до оповещения – 1.

    Третий способ – использование зон-заглушек:

    Этот функционал появился в Windows Server 2003. С помощью зон-заглушек мы можем получать информацию об авторитетных DNS-серверах – NS- и A-записи серверов, обслуживающих указанную зону. Причем, эта информация  будет еще и динамически обновляться.

    В общем-то, способ отличный, но для нашего примера подходит лишь частично. DNS-серверы из домена child1 получат NS/A-записи для всех DNS-серверов домена target.com (случаи с DisallowNSAutoCreation не будем рассматривать). Для разрешения имен, они также будут обращаться к одному из этих NS-серверов. Когда мы смигрируем компьютер в новый домен, он зарегистрируется на «новом», ближайшем DNS-сервере. Еще несмигрированные компьютеры будут обращаться к старым DNS-серверам, а те в свою очередь на какой-то DNS-сервер из нового домена. На какой? Успеет ли новая A-запись для смигрированного компьютера реплицироваться на этот какой-то DNS-сервер? Ответить на этот вопрос трудно. Поэтому зоны-заглушки из старого домена в новый, для нашей конфигурации, не подойдут. А вот в противоположную сторону мы их можем использовать.

    Начиная с Windows Server 2008 R1, у нас есть возможность реплицировать зоны этого типа между DNS-серверами. Стоит воспользоваться этой возможность, тем более целевой лес у нас Windows Server 2008 R2.

    Хотелось бы отметить несколько плюсов и минусов этих трех способов.

    Способ с пересылками достаточно прост в конфигурации, при этом трафик передачи зоны равен нулю. Но трафик запросов больше, чем у вторичных зон. Есть некоторые ограничения при миграции с Windows Server 2000: нет поддержки условных пересылок. Также есть проблемы с актуальностью данных. Например, если какая-то запись изменится, скажем, поменялся IP-адрес компьютера, то изменения будут отражены на пересылающей стороне только после истечения срока кэширования записи и при повторном запросе. Это касается и способа с зонами-заглушками. Что не скажешь о вторичных зонах, где информация более актуальна (при условии настройки оповещений при изменении).

    При использовании вторичной зоны трафик передачи зоны будет больше чем у первого и третьего способа, но трафик запросов будет равен нулю. Большим минусом является необходимость в наблюдении за успешностью передачи зоны.

    Вариант с зонами-заглушками имеет практически те же плюсы и минусы, что и способ с пересылками.

    Три способа. Какой лучше? Способ с пересылками является наиболее простым. Зоны-заглушки можно использоваться лишь частично. Второй способ является более сложным, а значит, увеличивается вероятность отказа. На вопрос я так и не ответил. Решайте сами.

    Если между взаимодействующими системами (клиентами, DNS-серверами), есть брандмауэры, нам необходимо разрешить трафик DNS – 53 TCP/UDP.

    Подробнее об управлении серверов DNS – http://technet.microsoft.com/en-us/library/cc794771%28WS.10%29.aspx

    Теперь немного о разрешении NETBIOS-имен. Основным способом разрешения имен в системах Windows 2000 и выше является DNS, но есть приложения, которые до сих пор используют NETBIOS-функции и короткие имена. Microsoft сделала определенный шаг, чтобы избавиться от этого. Теперь, начиная с Vista/Win2008, NETBIOS-функции не поддерживаются. Надеюсь, что в скором времени мы избавимся от NETBIOS-имен навсегда. Но отсутствие поддержки вовсе не означает, что такие приложения не будут работать в лесах Windows 2008 R2. Использование NETBIOS-имен также продолжается.

    Есть три способа разрешения NETBIOS-имен: файлы LMHOSTS, широковещательные рассылки и WINS-серверы.

    Для LMHOSTS ничего переносить не нужно, такие файлы мигрируются вместе с компьютерами. Другое дело, если вы будете в процессе миграции переименовывать системы. В этом случае вам необходимо вручную подправить эти файлы. На широковещание мы не сможем повлиять, поэтому здесь ничего сделать нельзя. Для миграции WINS-инфраструктуры мы можем воспользоваться одним из  следующих способов:

    1) Перенести инфраструктуру WINS после миграции ресурсов Active Directory:

    2) Настроить репликацию между новыми и старыми WINS-серверами, переключить компьютеры на новую инфраструктуру до миграции ресурсов AD:

    3) Как и второй способ, но компьютеры переключаем после миграции в новый лес:

    Первый и третий способ хорош тем, что мы не сталкиваемся с проблемами актуальности и сходимости данных. Все компьютеры направлены на одни и те же WINS-серверы (смигрированные и несмигрированные компьютеры), а значит, имеется единая точка, как обновления ресурсов, так и их разрешения. Затем нам придется настраивать репликацию между инфраструктурами (или для третьего способы мы уже это сделали) и, когда все ресурсы перенесены, необходимо переключить компьютеры на новые серверы. Если переключить все компьютеры за один раз, то наверняка столкнемся с некоторыми проблемами при разрешении имен. Гарантировать переключение всех компьютеров вряд ли можно в большой инфраструктуре. А если переключать порциями, то увеличится время миграции.

    Лучше столкнуться с проблемами в меньших масштабах и решать их (предотвращать) по мере поступления. Как раз это второй способ. Мы сначала настраиваем репликацию между старым и новым лесом, а затем, перед миграцией, порциями (слотами), переключаем компьютеры на новые WINS-серверы. В этой конфигурации несмигрированные ресурсы смотрят на одни серверы, смигрированные на другие. Возникает проблема с латентностью репликации данных между этими системами. Но, как я говорил, новые системы предпочитают DNS, поэтому мы вряд ли столкнемся с проблемами. А если и столкнемся, то, скорее всего, на небольшой части компьютеров.

    У нас есть возможность интегрировать DNS с WINS’ом – сделать для DNS-зоны WINS-просмотр. Нужно ли это делать для миграции? Лучше не стоит. Это лишнее усложнение, которое чревато ошибками и вероятность отказа сложных систем все же больше, чем у простых. Если говорить о реальных проблемах, то могут возникнуть ошибки при аутентификации по протоколу Kerberos. И вот почему. Например, пользователь запрашивает некоторую службу по короткому имени – SERVICE01. Подставляется некий суффикс и имя получается длинное – SERVICE01.target.com. Далее запрос отправляется на DNS-сервер, в котором для зоны target.com настроен обзор в WINS. Если DNS не находит в зоне target.com указанной записи, он отбросит доменные метки и запросит у WINS’а запись SERVICE01. WINS ответит IP-адресом. Но из какого домена эта запись? WINS – система плоских имен, поэтому неизвестно. DNS-сервер вернет пользователю ответ: SERVICE01.target.com=IP-адрес. IP-адрес будет, скорее всего, правильным – пинги пустить можно. Но вот что, если пользователь хотел обратиться к службе из старого леса – service01.source.com. Тут как раз и могут возникнуть проблемы при поиске службы по ServicePrincipalName. В результате могут возникнуть проблемы с аутентификацией по протоколу Kerberos.

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

    Как поступить, если мы решили настраивать репликацию базы WINS между инфраструктурами? Реплицировать ли базу только между  ближайшими WINS-серверами или это будет смешанная репликация?

    Посмотрите на вашу текущую модель репликации и сделайте по аналогии. Если у вас многодоменная среда и настроена репликация между серверами из разных доменов, значит, у вас нет проблем с дублированием NETBIOS-имен. Если есть, то стоит подумать о том, не возникнут ли проблемы при миграции в однодоменную структуру. В такой конфигурации можно использовать репликацию через магистраль.

    Если репликация используется только внутри домена, то настройте репликацию в пределах физической площадки – между серверами из старого домена и серверами той же площадки нового домена.

    Требования к открытию портов TCP/IP, используемых WINS-серверами – http://technet.microsoft.com/ru-ru/library/cc784026%28WS.10%29.aspx.

    Подробнее об управлении сервером WINS – http://technet.microsoft.com/en-us/library/cc739183%28WS.10%29.aspx.

    Разрешению имен стоит уделить особое внимание. Причем, не только при миграции. Ошибки, связанные с разрешением имен, составляют 80-90% от общего количества (если не брать в расчет ошибки ИТ-специалистов).

    На этом настройка разрешения имен не заканчивается. Мы будем и далее обсуждать эту тему.

    В следующей статье мы продолжим интеграцию наших инфраструктур.

    Ефимов Геннадий

    P.S.: появилась вторая часть статьи – читаем.

Комментарии

  1. Хорошая статья.

    // Лучше всего с настройки разрешения имен между инфраструктурами. Нам необходимо, чтобы смигрированные ресурсы могли разрешать имена несмигрированных ресурсов, и наоборот. Наиболее популярные механизмы разрешения имен в Windows-сетях – это DNS и NETBIOS.

    Я считаю, что “готовить” согласованное разрешение имен нужно с того, что выснить, как именно клиенты эти имена разрешают: определить преобладающие “типы узлов”, выяснить порядок просмотра суффиксов DNS…

    В остальном – очень обстоятельно, добротно и детально.

  2. про DNS, суффиксы и т.д. будет немного позже.
    пока не настроили более высокую интеграцию DNS переходить к настройке клиентов не стоит.
    выяснить особенности конкретной инфраструктуры нужно обязательно… но как правило, такой интеграции достаточно и без нее не обойтись.

  3. а как же PKI, обычно он есть в инфраструктуре

  4. kkvkkv, да, пожалуй, надо было в одной статье и PKI и файловые ресурсы, и службы печати, и почтовую систему, и граничный шлюз, и DLP, и бухучет и логистику и пользовательские данные “мигрировать”… :))

  5. Предвкушаю халивар…

    Почитайте название. Ведь мигрируют базовую инфраструктуру, а не инфраструктуру рационального уровня.

    Как я понял автор хочет рассказать как правильно подойти к миграции базовых сервисов, которые являются сердцем it-инф-ры. Вот только мне все не дает покоя одна мысль. Разве на базовом уровне есть AD? Как я понимаю на базовом уровне разрозненные средства аутентификации. Наличие AD на уровне 80%, должно быть на стандартном уровне. По крайней мере, если я правильно читал текнет. Стать была так названа просто для красоты?

    P.S. Не судите строго просто мысли в слух.

  6. Евгений, это не уровень “базовый”, а компонент инфраструктуры “базовый”. Считается, что без Active Directory и инфраструктуры-то никакой нету. 😉

  7. Просто решил для себя уточнить…
    Спасибо.

  8. Если двухкратно перевести

    core infratructure > базовая инфраструктура > basic infrastructure

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

    По теме статьи отпришусь, как прочитаю. Должно быть интересно 😉

  9. 1. Вывод о непригодности зон-заглушек по причине того, что обновления не успеют реплицироваться на остальные серера — не очень убедителен. ИМО, загушки — самое подходящее решение на время миграции.

    2. По поводу разрешения netbios-имен. Действительно ли так требовательны legacy приложения? Быть может они не привязаны к netbios, а просто используют hostname без доменой части? В этом случае, ни WINS, н LM Hosts не нужны (и вместе всем все описанные шаги по допиливаниюб wins-инфраструктуры). Старый добрый DNS и dns suffix list придут на помощь.

  10. 3. Не совсем ясна оправданность миграции source.com/SOURCE+child1.source.com/CHILD1 в target.com/TARGET.

    Вот если бы доменов было много…

  11. я ее базовой называю.. кто-то основной..

    >>> Вывод о непригодности зон-заглушек по причине того, что обновления не успеют реплицироваться на остальные серера — не очень убедителен.
    В больших инфраструктурах это более чем аргумент. От разрешения имен зависит очень многое и от невозможности разрешения имен возникает большинство ошибок. Если у вас небольшая инфраструктура и вы уверены, что описанные проблемы не возникнут, то используйте зоны-заглушки, иначе решайте сами.

    >>> По поводу разрешения netbios-имен. Действительно ли так требовательны legacy приложения? Быть может они не привязаны к netbios, а просто используют hostname без доменой части? В этом случае, ни WINS, н LM Hosts не нужны (и вместе всем все описанные шаги по допиливаниюб wins-инфраструктуры). Старый добрый DNS и dns suffix list придут на помощь.
    Если вы знаете как работают все ваши приложения и уверены, что они не используют плоскую систему именования, то WINS или аналоги могут не понадобиться. В больших инфраструктурах вам об этом ни кто не скажет.

    >>>> Не совсем ясна оправданность миграции source.com/SOURCE+child1.source.com/CHILD1 в target.com/TARGET.
    два домена-источника взяты только в качестве примера. Целесообразность тема уже другая.

  12. “Если у вас небольшая инфраструктура и вы уверены, что описанные проблемы не возникнут, то используйте зоны-заглушки, иначе решайте сами.”

    Ок, задам вопрос с другой стороны. А КАК использование вторичных зон или редиректов (вместо стабов) ускоряет репликацию обновлений на мастер зонах?

  13. компьютеры используют локальные (ближайшие) dns-серверы для регистрации и для запросов… репликация зоны настраивается между этими локальными серверами.. если у вас secondary-зона, то настраивается дополнительно оповещение, чтобы ускорить репликацию…
    пересылки также настраиваются между локальными серверами, репликация не нужна…

    в общем-то, плюсы и минусы описаны.. перечитайте еще раз…

  14. Мы же ранее говорили о Больших инфраструктурах, а описанные действия по выбору “локальных” днс-серверов и настройки пересылки/вторичных зон для них потребуют огромное количество ручной работы, а затем постоянное согласование в такие неспокойные времена, как миграция инфраструктуры. Мы же говорим о Больших инфраструктурах, не так ли?

    Также, не стоит забывать, что DNS сервер выдает NS-записи не в абы каком порядке, а так, что сначала идут IP адреса из той же сети. Таким образом, это помогает выбрать ближнего мастер-сервера для стабов.

  15. настройка пересылок и вторичных зон делается один раз. Стабы также придется настраивать вручную, скорее всего один раз.
    И сталкиваемся мы с теми же проблемами – если master-сервер недоступен, то зона обновляться не будет. Тут стоит задуматься об указании нескольких master серверов.
    для пересылок проблема такая же – решаем указанием нескольких серверов для пересылок.
    Как часто вы устанавливаете или удаляете DNS-серверы в сети? Может быть проблема надуманная и не стоит так усложнять задачу?

    NS-записи это имя_домена+имя_сервера. Что сортировать в этом случае? В качестве дополнительного ответа возвращаются A-записи с IP-адресами. NetMaskOrdering используется для A-записей с одинаковыми именами, но разными IP-адресами. Имена (DNS-серверов) у нас будут разные в данном случае. NetMaskOrdering не будет применяться.

    Об IP-адресации и балансировке: в windows 2000 сортировка осуществляется по классовым адресам, в windows 2003 и выше используется C-класс, по умолчанию (но можно настроить и другую маску). Все это усложнение, результат будет неожиданным и непредсказуемым. Чем проще – тем лучше.

    >>>Начиная с Windows Server 2008 R1, у нас есть возможность реплицировать
    >>>зоны этого типа между DNS-серверами. Стоит воспользоваться этой
    >>>возможность, тем более целевой лес у нас Windows Server 2008 R2.
    Ошибся немного. Эта фича появилась начиная с 2003.

  16. >>>Также, не стоит забывать, что DNS сервер выдает NS-записи не в абы каком
    >>>порядке, а так, что сначала идут IP адреса из той же сети.
    А зачем ему что-то выдавать вообще? NS-записи хранятся локально, в базе. Клиенту он их не отдается, если только рекурсия не отключена.

    >>>Таким образом, это помогает выбрать ближнего мастер-сервера для стабов.
    мастер-серверы указываются вручную. Они же и опрашиваются для получения записей для стаб-зон.

  17. “стоит задуматься об указании нескольких master серверов.”
    Конечно, в том и фишка!

    “для пересылок проблема такая же — решаем указанием нескольких серверов для пересылок”
    Обноавлять тяжело…

    “Как часто вы устанавливаете или удаляете DNS-серверы в сети?”
    В период миграции — весьма вероятно.

    “NetMaskOrdering используется для A-записей с одинаковыми именами, но разными IP-адресами. Имена (DNS-серверов) у нас будут разные в данном случае. NetMaskOrdering не будет применяться.”
    Согласен, не учел этот момент.

    “А зачем ему что-то выдавать вообще? NS-записи хранятся локально, в базе. Клиенту он их не отдается, если только рекурсия не отключена.”
    Клиентам NS-записи нужны для того, чтобы регистрировать свою A-запись на мастер-сервере.

    “мастер-серверы указываются вручную. Они же и опрашиваются для получения записей для стаб-зон.”
    Мы тут немного разошлись в понятиях мастер сервера орпашиваемых (вручную), и мастер-сереверов (первичных) для зоны (автоматически).

    Я к чему все это завел-то… ИМО, не так критично в переиод миграции мнгновенное обновление A-записей, как простота и управляемость процессом разрешения имен.

    За статью спасибо, тема очень хорошая. Сейчас почитаю следующую.

  18. Компания Intelligent Solution – была основана профессионалами, специализирующимися в области международного консалтинга и налогового планирования и обладающими опытом работы в консалтинговых и банковских сферах.
    Наша цель – предоставление максимально качественного сервиса по минимальным ценам. Наше преимущество – мы не работаем по шаблонным схемам.
    Для каждого клиента мы разрабатываем индивидуальные схемы согласно поставленным задачам и целям.
    Именно поэтому в результате выводится эффективная схема, которая будет максимально соответствовать задачам и достигать поставленных целей.

    Оффшоры и оффшорные компании

    Оффшоры (или оффшорные зоны) – это зоны, где иностранным компаниям предоставляются специальные льготы, в том числе и налоговые. Такая схема действует для привлечения в такие зоны иностранного капитала. Это надежный и законным инструмент бизнес, в котором есть главное правило: компания не должна проводить на территории страны регистрации хозяйственную деятельность

    Компания Intelligent Solution предлагает такие услуги:

    регистрация и комплексное сопровождение оффшорных компаний;
    регистрация компаний в низконалоговых и респектабельных юрисдикциях;
    перевод ранее зарегистрированных компаний под наше обслуживание;
    предоставление сертификата Good Standing,
    в том числе предоставление этого сертификата для компаний зарегистрированных в Белизе и на Сейшеллах не через Intelligent Solution Ltd;
    предоставление услуг номинальных директоров, секретарей и акционеров;
    открытие офисов, виртуальных офисов, представительств и филиалов;
    открытие счетов в иностранных банках;
    аудит (бухгалтерское сопровождение) Кипрских и Гонконгских компаний;
    защита активов;
    оптимизация налогообложения;
    международное налоговое и корпоративное планирование;
    помощь в оформлении вида на жительство в Латвии.

    Контакты:

    Сайт : http://www.int-solution.com
    Мейл : intelligent.solution@yahoo.com
    Icq : 642566426

  19. cost of zithromax

    Zithromax operates by stopping bacteria from developing proteins that are crucial to them.
    azithromycin purchase online