Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делегирования. Делегирование — это то каким образом пространство имен в DNS делится на зоны. Зона — это обособленная ветвь пространства DNS имен которая располагается на своих авторитарных DNS серверах. В зону может входить любое количество доменов нижележащего уровня — до тех пор пока они все расположены на одних и тех же авторитарных серверах, зона у них одна и та же.
Делегирование из родительской зоны происходит путем создания NS записей. В дочерней (делегированной) зоне создается полное описание зоны начиная с SOA записи. Вот, например, когда регистрируется домен второго уровня через регистратора nic.ru, то там при регистрации просят указать имена и адреса минимум двух DNS серверов которые будут считаться авторитарными для данной ветви пространства DNS имен. Для проведения делегирования не обязательно иметь под зону именно два DNS сервера — просто у nic.ru такая политика для того чтобы заставить клиентов обеспечить надежность системы. Вот эти два сервера становятся NS записями в домене ru.
Пример. Скажем, нами регистрируется домен второго уровня под названием net.ru. Авторитарными для него будут DNS сервера ns.net.ru (IP 1.2.3.4) и ns2.dnshosting.com (IP 5.6.7.9). В записях DNS серверов отвечающих за зону ru. (которыми управляет организация nic.ru) вносится такая информация:
$TTL 300 ru. IN SOA ns.ripn.net. hostmaster.ripn.net. ( 4014396 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS sunic.sunet.se. NS e.dns.ripn.net. NS ns.ripn.net. NS ns5.msk-ix.net. ; это добавили net.ru. NS ns.net.ru. net.ru. NS ns2.dnshosting.com. ns.net.ru. A 1.2.3.4
Запись «ns.net.ru. A 1.2.3.4» называют еще «glue record», она нужна в случаях, когда имя NS сервера располагается внутри делегированной зоны. Это вспомогательная запись которую обязательно указывать в таких случаях. Без нее возникла бы ситуация, когда для того чтобы узнать IP сервера ns.net.ru надо обратиться к нему по IP (замкнутый круг). Так как второй NS расположен в чужой зоне, то для него не указываем glue record.
В свою очередь на сервере ns.net.ru который является мастером для зоны net.ru создается полная SOA запись как и полагается:
$TTL 300 net.ru. IN SOA ns.net.ru. hostmaster.net.ru. ( 2009012500 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS ns.net.ru. NS ns2.dnshosting.com. MX 10 mail.net.ru. ns.net.ru. A 1.2.3.4 www.net.ru. A 9.8.7.6 ftp.net.ru. A 10.11.12.13 mail.net.ru. A 11.12.13.14
На slave сервере ns2.dnshosting.com в ручную записи не создаются, но он настраивается так чтобы периодически запрашивать мастер ns.net.ru и перекачивать с него всю информацию о записях в домене, а мастер ns.net.ru настраивается так чтобы отдавать все записи о зоне при запросах с подчиненного.
Точно по такой же схеме происходит делегирование доменов третьего, четвертого да любого уровня. Делегировать можно даже одно единственное хост имя!
Например случай с делегированием домена третьего уровня. Выглядеть это будет так — в записях зоны net.ru добавляется информация с NS записями о субдомене home.net.ru (допустим, будет только один авторитарный DNS сервер для этого субдомена ns.home.net.ru IP 7.7.7.7)
$TTL 300 net.ru. IN SOA ns.net.ru. hostmaster.net.ru. ( 2009012500 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS ns.net.ru. NS ns2.dnshosting.com. MX 10 mail.net.ru. ns.net.ru. A 1.2.3.4 www.net.ru. A 9.8.7.6 ftp.net.ru. A 10.11.12.13 mail.net.ru. A 11.12.13.14 ;это добавили home.net.ru. NS ns.home.net.ru. ns.home.net.ru. A 7.7.7.7
Ну и соответственно на DNS сервере ns.home.net.ru создается зона с новой SOA записью:
$TTL 300 home.net.ru. IN SOA ns.home.net.ru. adminzoni.mail.ru. ( 2009012501 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS ns.home.net.ru. ns.home.net.ru. A 7.7.7.7 home.net.ru. A 7.7.7.8 www.home.net.ru. A 7.7.7.8 proxy.home.net.ru. A 7.7.7.9
Был приведен синтаксис зоны как это принято в BIND и NSD. Для djbdns то, что написано выше будет выглядеть так:
Zhome.net.ru:ns.home.net.ru.:adminzoni.mail.ru.: \ 2009012501:7200:900:2592000:3600:300 &home.net.ru:7.7.7.7:ns.home.net.ru +home.net.ru:7.7.7.8:300 +www.home.net.ru:7.7.7.8:300 +proxy.home.net.ru:7.7.7.9:300
До кучи, напишу заодно еще и про реверс зоны и их делегирование.
Система DNS позволяет производить обратные разрешения из IP адресов в DNS имена. Для этого в дереве имен есть специальный служебный домен под именем in-addr.arpa. Этот домен имеет 256 субдоменов, каждый из субдомменов может иметь 256 своих субдоменов, у которых могут быть 256 своих субдоменов, в которых уже будет по 256 имен. Таким образом получается структура вида a.b.c.d.in-addr.arpa. где а,b,c,d это 0-255. На эту часть DNS имен распространяются те же правила, что и на обычные имена, вот только владельцем какого-либо субдомена может стать лишь организация получившая контроль за соответствующим блоком IP адресов — например провайдер, когда покупает для своих нужд у RIPE диапазоны IP адресов. Например, если провайдер купил себе префикс с адресами 123.44.55.0/24 (256 адресов), то он может получить от RIPE (регионального регистратора) и реверс зону в которой начнет создавать PTR записи по просьбе клиентов или для своих нужд:
$TTL 300 55.44.123.in-addr.arpa. IN SOA ns.net.ru. admin.net.ru. ( 2009012500 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS ns.net.ru. NS ns2.dnshosting.com. 1.55.44.123.in-addr.arpa. PTR hostname.net.ru. 2.55.44.123.in-addr.arpa. PTR imja.net.ru. 254.55.44.123.in-addr.arpa. PTR esheodnoija.net.ru.
Тут все просто и красиво потому, что в этом примере деление на DNS зону и IP субнет произошло по границе третьего и четвертого байта в IP адресе, а как делегировать половину субнета или только пару IP адресов из него? Скажем, клиент купил себе 8 «белых» IP адресов и захотел получить контроль над назначением реверс имен для них?
В таком случае можно сделать делегирование таким образом — в родительской зоне создаются CNAME записи на подставной домен, а он уже делегируется клиенту:
$TTL 300 55.44.123.in-addr.arpa. IN SOA ns.net.ru. admin.net.ru. ( 2009012500 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS ns.net.ru. NS ns2.dnshosting.com. 1.55.44.123.in-addr.arpa. PTR hostname.net.ru. 2.55.44.123.in-addr.arpa. PTR imja.net.ru. 254.55.44.123.in-addr.arpa. PTR esheodnoija.net.ru. ;создаем подставные записи 7.55.44.123.in-addr.arpa. CNAME 7.klient.55.44.123.in-addr.arpa. 8.55.44.123.in-addr.arpa. CNAME 8.klient.55.44.123.in-addr.arpa. 9.55.44.123.in-addr.arpa. CNAME 9.klient.55.44.123.in-addr.arpa. 10.55.44.123.in-addr.arpa. CNAME 10.klient.55.44.123.in-addr.arpa. 11.55.44.123.in-addr.arpa. CNAME 11.klient.55.44.123.in-addr.arpa. 12.55.44.123.in-addr.arpa. CNAME 12.klient.55.44.123.in-addr.arpa. 13.55.44.123.in-addr.arpa. CNAME 13.klient.55.44.123.in-addr.arpa. 14.55.44.123.in-addr.arpa. CNAME 14.klient.55.44.123.in-addr.arpa. ;делегируем клиенту klient.55.44.123.in-addr.arpa. NS ns1.klient.ru. klient.55.44.123.in-addr.arpa. NS ns2.hosting.com.
Клиент принимает у себя:
$TTL 300 klient.55.44.123.in-addr.arpa. IN SOA ns.klient.ru. admin.klient.ru. ( 2009012502 ;serial 7200 ;refresh 900 ;retry 2592000 ;expire 3600 ;neg. ttl ) NS ns.klient.ru. NS ns2.hosting.com. 7.klient.55.44.123.in-addr.arpa. PTR host1.klient.ru. 8.klient.55.44.123.in-addr.arpa. PTR host2.klient.ru. 9.klient.55.44.123.in-addr.arpa. PTR host3.klient.ru. 10.klient.55.44.123.in-addr.arpa. PTR host4.klient.ru. 11.klient.55.44.123.in-addr.arpa. PTR host5.klient.ru. 12.klient.55.44.123.in-addr.arpa. PTR host6.klient.ru. 13.klient.55.44.123.in-addr.arpa. PTR host7.klient.ru. 14.klient.55.44.123.in-addr.arpa. PTR host8.klient.ru. ...
Да, еще одна штука вспомнилась.
Я когда работал в провайдере, так все хотел приколоться и сделать себе почтовый адрес вида terminus@1.2.3.4.in-addr.arpa, но не успел — все лень было, а потом уволился и сейчас своих реверс зон нет нигде.
Между прочим, нету никакаих объективных причин почему бы такое не работало — DNS должен будет корректно отвечать на запросы о MX записях для домена 1.2.3.4.in-addr.arpa так же как и для обычных доменов. Если есть в наличии SMTP сервер «для поиграться» + желание приколоться, то можно прописать в PTR зоне MX запись, на почтовом сервере на который указывают MX запись прописать домен, и проверить как оно будет (99% что должно работать).