Мы — долго запрягаем, быстро ездим, и сильно тормозим.
www.lissyara.su
—> статьи
—> FreeBSD
—> программы
—> DNS zonesЗаметки про работу с DNS зонами
Автор: terminus.
Собственно это не совсем статья, а просто собранные вместе заметки которые писались на форуме. Спрашивали про 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) вносится такая информация:
|
Запись "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 запись как и полагается:
|
На 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)
|
Ну и соответственно на DNS сервере ns.home.net.ru создается зона с новой SOA записью:
|
Был приведен синтаксис зоны как это принято в BIND и NSD. Для djbdns то, что написано выше будет выглядеть так:
|
До кучи, напишу заодно еще и про реверс зоны и их делегирование.
Система 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 записи по просьбе клиентов или для своих нужд:
|
Тут все просто и красиво потому, что в этом примере деление на DNS зону и IP субнет произошло по границе третьего и четвертого байта в IP адресе, а как делегировать половину субнета или только пару IP адресов из него? Скажем, клиент купил себе 8 "белых" IP адресов и захотел получить контроль над назначением реверс имен для них?
В таком случае можно сделать делегирование таким образом - в родительской зоне создаются CNAME записи на подставной домен, а он уже делегируется клиенту:
|
Клиент принимает у себя:
|
...
Да, еще одна штука вспомнилась.
Я когда работал в провайдере, так все хотел приколоться и сделать себе почтовый адрес вида 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". Далее все как обычно:
|
Пока что, насколько я в курсе, перекодирование в punycode - задача администратора DNS сервера. Но скорее всего в будущем это будет автоматизировано или в самих DNS серверах, или в каких-нибудь внешних конверторах. В гламурный бинд это скорее всего встроют в первую очередь (если уже не встроили).
размещено: 2010-03-09,
последнее обновление: 2010-08-26,
автор: terminus
Владимир, 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-у,
чтоб человек и сидя на пенсии продолжал писать свои фундаментальные труды :)))
Этот информационный блок появился по той простой причине,
что многие считают нормальным, брать чужую информацию не уведомляя автора
(что не так страшно), и не оставляя линк на оригинал и автора — что более существенно.
Я не против распространения информации — только за. Только условие простое — извольте
подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой,
незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
© lissyara 2006-10-24 08:47 MSK
Комментарии пользователей [22 шт.]