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

  Собственно это не совсем статья, а просто собранные вместе заметки которые писались на форуме. Спрашивали про DNS - отвечал. Набралось вот какое-то количество текста с примерами и описаниями, и вот решил это все оформить в виде отдельной памятки. Если у кого-нибудь возникнут вопросы про то, что осталось за кадром - спрашивайте в каментах или в ветке форума.

Запись "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   ns1.klient.ru. admin.klient.ru. (
         2009012502   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns1.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% что должно работать).

...





Еще заметка про новый домен РФ и punycode.



Как известно недавно создали новые "национальные" домены верхнего уровня. Вот список всех TLD доменов ( http://data.iana.org/TLD/tlds-alpha-by-domain.txt ). России достался свой домен под именем "РФ.". Возникает вопрос - как это работает и как его использовать. Работает это следующим образом: юзер вписывает в адресной строке броузера "россия.рф", броузер юзера перекодирует этот адрес в формат punycode и получается "xn--h1alffa9f.xn--p1ai", далее идет стандартное обращение к DNS на разрешения А записи для имени xn--h1alffa9f.xn--p1ai. Таким образом поддержка национальных языков в DNS именах - проблема клиентского програмного обеспечения. Захотел юзер посмотреть страничку - броузер должен уметь punycode. Захотел послать письмо электропочтой - почтовый клиент должен уметь punycode. И так далее.



Администратуру DNS сервера для создания зоны надо воспользоваться punycode конвертором ( например http://mct.verisign-grs.com/ ) и переконвертировать имя своего нового, модного домена из "иванломов.рф" в "xn--80adbvrgfjb.xn--p1ai". Далее все как обычно:

$TTL 300
xn--80adbvrgfjb.xn--p1ai.   IN   SOA   ns.xn--80adbvrgfjb.xn--p1ai. ad.m.ru. (
         2012082600   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.xn--80adbvrgfjb.xn--p1ai.
      NS   ns2.dnshosting.ru.

      A   56.78.90.12

ns.xn--80adbvrgfjb.xn--p1ai.   A   98.76.54.32
www      CNAME   xn--80adbvrgfjb.xn--p1ai.

Пока что, насколько я в курсе, перекодирование в punycode - задача администратора DNS сервера. Но скорее всего в будущем это будет автоматизировано или в самих DNS серверах, или в каких-нибудь внешних конверторах. В гламурный бинд это скорее всего встроют в первую очередь (если уже не встроили).

Владимир, 2009-12-31 в 18:14:37

Хорошо расписал ;) Думаю для многих нужная статья, а я нашел решение старой задачи, которую ... уже давно решил :) но ломал голову)))

ban, 2010-01-08 в 2:03:18

а почему в боковой колонке последних статей нет этой статьи?

terminus, 2010-01-08 в 11:14:05

Зачем? Это не статья - просто маленькая памятка.

ban, 2010-01-08 в 18:54:25

> Для проведения делегирования не обязательно иметь под > зону именно два DNS сервера - просто у nic.ru такая > политика для того чтобы заставить клиентов обеспечить > надежность системы. не совсем верно. Это не политика одного из Регистраторов (RUCENTER-REG-RIPN). Это требование Правил регистрации доменных имен в домене RU:"6.1. ... Обеспечение наличия не менее двух серверов DNS делегируемого домена, имеющих надежное подключение и круглосуточно функционирующих, является обязанностью Администратора." Собственное, а чем это не статья? по мне так не меньше статья чем другие.

alex, 2010-01-18 в 11:25:16

Про view было бы неплохо написать тоже, просто многие не имеют об этом представления и задают вопросы.

unknownDaemon, 2010-02-23 в 16:02:15

