Заметки про работу с DNS зонами [2009] - DNS - Сеть - Каталог статей

	Документация по ОС FreeBSD	Среда, 29.01.2025, 22:22
		Главная Регистрация Вход

Приветствую Вас Гость | RSS

Меню сайта

Категории каталога

Apache [58]

DNS [25]

FTP [27]

Mail [74]

Samba [24]

Squid [46]

SSH [23]

VPN [35]

РРР [20]

Net [173]

Главная » Статьи » Сеть » DNS

Заметки про работу с DNS зонами [2009]

Собственно это не совсем статья, а просто собранные вместе заметки которые писались на форуме. Спрашивали про 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.