BSDA в вопросах и ответах

Данная книга задумана как методическое пособие для подготовки к экзамену BSDA. Книга, тем не менее, может быть полезна не только тем кто собирается сдавать этот экзамен, но и просто широкому кругу IT-специалистов, желающих систематизировать свои знания об операционных системах семейства BSD (NetBSD, OpenBSD, FreeBSD, DragonFly BSD).

Читать -> BSDA в вопросах и ответах

Материал написан Евгением Миньковским, он старый, но многое актуально для понятия основ и по сей день.

Настройка двусторонней синхронизации файлов с помощью unison

Для решения задачи по синхронизации данных между двумя машинами, в ситуации
когда изменения могут появиться на каждом из компьютеров, прекрасно подходит
утилита unison (http://www.cis.upenn.edu/~bcpierce/unison/). При синхронизации
между удаленными машинами в качестве транспорта может использоваться ssh. При
обнаружении конфликтов, например, когда на обоих машинах отредактирован один и
тот же файл, unison пытается разрешить конфликт автоматически, а если это не
удается предоставляет пользователю интерфейс для принятия решения.

Устанавливаем unison.

Fedora/RHEL/CentOS:

   sudo yum install unison

Debian/Ubuntu:

   sudo apt-get install unison

FreeBSD:

   $ cd /usr/ports/net/unison/ && make install

Синхронизируем две локальные директории:

   unison /test1 /test2

В процессе будет выводиться статистика и задаваться вопросы, касающаяся
синхронизации и разрешения конфликтов, направление копирования будет указано стрелкой.

Для синхронизации с удаленной директорией необходимо указать:

   unison /test1 ssh://testserver.test.ru//test1

Чтобы выполнить синхронизацию автоматически, без интерактивного взаимодействия
с пользователем необходимо использовать опцию «-batch». В случае конфликта,
выполнение будет прервано с выводом соответствующего уведомления.

Для определения сложной политики синхронизации можно создать файл конфигурации
с определением параметров.

Например, создаем файл ~/.unison/test.prf:

   # Определяем список директорий, которые будут синхронизированы
   root = /home/project
   root = /mnt/NFS/home/project
 
   # Указываем сохранять права доступа и владельца
   owner = true
   times = true
 
   # Определяем список поддиректорий, которые нужно синхронизировать, остальное игнорируем:
   path = cgi-bin
   path = htdocs
   path = conf
 
   # Определяем маски для файлов, которые не нужно синхронизировать
   ignore = Name .htaccess
   ignore = Name *~
   ignore = Name .*~
   ignore = Path conf/project.conf
   ignore = Path htdocs/rrd
   ignore = Path htdocs/mon
   ignore = Name *.o
   ignore = Name *.tmp
   ignore = Name *.log
   ignore = Name *.gz
   ignore = Name *.iso
   ignore = Name {,.}*{.old}
 
   # Копируем в резервные копии изменяемых файлов в отдельную  директорию
   backup = Name *
   backups = true
   backupdir = /home/project/backup
 
   # Определяем свою команду для отображения отличий между копиями файлов при конфликте
   #diff = diff -y -W 79 --suppress-common-lines
 
   # Сохраняем лог с результатами работы в отдельном файле
   log = true
   logfile = ./sync.log

При необходимости синхронизировать описанные в файле конфигурации директории, выполняем:

   unison test

Cоветы по использованию утилиты GNU Find

GNU find является одной из наиболее часто используемых программ. На первый взгляд опции find и их синтаксис выглядят слегка непонятными. Однако, немного попрактиковавшись с find, вы сможете быстро и без труда находить любой файл в вашей системе. Чтобы помочь вам начать работать с find, рассмотрите предлагаемые десять способов её использования.

Имейте ввиду, что не все версии find одинаковы, и та, которую вы используете в Linux, будет отличаться от версий для Mac, BSD или Solaris. В основном синтаксис одинаков во всех версиях, но местами встречаются небольшие различия.

Простой поиск

Давайте начнём с простого. Если вам известно имя файла, но вы не знаете точно в каком каталоге он расположен, синтаксис find будет предельно прост. Просто сообщите find имя искомого файла:

find -name имя_файла

Если файл с именем filename существует, то команда find покажет местоположение файла или файлов, которые соответствуют этому имени, следующим образом:

jzb@kodos:~$ find -name filename
./projects/filename
jzb@kodos:~$

Поиск по размеру

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

Для такого случая у find имеется опция -size, принимающая в качестве параметра размер, являющийся критерием поиска. Размер можно указывать начиная с байтов (b), заканчивая гигабайтами (G). Например, чтобы выполнить поиск файлов размером 100 килобайт, можно использовать команду:

find -size 100k

Однако такой вариант может не подойти в нашем случае. Более подходящим будет поискать файлы размеров больше (или меньше) заданного. Чтобы выполнить такой поиск, просто добавьте «+» или «-» к размеру, и find будет искать файлы большего или меньшего размера соответственно, чем указан. Например, следующая команда найдёт все файлы размеров более 100 килобайт:

find -size +100k

а эта — менее, чем 100 килобайт:

find -size -100k

Также, вы можете попросить find найти все пустые файлы:

find -empty -type f

Обратите внимание на указанную опцию -type с параметром «f», которая указывает find искать только обычные файлы. Если не указать это, то find выведет также и пустые каталоги.

Поиск по владельцу

Другой, часто используемый, вариант поиска — поиск по принадлежности файла какому-то пользователю или даже по его отсутствию. Например, вы переместили какие-то файлы в другую систему или же удалили какого-то пользователя, вероятно сделав файлы «сиротами». Отыскать такие файлы-сироты можно простой командой:

find -nouser

Для поиска файлов, принадлежащих какому-то конкретному пользователю, существуют опции -user и -uid. Первая опция принимает как имя пользователя, так и его идентификатор, а вторая — только идентификатор. Например, если мне нужно будет найти все файлы, владельцем которых я являюсь, я воспользуюсь одной из команд:

find -user jzb
find -user 1000
find -uid 1000

Также, вам может понадобиться найти файлы принадлежащие пользователю А или пользователю Б. Для этого необходимо объединить два условия поиска при помощи оператора «-o»:

find -user root -o -user www-data

Такая команда будет искать файлы, владельцем которых является пользователь root или же пользователь www-data. Если же, например, вы хотите найти файлы, владельцем которых пользователь не является, используйте оператор «-not»:

find -not -user www-data

Естественно, операторы работают и с другими опциями. К примеру, следующая команда найдёт файлы, владельцем которых является www-data и которые размером не более ста килобайт:

find -user www-data -not -size +100k

Поиск по группе-владельцу

Ещё один способ использования find — поиск файлов, принадлежащих какой-то группе пользователей. Для этого используется опция «-group», параметром которой должно быть имя группы или её идентификатор. Например:

find -group admin

В повседневной жизни вы, вероятней всего, будете комбинировать эту опцию с другими. Например, если вам нужно отыскать файлы, принадлежащие определённому пользователю и группе.

Поиск по правам доступа

Иногда у вас может возникать необходимость найти файлы, доступные для записи кому угодно или файлы, имеющие какие-либо другие «плохие» разрешения. Подобный поиск find может осуществлять при помощи различных опций. Простейшие из них — это операторы -readable, -writable и -executable, которые работают применительно к пользователю, запустившему find. Имейте ввиду, что в слишком древних версиях find эти опции отсутствуют.

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

find -type f -perm -110

Здесь параметр «110» сообщает find набор битов доступа, а «-» заставляет игнорировать все остальные. Таким образом, если файл имеет ко всему прочему установленные биты чтения и записи, он также будет соответствовать критерию поиска, поскольку для find важно лишь то, что установлены указанные биты выполнения.

Если вам необходимо точное совпадение с указанным режимом доступа, то уберите опцию «-».

А что, если вам необходимо найти файлы, исполняемые владельцем или группой? В это случае вместо «-» используйте «/»:

find -type f -perm /110

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

Использование регулярных выражений

Иногда вам может потребоваться использование регулярных выражений, чтобы определить критерии поиска. И find поддерживает их даже в большей степени, чем вы, возможно, ожидали. find не только поддерживает использование регулярных выражений, но и позволяет использовать различные их типы. Тип регулярного выражения можно определить при помощи опции -regextype, которая принимает параметры posix-awk, posix-egrep и тому подобные. В man-странице вы найдёте полный перечень поддерживаемых типов регулярных выражений вашей версией find.

Небольшой пример. Скажем, вам нужно найти файлы, имеющие расширения «.php» и «.js». Такое можно осуществить следующей командой:

find -regextype posix-egrep -regex '.*(php|js)$'

Выглядит страшновато, не так ли? Эта команда говорит find использовать синтаксис регулярных выражений egrep (-regextype posix-egrep), а затем сообщает само регулярное выражение. Выражение обрамлено одинарными кавычками, чтобы оболочка не пыталась по-своему интерпретировать спецсимволы, использующиеся в выражении. В самом выражении «.*» означает любой символ, повторяющийся ноль или более раз. Часть выражения «(php|js)» сообщает о необходимости искать «php» или «js» (символ вертикальной черты используется для определения оператора «или»). И, наконец, знак доллара в конце выражения сообщает о том, что предыдущая часть выражения должна искаться в конце строки.

Так же, как и с правами доступа, регулярные выражения можно комбинировать.

Работа со временем

Что, если вам понадобится найти файлы, основываясь на их возрасте? Иногда бывает, что знаешь, в каком промежутке времени файл был создан, а всё остальное — позабылось. Или же, вам может понадобиться отыскать какие-то старые файлы, которые пора удалить. В общем, причин может быть куча.

find в полном объёме умеет работать со временем, позволяя искать по времени последнего доступа к файлу (-atime), времени последнего изменения файла (-mtime), или по времени его создания (-сtime).

Например, давайте все найдём файлы, которые были изменены за последние два дня:

find -mtime +2

Параметры опций, работающих со временем, можно интерпретировать как «N раз по 24 часа» и в действительности означают промежуток времени. Если вы передадите find опцию «+1», то она поймёт это как «не менее, чем 24 часа назад, но не более, чем 48».

Эти опции вы также можете комбинировать, если нужно отыскать файлы, временные критерии поиска находятся в каком-то промежутке. Так, команда

find -mtime +2 -mtime -5

означает «два или более дня назад, но не более пяти дней назад».

Работа с минутами

Иногда бывает нужно найти файлы, изменённые за последние 24 часа, и в этом случае рассмотренные опции *time по понятным причинам не подойдут. Однако, на этот случай, у find припасены специальные опции -amin, -cmin, -mmin, которые работают подобно выше рассмотренным, с той разницей, что в качестве параметров они принимают минуты, а не сутки. Так что, если вам нужно найти какие-то файлы, изменённые, например, в течение рабочего дня — это те самые опции, которые вам помогут.

Ограничение поиска

Иногда find выдаёт намного больше результатов поиска, чем вам нужно. При помощи опции -maxdepth вы можете ограничить find таким образом, чтобы она не «зарывалась» слишком глубоко. Например, если вы хотите найти все файлы c расширением «js» в каталоге wordpress, можно воспользоваться командой:

find wordpress -name '*js'

Но что, если вас интересуют файлы лишь из каталога верхнего уровня? Нет проблем: ограничьте описк при помощи опции -maxdepth:

find wordpress -maxdepth 1 -name '*js'

Такая команда заставит искать find только в каталоге wordpress, не заходя в подкаталоги, которые в нём содержатся. Если вы хотите поискать в этих подкаталогах, но не соваться глубже — увеличьте параметр опции -maxdepth на единицу и т. д.
Действия над найденными файлами

Итак, вы нашли то, что искали. Что вы будете делать с найденным? Используя xargs или опцию find -exec, можно выполнять необходимые действия с найденными файлами.

Давайте представим, что вы хотите сменить владельца каких-то файлов с root на www-data. Для начала нужно все эти файлы найти, а затем уж сменять их владельца. Смена владельца вручную по списку, полученному от find звучит как-то скучно. Всё же, лучшим решением будет использовать опцию -exec:

find -user root -exec chown www-data {} \;

Такая команда заставляет find передавать пути всех найденных файлов утилите chown, которая и будет изменять владельца файлов. Легко и просто!

Заключение

Знание возможностей утилиты find является обязательным для всех пользователей Linux, которые хотят освоить свою систему. Когда используется рабочий стол, вы можете обойтись без утилиты find, но при администрировании системы вам нужно иметь свои приемы применения утилиты find. Если вы собираетесь использовать параметры -exec и xargs для внесения изменений в файлы или удаления файлов, сначала сделайте один или пару тестов с тем, чтобы убедиться, что команда работает так, как ожидается.

Советы по работе с DNS зонами

Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делегирования. Делегирование — это то каким образом пространство имен в 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% что должно работать).

Источник

Советы по работе с DNS зонами

Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делегирования. Делегирование — это то каким образом пространство имен в 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% что должно работать).

Источник