новости
статьи
.технологии

DNS “reloaded”

Почему у статьи такое странное название? – спросит пытливый читатель. А потому, что эта статья уже публиковалась в далеком 2000 году. Эта, да не совсем... Несмотря на то, что базовые концепции системы доменных имен остались без изменения не то, что с 2000 года, а, по, правде говоря, с конца 80-х годов прошлого века, появилось много нововведений и дополнений – как к самому протоколу, так и к различным процедурам, связанным с регистрацией доменных имен. Поэтому статья была практически полностью переписана, так что даже нашим старым читателям, помнящим этот «эпохальный» (по размеру, разумеется ;) труд еще по газетной версии «Сетевых решений», рекомендуем с ней ознакомиться.

DNS - зачем оно нужно?

Domain Name System (система доменных имен)
— это технология трансляции легко запоминаемого человеком символьного имени хоста в IP-адреса, которыми и только которыми оперируют хосты и маршрутизаторы, взаимодействующие через Internet Protocol. В более широком смысле DNS — это также система управления иерархической распределенной базой данных имен; методология назначения имен, выделения зон ответственности DNS и управления оными (в народе популярен термин «ведение зоны ответсвенности»).

как это работает?

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

Домен — это группа (набор, совокупность) имен, организованная по некоторому критерию — географическому, функциональному, корпоративному и проч. В соответствии с иерархией имен DNS домены бывают корневого (нулевого), первого, второго, третьего и т. д. уровней. Анализ имени и отсчет уровня домена производится справа налево. Разделителем в отсчете уровней служит точка.

Пример:

- com, by, arpa — домены первого уровня;

- minsk.by, google.com, in-addr.arpa — домены второго уровня;

- nestor.minsk.by, en.wikipedia.org, 121.226.194.in-addr.arpa — домнны третьего уровня.

Существует также понятие поддомена, домена в домене. В частности nestor.minsk.by можно назвать поддоменом minsk.by, а users.nestor.minsk.by — поддоменом nestor.minsk.by соответственно. Впрочем, автору этот термин не очень нравится, поскольку вносит лишнюю путаницу.

Полное доменное имя (Full Qualified Domain Name) — доменное имя хоста, включающее в себя собственно имя хоста, дополненное именем домена соотвествующего уровня. При работе с базой данных имен в конце полного доменного имени ставится точка.

Зона ответсвенности (zone of authority) — часть пространства имен DNS, за которую отвечает конкретный сервер имен. Сервер имен хранит IP-адреса всех имен данной зоны, а также указания на домены более высоких уровней, либо может включать и информацию по ним.

Реверсная зона — зона в домене первого уровня in-addr.arpa (и его поддоменах), предназначенная для нахождения символьного доменного имени хоста по его IP-адресу.

База данных зоны ответственности — база, хранящаяся на сервере имен, содержащая информацию соответствии имен хостов и их адресов, указатели на почтовые сервера, обслуживающие данный домен, а также другую информацию об этом домене и хостах в нем. Состоит из ресурсных записей (Resource Records, RR).

Ресолвер — модуль DNS клиентского ПО, посылающий запросы на разрешение имен, проще говоря — DNS-клиент.

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

Запросы к DNS-серверам бывают двух видов: рекурсивные и итеративные.

Рекурсивный запрос предполагает получение клиентом IP-адреса либо сообщения об ошибке, а итеративный — искомого IP-адреса или адреса сервера, который может его сообщить (ответственного за ту зону, в которой находится искомый хост).

Дальнейшие термины будут расшифровывыаться по ходу повествования.

Как правильно подчеркнул в своем материале о DNS Дмитрий Ю. Карпов «Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос”.

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

Задача: обращение на веб-страницу нашего издательства — www.nestor.minsk.by.

1. После того, как вы набрали символьный адрес в поле URL своего браузера, он обращается к функции Winsock GetHostByName (если речь идет о платформе win32), которая в данном случае и является ресолвером DNS.

2. Ресолвер посылает локальному DNS-серверу рекурсивный запрос, в котором просит определить IP-адрес для www.nestor.minsk.by.

3. Локальный сервер смотрит, не дает ли ответа на вопрос содержимое баз данных его собственных зон ответственности. Если да — посылает ответ ресолверу. Если нет —

