Делегирование домена на свои DNS.
У меня на сайте довольно много внимания правильному разрешению символических имен в адреса с помощью DNS. Например описано как настраивать BIND на UNIX'ах. Я неоднократно писал в на своем сайте, насколько важно правильно поднять DNS в локалке, например Рефакторинг отдельного сайта к Web-порталу совершенно невозможно выполнить при малейших ошибках в настройке DNS.
Все мои сетевые проги тоже активно работают с DNS, например мой WebDownloader_UltraLite считывает по каждому домену IP-адрес и реверсную SOA-запись:
Однако я обратил внимание, что у меня на сайте нет описания очень распространенного шаблона админской работы - делегирования домена на свои виндузовые DNS. По моим наблюдениям, под юниксами делегирование может сделать любой админ, однако на вкладках виндузового DNS многие путаются. И действительно, в виндузне запутаться немудрено.
Поэтому здесь я покажу как должны выглядеть вкладки DNS при делегировании им некоего моего домена vbnet2000-osel.ru:
Как всегда, нужны конечно два DNS - Primary и Secondary, расположенные в разных подсетях. Эти сервера уже должны иметь изначально символические имена. Иначе вся DNS-структура интернета не будет иерархической - что противоречит логике работы DNS, определенной соответствующим RFC.
Поэтому самые первые DNS в цепочке так или иначе должны быть прописаны в национальном регистраторе https://www.nic.ru/ (а домены NET, ORG - даже в несольких национальных регистраторах). В данном случае имена серверов http://www.asp-net.ru и http://mail.asp-net.ru, на которые я отдам домен vbnet2000-osel.ru, непосредственно хранятся в NIC.RU.
Итак, первым конечно настраиваем Primary DNS - главным хранителем зоны домена vbnet2000-osel.ru .
Для начала прогоняем мастер. В данном случае Primary DNS будет мой сервер //www.vb-net.com/, а Secondary DNS будет http://mail.asp-net.ru. Самая главная фишка тут в том, что если Primary DNS стоит за фаеволом (в DMZ) - то мастер впишет везде внутренние локальные имена. Это конечно неверно и их сразу же надо поправить - как в SOA:
так в DNS-серверах делегируемого домена.
Если все происходит не очень быстро (и есть шанс что определение зоны прочитали другие сервера) - то нужно увеличить инкремент зоны в на вкладке SOA. Это следует делать всегда после внесения изменений в определения зоны.
Второй момент, который важен - это проверить что наш Primary DNS имеет разрешение пересылать всем желающим определение зоны (иначе о том, что наш DNS хранит определение зоны никто никогда не узнает).
При создании Primary DNS (основной зоны) мы определили что определение зоны надо хранить в файле. Это замечательно, ибо формат этого файла полностью совместим с BIND (за исколючением специфики конца строки Win/Unix)
И теперь мы можем смотреть это определения, редактировать их, заново загружать, копировать большими пакетами таких определений, бекапить, переносить с сервера на сервер. Чесно говоря, верхний скрин со вкладками и странными иконками мне кажется более запутанным, чем текстовое определение домена ниже:
Что имеет приоритет при расхождениях определения этого текстового файла с внутренними данными, хранимыми Windows - надо указать в определении свойств самого DNS-сервера (уровнем выше в оснастке).
Там же надо указать какие сетевые интерфейсы обслуживает ваш DNS. В данном случае этот мой сервер подключен к четырем независимым поставщикам интернета:
А чтобы DNS-сервер еще и корректно обслуживал внутренюю локалку за фаерволом (а не только хранил в себе делегированные ему домены) - надо ему указать DNS всех поставщиков интернета:
После этого можно сделать проверку вашего DNS на вкладке наблюдение. Более глубоко в тему отладки DNS, в атаки пересылкой зон и проч я тут погружаться не буду. Будем считать что Primary DNS мы подняли.
Теперь поднимем Secondary DNS. Начнем с того же мастера:
Чтобы создать Secondary DNS по правилам RFC надо создать дополнительную зону. По идее DNS, хранящий заглушку, не является полномочным для хранения определения домена - однако на практике это работает. Итак, я создам заглушку, не интегрированную с ActiveDirectory. Интеграция нам совсем не нужна , ибо во-первых сервер стоит в DMZ и имеет локальное имя, а во-вторых нам совсем не нужно чтобы имена из локалки были доступными всему миру.
И нам нужна именно основная зона. Обратная будет нужна для почтовика домена vbnet2000-osel.ru (про настройку MX записи и обратного разрешения имени можнол почиать здесь - Настройка Exchange Server 2003):
После того, как мы укажем ведомому серверу - откуда считать первичное определение зоны
И считаем зону
вкладки Secondary DNS станут недоступными. Это и правильно - все изменения вносятся в основной DNS, а в Secondary DNS хранится только кэш. Однако Secondary - не означает ненужный. Прекращение регистратором делегирования домена отсчитывается именно от времени прекращения работы Secondary DNS.
И вот только теперь, можно дать задание регистратору на тестирование наших DNS и делегирование на них определения вашего домена.
Разные регистраторы проводят проверку DNS, на который надо отдать домен в течение разного времени. Например, попытка делегировать домен на ваши DNS может производиться в течении трех суток. Обычно вы получаете почтовое уведомление с сообщением об ошибке настройки DNS или сообщение о том, что домен удалось разместить на ваших DNS.
Обратите внимание, что полное управление своим доменом подразумевает не только самые распространенные записи A или немного менее распространенные записи PTP, CNAME или MX - но всего может быть более 20 типов записей.
Ровно точно так же выглядит настройка DNS в Linux. Даже вкладки такие же. Вы можете ознакомиться с ними на скринах ниже.
В заключение хотелось бы заметить, что DNS надо размещать на наиболее надежных компьютерах с резервированием каналов интернета. Даже кратковременные пропадания даже небольших DNS на хостингах, содержащих скажем тысячу определений доменов и десять тысяч поддоменов - приводят к полной недоступности для пользователей всех 10 тысяч сайтов. Поэтому для начинающих я бы не рекомендовал делегировать домены на собственные DNS, а платить за делегирование регисраторам (которые обычно имеют хорошие каналы интернета и надежные кластеры для DNS-серверов). Тем более, что многие мелкие регистраторы (но не https://www.nic.ru/) предоставляют делегирование на свои собственные DNS бесплатно.
)
|
|