(Notes) Notes (2009 год)

Делегирование домена на свои 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 бесплатно.



Comments ( )
<00>  <01>  <02>  <03>  <04>  <05>  <06>  <07>  <08>  <09>  <10>  <11>  <12>  <13>  <14>  <15>  <16>  <17>  <18>  <19>  <20>  <21>  <22>  <23
Link to this page: //www.vb-net.com/DomainDelegated/index.htm
<SITEMAP>  <MVC>  <ASP>  <NET>  <DATA>  <KIOSK>  <FLEX>  <SQL>  <NOTES>  <LINUX>  <MONO>  <FREEWARE>  <DOCS>  <ENG>  <CHAT ME>  <ABOUT ME>  < THANKS ME>