4. Локальный сервер посылает корневому (ответственному за зону домена нулевого уровня, обозначаемого иногда точкой (.) DNS-серверу итеративный вопрос об узле www.nestor.minsk.by.

5. Корневой сервер вообще-то ничего о хостах не знает, и может сообщить лишь адрес сервера(ов), ответственного(ых) за зону.by.

6. Локальный сервер продолжает посылать итеративные запросы по очереди серверам ответственным за зоны by. и minsk.by и наконец доходит до сервера, ответственного за зону nestor.minsk.by.

7. Сервер домена nestor.minsk.by находит в своей базе данных (о формате оной речь пойдет чуть ниже) искомый хост и возвращает локальному серверу IP-адрес, соответствующий этому имени — 194.226.121.90.

8. Локальный DNS-сервер посылает клиенту искомый IP-адрес (и опционально — кучу малополезной для клиента белиберды в разделе Authority, как то имена и IP-адреса серверов, ответственных за домен nestor.minsk.by, чем только гадит и без того загаженный трафик;)

9. Ресолвер отдает браузеру желанные циферки и последний производит TCP соединение на 194.226.121.90:80 — начинается собственно веб:)

Большинство DNS-серверов кэшируют запросы, на которые они отвечают. Поэтому не исключено, что вся эта 9-этапная конструкция будет заменена на более простое взаимодействие — 1) запрос ресолвера к локальному серверу 2) выгребание из кэша сервера заветной четырехоктетной комбинации 3) отдавание этого добра ресолверу. Чем популярнее в народе, который имеет привычку обращаться к этому локальному DNS-серверу, хост, тем больше вероятность, что данные о его адресе вы получете именно из кэша. Кстати ресолверы тоже имеют склонность к кешированию, что может создать некоторые временные проблемы.

DNS использует для свое работы 53 порт (UDP и TCP). Большинство запросов и ответов передаются с помощью UDP, и лишь объемные ответы (больше 512 байт) и процедуры зонального обмена (см. ниже) требуют использования TCP. Впрочем есть реализации ресолверов, работающих исключительно по TCP. Еще кое-что из жизни DNS-серверов и их хозяев. Дабы функционирование системы DNS было более стабильным, спецификация предусматривает наличие помимо основного ответственного за зону сервера еще и дополнительных серверов имен.

Основной (первичный, primary, master) NS — сервер, на котором администрация домена вносит изменеия в файлы базы данных зоны.

Резервный (вторичный, secondary, slave) NS — сервер, получающий информацию о своей зоне от других серверов, ответственных за данную зону (обычно — от первичного нэймсервера). Таких серверов может быть несколько для каждой зоны, верхнего предела явно не существует, но желательно — не менее одного (а в большинстве случаев при делегировании наличие одного основного и хотя бы одного резервного серверов имен является обязательным условием регистрации домена).

Для чего следует создавать вторичные нэймсерверы:

1. Избыточность в поддержании домена в работоспособном состоянии. При отказе (недоступности) одного из них остальные возьмут всю обработку запросов на себя и домен не «потеряется».

HINT! Одно из “правил хорошего тона» в администрировании DNS гласит: вторичные нэймсерверы предпочтительно создавать так, чтобы они находились “подальше” от основного — по меньшей мере в другой автономной системе.

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

3. За счет создания вторичных серверов уменьшается нагрузка на первичный. Без комментариев: это и так понятно:)

Технология передачи содержимого базы данных зоны называется зональным обменом (зонной передачей, zone transfer). Для осуществления ее предусмотрено два типа запроса — AXFR (полный трансфер) и IXFR (инкрементальный трансфер).

Существует дискуссия на тему того, стоит ли разрешать трансфер зоны кому-либо помимо своих вторичных нэймсерверов. Дело в том, что запрос AXFR/IXFR — самый обыкновенный запрос к NS и по спецификации он не является чьей-либо исключительной прерогативой. Еще несколько лет назад обратившись к любому из обслуживающих зону серверов с таким запросом, клиент мог получить листинг всей зоны и почитать его на досуге. Теперь все больше администраторов предпочитают ограничивать возможность трансфера, оставляя ее только для вторичных NS (в большинстве реализаций DNS- демонов предусмотрен такой вид настройки). Часть всемирной сетевой общественности возмущается по этому поводу несказанно: мол, статистику о развитии Интернет тяжело стало собирать. Вобщем дело вашей совести и степени параноидальности — допускать лишние глаза к базе данных зоны или нет. Я не допускаю, а вот администратор домена, чья зона красуется у нас в этой статье — допускает. Хозяин — барин.

