В физическом плане делегирование очень похоже на то, как руководитель делегирует ответственность за задачи своему персоналу. Результаты одинаковы, однако в процессе участвовало более одного человека. Менеджер получает запрос на работу, передает ответственность другому сотруднику, и либо сотрудник, либо менеджер возвращаются с результатами работы. Это все при условии, что работа, которую выполняет сотрудник, является действительно правильной и является тем, о чем просил первоначальный запрашивающий (или что запрашивающий фактически запрашивал что-то, что было допустимо в первую очередь!).
С делегированием DNS это очень похоже. Когда у com
серверов имен запрашивается место для определения полномочий зоны example.com
, они часто делегируют эту работу отдельным серверам имен (фактически в подавляющем большинстве случаев они фактически делегируют ответ другим серверам имен). Когда вы впервые регистрируете домен, скажем, наш example.com
домен, это часто делается через третью сторону, называемую регистратором. Обычно регистраторы устанавливают свои серверы имен для делегирования и обслуживают зону по умолчанию с этих серверов имен. Эта зона по умолчанию включает в себя основные требования для обслуживания этой зоны в Интернете (в SOA
, NS
и A
запись , связанную с этим NS записи).
Очевидно, что если вы сами хотите взять под контроль полномочия домена, вам следует попросить регистратора вместо этого делегировать домен вашему серверу имен. Различные регистраторы обращаются к этому в процессе по-разному: «изменить серверы имен», «использовать сторонние DNS», «добавить записи клея» и так далее. Механизм внизу остается прежним. Вы предоставляете, как правило, 2 или более «имен серверов имен» (например, ns0.example.com
и ns1.example.com
) и IP-адреса, на которых ns0
и ns1
находятся. Затем они обрабатывают запрос, и делегирование направляется от вашего регистратора на предоставленные вами серверы имен.
С технической точки зрения, это на данный момент , вы должны обеспечить ваши сервера имен и работает, обслуживающих домен example.com
, с минимумом в SOA
(начало записи полномочий), 1 или более NS
записи и A
записи (ИПС) , что эти NS записи разрешены из:
example.com. IN SOA ns0.example.com. hostmaster.example.com. ( 10 3600 900 604800 7200 )
IN NS ns0.example.com.
IN NS ns1.example.com.
ns0 IN A 192.0.2.8
ns1 IN A 192.0.2.44
(Я выбрал несколько произвольных значений для значений SOA, имен для записей NS и IP-адресов, которые разрешают серверы имен). Все это должно отражать зону, для которой вы служите.
Эта служба DNS должна быть видна из любого места в Интернете и не должна быть защищена брандмауэром (т. Е. Должен быть разрешен входящий порт udp 53 и tcp). Ваш поставщик услуг также не должен блокировать этот порт (который некоторые поставщики блокируют входящий трафик, предназначенный для этих портов).
Учитывая мое первоначальное сравнение, то com
неймсерверы являются менеджерами DNS, которые делегируют зону example.com
на сервера имен (сотрудники) , чтобы сделать работу по предоставлению базовой информации о зоне ( SOA
, NS
, A
). Вы также можете обслуживать любые дополнительные записи, такие как записи почтового сервера MX
или могут быть A
записи для вашего www.example.com
адреса.
Если этот сервер имен не выполняет работу, возвращает неправильные результаты или имеет стороннюю систему (брандмауэр / ISP), блокирующую работу, у вас не будет рабочего DNS и перерывы делегирования.
Также стоит отметить, что домен НЕ ДОЛЖЕН быть делегирован серверам имен в одном домене, ns0.example.net
и ns0.example.org
оба могут быть действительными серверами имен, которые могли бы example.com
делегировать их. При условии, что оба этих сервера имен обслуживают example.com
домен.