>Для проведения делегирования не обязательно иметь под зону именно два DNS сервера... вот как раз вопрос по поводу: скажем поднял я NSD, одна из них - та в которой оба ns... Итого ns1 у меня есть, как впарить ns2 для nic.ru? Он не ест в качестве ns2 тот же сервер, хотя и в SOA и в реверсе он описан... :( Нужно ли поднимать для этого слейвовый инстанс или есть какие-либо иные пути?

unknownDaemon, 2010-02-23 в 16:05:07

Долбаный тачпэд :( В предыдущем камменте не хватает: поднял я NSD, [ описал зоны, ] одна из них ...

terminus, 2010-02-23 в 17:06:11

"... просто у nic.ru такая политика для того чтобы заставить клиентов обеспечить надежность системы" Я может выразился не очень удачно? Идея была в том, что сама архитектура DNS не налогает жесткого требования на количество NS для зоны, но регистраторы (тот же nic.ru) требуют 2 чтобы заставить клиента очеспечить надежность.

unknownDaemon, 2010-02-23 в 17:14:17

Правильно выразился и правильно был понят... возможно я не удачно осветил суть проблемы: вот мне как раз сейчас и нужно впарить "второй ns" именно для nic.ru, вот ломаю голову как это лучше сделать... Опять таки для повышения надежности - есть такие холявные сервисы, как например http://ns2.trifle.net, только вот я никак не могу их подружить... Ругается, что мой сервак не отдает AXFR... пытаюсь курить конфиг... пока безуспешно... по идее ему надо ключик отдать, а сервис такого не предусматривает... вот ломаю голову

unknownDaemon, 2010-02-23 в 18:00:29

Вобщем... хотел бросить один маленький vds, но накатил на него второй NSD, урезал тариф(естественно и его ресурсы) но для вторичного ns сервера вполне - вобщем решил пока так эту проблему

emerge, 2010-03-09 в 15:04:58

вполне внятная памятка для тех кому приходится копаться в днс-ах \"раз в год\". спс.

BlackCat, 2010-03-09 в 15:29:13

Отличная заметка, вопрос делегирования слабо раскрыт в документации. А идея с почтой в домене in-addr.arpa - весьма остроумная, хоть пиши заявку на регистрацию блока адресов.

Алексей, 2010-03-17 в 5:17:15

nic.ru один и тот же сервер с одним IP не примет как первичный и вторичный. В требованиях указано - должны быть разные подсети.

DarkAGeS, 2010-03-22 в 16:21:00

хм, а если есть несколько белых ip от провайдера, но машина под сервер одна и вторую поднимать под вторичный днс лень - попробовать с помощью ifconfig_fxp0=\"inet 1.2.3.4 netmask 255.255.255.248\" ifconfig_fxp0_alias0=\"inet 1.2.3.5 netmask 255.255.255.255\" в rc.conf? в теории должно работать.. пробовал кто-нибудь? и сможет ли допустим NSD слушать и отвечать с двух ip одного интерфейса или придется поднимать 2 dns-сервера? ps. не пинайте ибо сейчас только начал ковырять DNS

serverX, 2010-03-27 в 20:34:42

DarkAGeS NSы должны располагаться в разных сетях класса C.

DarkAGeS, 2010-03-27 в 21:12:16

serverX nic делегирует на NSы из одной подсети /29 - проверено

freek, 2010-04-06 в 0:30:51

Как бы понятно, а как бы и нет =) Я можно еще указать имена фалов там .zone .rev, а то куча примеров прям глаза разбегаются =)

Luser, 2010-04-07 в 12:32:18

Надеялся здесь наткнуться, суть вот в чем, есть домен mydomain.ru, и два белых адреса к нему, как мне заставить пользователей из локалки считать что mydomain.ru находится по адресу 192.168.0.100, а не по внешним? Почитал что через view можно, но не смог разобраться как делать, хотелось бы еще на эту тему увидеть решения

terminus, 2010-04-07 в 18:34:42

view это серверо-специфичныая вещь и не имеет прямого отношения к делигированиям и зонам. Настраевается она у каждого DNS сервера (BIND, tinydns, unbound) по-своему, да и добиться того чего вы хотите можно по-разному. Один вариант - использовать view на авторитарном сервере (BIND, tinydns) и настроить там, чтобы на запросы с определенных адресов он давал ответы с 192.168.0.100. Второй вариант - настроить у клиентов из локальной сети использование вашего кеш сервера (BIND, unbound), а уже у него "засорить" записи в кеше информацией с адресом 192.168.0.100.

Luser, 2010-04-08 в 8:27:00

terminus, сейчас bind стоит, с другими не работал, сервер авторитарный, можно поподробнее или ссылки второй вариант - не вариант, лучший способ когда все телодвижения в одном месте - на сервере

gabell, 2010-07-27 в 15:39:25

Слово Authoritative соответстует скорее русскому авторитетный, а не авторитарный. Хотя лично я предпочитаю, когда такие слова остаются без перевода.

gonzo111, 2010-11-18 в 13:11:00

отличная статья, собираем деньги terminus-у, чтоб человек и сидя на пенсии продолжал писать свои фундаментальные труды :)))

`Оставьте свой комментарий:`
`Ваше имя: *`
`e-mail:`
`жирный` `наклонный` `подчёркнутый` `ссылка` `цвет`	Товарищщи! Это поля для ввода комментариев к статье, а не для вопросов. Сюда пишите найденные баги, или какие-то фичи :) Для вопросов есть форум!
`Нынешний год: *`