зоны ответственности и типы записей

А теперь обратим наше внимание на формат базы данных зоны ответственности и записей в ней. Сие ценное знание нужно нам по крайней мере для одной из вещей: ведения собственной зоны и/или получения информации о чужой зоне и, естественно, о хостах в ней.

Вот вам пример «живой и настоящей» зоны ответственности, будем разбираться с форматом на ее примере.

$ORIGIN neurology.ru.
@ 1D IN SOA dns0.mtu.ru. hostmaster.mtu.ru. (
2001103106; serial
3H; refresh
30M; retry
1W; expiry
1D ); minimum

23h30m IN NS dns0.mtu.ru.
23h30m IN NS dns1.mtu.ru.
1D IN MX10 umail.ru.
1D IN A 62.118.254.152
www 1D IN CNAME unix.hosting.ru.


Как уже было сказано выше, база данных DNS состоит из ресурсных записей (далее — RR или запись). Стандартный формат любой записи выглядит так:

{name} {ttl} addr-class Record Type Record Specific data

где name — доменное имя, к которому относится данная запись. Может выражаться следующими формами:

1. полное доменное имя (обязательна точка в конце имени!);

2. имя хоста, которое при обработке запросов дополняется именем текущего ориджина (ORIGIN), который обычно соответствует имени домена, описываемого в данном файле базы данных. Впрочем в течение файла ориждн может и поменяться;

3. пустота — предполагает, что в данной RR речь идет о том же имени, что и в предыдущей;

4. @ — здесь и в других местах базы данных указывает на текущий ориджин.

В приведенном примере мы видим практически все из приведенного, кроме записи, начинающейся полным доменным именем.

ttl — Time To Live, время жизни записи. Время, указывающееся по умолчанию в секундах (хотя, как видно из приведенной иллюстрации, возможны и более крупные единицы измерения), которое информация данной записи проболтается в кэшах чужих серверов. Если оставить это поле пустым, будет использоваться значение ttl, указанное в опциях записи SOA.

addr-class — на сегодняшний день ничего кроме класса IN (INternet) не используется. Заполняется в обязательном порядке (хотя смысла в свете вышесказанного не имеет никакого;)

Record Type — собственно тип записи, то, что мы этой записью хотим сказать. Их вообще-то достаточно много (see RFC 1035), вот вам самые используемые вещи:

А — Address — IP-адрес, соответствующий данному имени.

АААА или А6— то же самое, но для IPv6.

NS — NameServer — обслуживающий домен нэйм-сервер. Таких записей может быть ровно столько, сколько серверов держит эту зону. В приведенном примере их у нас два штука.

MX — Mail eXchange — mail-сервер, получающий почту для данного имени.

CNAME — Canonical NAME — основное имя хоста, если указанное в поле name — псевдоним. Мода последних лет утверждает, что запись эта обречена на медленное отмирание. Вместо нее желательно использовать запись A или АААА. О вкусах не спорят, а колхоз — дело добровольное, вобщем как хотите — так и пишите;)

HINFO — Host INFOrmation — информация о хосте, если конечно администратору зоны придет в голову такие глупости писать. Чаще всего речь идет об операционной системе и аппаратном обеспечении хоста (непуганные американцы в далеких 80-х такое придумали ;)

TXT — TeXT — какой-то произвольный текст, комментарий.

WKS — Well Known Services — информация о том, какие сервисы работают на данном хосте по данному протоколу. (корявое объяснение конечно... see RFC 1035).

PTR — PoinTeR — запись используется в реверсных зонах. Для получения имени по IP-адресу.

SOA — Start Of Authority — начало зоны ответственности, параметры зоны.

NAPTR - Naming Authority Pointer – новый тип записи, поддерживающий регулярные выражения для перезаписи адресов (URI rewriting). Думаю, мы вернемся к рассмотрению этого чудо-нововведения в отдельной статье.

SRV - SeRVice – относительно новый тип записи, позволяющий клиенту отыскивать нужные ему сервисы в сети. Активно используется такими протоколами, как SIP и XMPP. Также много SRV-записей можно обнаружить в DNS-зонах, относящихся к Windows-домену.

Record Specific data — данные, соответсвующие формату записи каждого типа. В зависимости от типа RR, это могут быть IP-адреса хостов, доменные имена, тексты произвольного характера и другое.

Формат ресурсных записей мы тут подробно разбирать не будем. Большинство насущного вполне сносно описано в материале «Настройка DNS сервера на примере программного продукта bind 8-й версии”, а любопытные да отправятся наконец-то читать RFC 1035 (если бы значительная часть современных сетевиков не дрожала от ужаса при одном лишь упоминании этих заветных трех букв, мне вообще не пришлось бы писать эту статю!;) Однако позволю себе остановиться на некоторых хинтах и всеобщих (и частных) заблуждениях:

1. Внимательно разберитесь с форматом записи SOA. Большинство народу имеет манеру либо использовать «шапку по умолчанию», предлагаемую в комплекте с некоторыми демонами (серверными программами) DNS или сдирают у ближнего своего, как советует автор материала о настройке bind. IMHO лучше не полениться и написать хотя бы один раз самому. Обратите внимание, что:

- поле serial может содержать совершенно произвольное, увеличивающееся на произвольную же величину с каждым внесением изменений в зону число, а не только общенародное «ГГГГММДДНН».

- поле expiry обозначает верхний предел (обычно в секундах, но могут быть и другие единицы измерения времени), после которого вторичные нэймсерверы обязаны заняться обновлением зоны. А не указание на продолжительность хранение в кэшах, как думают некоторые.

- поле minimum как раз таки относится к кэшу. Это минимальный и дефолтовый ttl для всех ресурсных записей зоны. То бишь для ясности понимания следует уяснить, что ttl задается для каждой ресурсной записи (см. выше), но в случае отсутствия этого поля в записи — используется дефолтовый из SOA.

И еще посоветую для ознакомления следующий документ: RIPE-203 «Recommendations for DNS SOA Values” — http://www.ripe.net/ripe/docs/ripe- 203.html. Хотя вовсе не факт, что указанные в нем соображения следует воспринимать как безусловную истину в последней инстанции.

HINT! Очень распространено в народе заблуждение о том, что, дескать, как ни крути, а после внесения изменений в записи DNS должно пройти некоторое время, прежде чем информация «распростарнится по всему миру». Заблуждение заключается в том, что по сути не новая информация «распространяется», а старая живет себе, догнивает согласно указанному вами же ttl в кэшах чужих серверов. Бороться с этим очень просто. Допустим, у вас должен смениться адрес веб-сервера. Доселе ttl для этой записи (или дефолтовывй) был равен, предположим, 12 часам. За 12+х часов (чтобы уж наверняка) до запланированных изменений вы подправляете для вашей (еще старой) записи о адресе веб-сервера ttl, меняя его на что-то стремящееся к нулю, и спокойно занимаетесь своими делами — переносите содержимое вашего веба на новое место и наводите марафет.К назначенному времени все мыслимые и немыслимые кэши будут готовы буквально через несколько секунд принять новую информацию, и вы вносите правку в поле адреса вашего веб-сервера. Ни одна тварь (в смысле — посетитель;) не пролетит мимо, попав вместо вашего веба на какую-то в лучшем случае заглушку. Для 99.9% посетителей сайта переход на новый адрес будет абсолютно незаметным.

Единственный минус маленького значения ttl — увеличивается трафик на держащий вашу зону DNS-сервер, поэтому этой мерой злоупотреблять, естественно не стоит — чай не каждый день куда-нибудь переезжаете;) Переехали — вернули ttl к более разумному значению.


2. Не все золото, что блестит — гласит народная мудрость. С DNS та же проблема: вопреки существующему поверью точка далеко не всегда указывает на то, что здесь должна начаться новая зона ответственности или что только самый левый блок является именем хоста. Вот вам пример из жизни, опять же на тему нашего домена: только после 2-х лет существования полного доменного имени www.nestor.minsk.by было решено выделить отдельную зону ответственности nestor.minsk.by. До этого все выглядело приблизительно так:

$ORIGIN = minsk.by
...
...
www.nestor.minsk.by. IN CNAME www.somehost
...


(существовала запись о хосте со сложносочиненным именем www.nestor в зоне minsk.by)

А теперь вот так:

$ORIGIN = nestor.minsk.by

@ 86400 IN SOA nestor.minsk.by. alice.nestor.minsk.by. (
...
...
www IN A 194.226.121.90
...


(существует зона ответственности и домен 3-го уровня nestor.minsk.by и запись о хосте www в нем)

wildcard records

Определение данного типа записи, данное Википедией, звучит слегка обескураживающе: «Wildcard-запись – это запись в зоне, которая соответствует всем запросам для несуществующих доменных имен, то есть имен, для которых вообще нет никакой записи». А если по-простому, то такая запись – это просто подстановка, что-то вроде простейшего регулярного выражения. Проще разобраться на примере:

$ORIGIN = example.com

* IN A 192.168.44.3


Это означает, что А-запросы для www.example.com, something.example.com, bla.bla.bla.example.com и т.п. дадут один ответ - 192.168.44.3. Аналогично можно сделать и МХ-запись.

Изначально возможность таких подстановок была описана в RFC 1034, однако на сегодняшний день мало кто придерживается этого документа в реализации wildcards. Дело в том, что все немного по-разному воспринимают ситуации, когда шаблоны описывают перекрывающиеся области. Более того, иногда целесообразно отступить от спецификации в угоду удобства пользования рядовыми юзерами. Вот такой пример приводит все та же Википедия. В зоне example.com есть МХ-запись для *.example.com и А-запись для www.example.com. Что будет, если юзер выполнит МХ-запрос (внимание!) на www.example.com? По RFC ответ должен быть отрицательным – «записи не существует». Однако юзер, скорее всего, просто ошибся, и правильным по сути будет ответ, основанный на МХ-записи для *.example.com. В таком ключе действуют, по крайней мере два DNS-сервера - Microsoft DNS server и MaraDNS.

О других тонкостях обработки шаблонов разными DNS-серверами читайте в документации к оным.

glue record

Теперь хочу обратить ваше внимание на вещь, которая при всей своей тривиальности почему-то вызывает замешательство даже у вполне продвинутых администраторов. Это так называемая glue record (приклеивающая запись). Нет, это не особый тип записи в файле зоны, это просто стандартный прием, часто используемый при делегировании зоны ответственности. Суть в следующем. Когда вы подаете заявку на делегирование, от вас требуются по крайней мере две обязательные вещи: название домена (зоны) и список неймсерверов. По стандарту неймсерверы для зоны указываются по DNS- именам, а не IP-адресам. Это означает, что ресолвер, получив имя неймсервера, у которого можно узнать адрес интересующего нас хоста, должен выполнить еще один DNS-запрос, с помощью которого мы узнаем IP-адрес нужного неймсервера. Если имя этого неймсервера находится в другой зоне ответсвенности, все будет ОК. Однако если имя неймсервера находится в той же зоне, ситуация зациклится. Чтобы этого не произошло, администратор верхней по отношению к нам зоны должен прописать дополнительную А-запись для нашего неймсервера – glue record.

Не очень понятно? Давайте разберем на примере.

Итак, есть существующая зона minsk.by. Мы подаем заявку на делегирование домена 3-го уровня nestor.minsk.by. В качестве неймсерверов будут выступать хосты с именами ns1.nestor.minsk.by и ns2.nestor.minsk.by. Чтобы все заработало, администратор зоны minsk.by должен прописать у себя примерно следующее:

$ORIGIN = minsk.by

nestor IN NS ns1.nestor
nestor IN NS ns2.nestor
ns1.nestor IN A 194.226.121.90
ns2.nestor IN A 194.158.200.188


Последние две записи и есть glue records, без которых запросы будут зацикливаться.

Если бы мы решили использовать в качестве авторизованных для нашей зоны неймсерверы хостинг-провайдера(ов), картинка могла быть иной:

$ORIGIN = minsk.by

nestor IN NS ns1.mycoolhoster.net.
nestor IN NS ns2.anothergoodhoster.biz.


о черных дырах DNS

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

Такой же ошибкой будет добавить пару неймсерверов непосредственно в файл зоны, не продублировав на вышестоящем сервере. Может быть, конечно, вам это нужно исходя из каких-то специфических внутренних задач, но в общем случае такое прописывание – пустое дело. Ни уму, что называется, ни сердцу: все равно данные о неймсерверах, обслуживающих вашу зону, клиенты запрашивают у вышестоящего сервера.

dynamic DNS и TSIG

Dynamic DNS (DDNS) – это система, позволяющая в реальном времени обновлять данные доменной зоны. Чаще всего эта фича используется для динамического назначения DNS-имен хостам с меняющимся IP-адресом. Для чего это может потребоваться на практике? Например, для клиентов, которые хотят держать DNS-серверы на хостах с динамическими адресами. Также DDNS поддерживается многими DNS-хостерами, которые предоставляют своим пользователям клинетский софт, отправляющий хостеру апдейты каждый раз, когда IP-адреса меняются. Многие маршрутизаторы и подобные сетевые устройства также поддерживают DDNS.

«Кошерный» DDNS описан в RFC 2136, однако термин dynamic DNS применим к любому механизму изменения DNS-клиентом содержимого зоны. Существует множество коммерческих и халявных провайдеров Dynamic DNS-сервиса, которые используют какие-то свои нестандартные методы. Достаточно популярным вариантом является обновление DNS с помощью банальных HTTP GET-запросов.

Поскольку обновление зон с DNS-клиента может быть весьма опасным мероприятием, совместно с DDNS обычно используется протокол TSIG. Он снабжает DDNS механизмами аутентификации каждой из взаимодействующих сторон, используя общий секретный ключ. Чтобы злоумышленник не мог, перехватив данные по сети, выяснить секретный ключ, используется необратимое хеширование. Также предусмотрено использование временных меток, что не позволяет повторно использовать перехваченные запросы/ответы. Отсюда исходит дополнительное требование к хостам, использующим DDNS+TSIG – их часы должны быть синхронизированы.

Обновления передаются в виде наборов инструкций для DNS-сервера. Запрос включает заголовок, имя обновляемой зоны, необходимые условия, которые должны быть выполнены и списко записей, которые нужно обновить. TSIG добавляет еще одну запись, которая включает временную метку, хэш запроса и имя секретного ключа, использованного для подписи запроса. В RFC 2535 есть рекомендации, каким должно быть это имя. Ответ на успешное обновление также должен быть подписан с помощью TSIG. А вот сообщения об ошибках и неудачах не подписываются, чтобы не дать атакующему возможности сделать какие-то выводы относительно используемого ключа, посылая «специально обученные» тестовые запросы на обновление.

Microsoft использует в своих продуктах альтернативный метод защиты - GSS-TSIG, который использует для аутентификации Kerberos. При этом исчезает необходимость ручной инсталляции ключей. Этот протокол, кстати, имеет статус proposed standard.

DNSSEC

The Domain Name System Security Extensions (DNSSEC, расширения системы доменных имен в области безопасности) – это набор спецификаций, описывающих некоторые методы защиты клиентов (ресолверов) от получения фальшивых данных DNS. Согласно доктрине DNSSEC все ответы серверов должны иметь цифровую подпись. Проверяя эту подпись, ресолвер выясняет, является ли полученная им информация идентичной той, что расположена на авторизованном неймсервере. DNSSEC может также быть полезен в деле защиты другой информации, как, например, криптографических сертификатов общего назначения, хранящихся в базах DNS. RFC 4398 описывает, как распространять такие сертификаты с использованием протокола DNS. В частности, речь может идти о криптосертификатах для электронной почты – с помощью DNSSEC можно построить распределенную всемирную инфраструктуру публичных ключей для e-mail.

Вопреки распространенному заблуждению, DNSSEC не обеспечивает конфиденциальности самих данных, передаваемых по сети – все DNSSEC-ответы аутентифицированы, но не зашифрованы.

Текущие спецификации DNSSEC (DNSSEC-bis) - RFC 4033, 4034 и 4035 - детально описывают протокол DNSSEC в его сегодняшнем виде. С выходом этих документов в марте 2005 года RFC 2535 («старый» DNSSEC) перешел в разряд устаревших.

DNS Views

Вообще-то это фича не описана в спецификациях, относящихся к DNS, так что считать ее частью технологии будет не совсем корректно. Это просто конфигурационная опция популярнейшего DNS-сервера bind, на котором «крутится» подавляющее число доменов в мире. Однако фишка настолько, на мой взгляд, долгожданная и востребованная, что не упомянуть о ней я не могу.

Итак, суть в том, что теперь bind можно настроить таким образом, чтобы он отдавал разные данные в зависимости от адреса запрашивающего. Типичный пример использования: один и тот же сервер (например, веб) имеет несколько IP-адресов – скажем, фейковый 192.168.7.1 во внутренней сети и реальный 178.28.0.1 для остального мира. При этом было бы здорово, чтобы клиенты обращались к нему по одному и тому же доменному имени (именам), поскольку большиснтво веб-серверов на сегодняшний день конфигурируются как виртуальные хосты на основе имен. Путь это будет www.example.com. Итак, клиенты из внутренней сети на запрос А-записи для www.example.com должны получать 192.168.7.1, а из внешней - 178.28.0.1. Все просто. Но раньше это было не так-то и просто реализовать – приходилось ставить два отдельных неймсервера, прописывать hosts на машинах у внутренних юзеров, колдовать с файрволлом...

Теперь счастливые обладатели bind версии 9.х могут прописать в конфиге примерно следующее (адреса даны для нашего примера, разумеется):

acl “internal” {192.168.7.0/24; 127/8}
...
view “internal”
{
match-clients { internal; }
recursion yes;
zone “.” {...}
zone “example.com”
{
type master;
file “zonefile.internal”;
allow-transfer {...};
}
}

view “external”
{
match-clients { any; }
recursion no;
zone “example.com”
{
type master;
file “zonefile.external”;
allow-transfer {...};
}
}


Как видите, для каждого типа клиентов у нас разные файлы зоны. А уж в них вписываем нужные нам А-записи для хоста www.example.com, а также все остальное, что сочтете нужным. Как это делать вы, конечно же, знаете сами.

свой собственный домен - за и против

До поры до времени можно смириться с тем, что ваше, пусть даже очень симпатичное и осмысленное доменное имя находится в чужой зоне
ответственности. Вроде и хлопот поменьше: не надо поддерживать DNS-сервер (а то и два, если договориться не с кем о организации вторичного (резервного) сервера имен); не надо вникать в формат баз данных зон (хотя как вы могли убедиться из вышесказанного — там все очень просто)... Но позвольте мне вас убедить: случись вам несколько изменить плавный ход ваших Интернетных дел (завести новый или перенести в другое место старый веб-сайт, лишиться почтового ящика из-за некорректной ценовой политики провайдера, да мало ли что еще...) — и хлопот у вас резко прибавится. А именно:

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

- Даже если вам придется подождать пол недели для выполнения вашей заявки, не факт, что ttl на вашу запись не был установлен размером в 3 дня (неделю, месяц, год — шутка ;) Поэтому вашим партнерам и посетителям сайта тоже придется подождать.

- У администраторов «чужих» доменов могут быть свои взгляды на мир, и название вашей рабочей машины fuckingbastard.puritan-domain.com. они могут забраковать:)

- Если у хозяев вашего домена есть обязательство вносить изменения в записи о ваших хостах и др. касаемую вас информацию бесплатно, то после трогательных просьб делать это раз 5 в день они перестанут с вами здороваться;).

После того, как вы тем или иным из описанных ниже способов «пробъете» себе собственную зону ответственности, этих проблем у вас быть не болжно: сам себе режиссер, сам себе капитан, мой дом — моя крепость, ерунды наворотил — сам дурак... Свобода!

И вот на этом самом месте может раздасться возглас читателя «Ух как просто! Хочу и себе такое! Хочу администрировать свой домен!». Хорошо, тогда в следующем номере приступим ко второй части повествования ;)

Продолжение следует.



Alice D. Saemon, adsaemon@nestormedia.com
обсудить статью
© сетевые решения
.
.