Сегодня вопросы имен доменов и управления IP-адресами наиболее приоритетны для администраторов сетей. К счастью, некоторые из них легко разрешимы благодаря последним техническим разработкам. DHCP, например, избавляет администраторов от необходимости вести контроль и конфигурировать по отдельности IP-адреса клиентов каждый раз при их добавлении, перемещении или изменении. Однако, решая одну проблему, DHCP порождает другую: каким образом модифицировать статическую систему имен доменов (Domain Name System, DNS) в соответствии с новыми назначениями IP-адресов?

До недавнего времени никакого стандарта на взаимодействие между серверами DHCP и статически обновляемыми серверами DNS не было. Однако с выходом RFC 2136 под названием "Динамические обновления в системе имен доменов" (автор Пол Викси, апрель 1997 г.) появилось предложение по стандарту на динамическую DNS (Dynamic DNS, DDNS). Кроме того, несколько новых предложений относительно DNS совместимы с ним.

Подавляющее большинство современных реализаций DNS основаны на комплекте приложений под названием берклевский демон имен Internet (Berkley Internet Name Daemon, BIND). В мае 1997 года Internet Software Consortium выпустил версию BIND 8.1.1 с первой реализацией недавно предложенного стандарта DNS для сообщества пользователей Unix.

В этой статье мы коснемся истории появления DNS и ее связи с BIND, а также обсудим вопросы защиты и управления, связанные с предложениями по стандарту на DHCP и DDNS.

При навигации по Сети в поисках какой-либо новой странички о светлом пиве типа www.suds.com или при отправке кому-либо электронной почты по адресу типа billyjoebob@suds.com вы используете DNS. Разработанная в начале 80-х DNS переводит имя удаленной системы в соответствующий IP-адрес.

До появления DNS хосты Internet идентифицировались с помощью этих адресов. К сожалению, ввиду экспотенциального роста числа хостов в Internet с конца 70-х, управлять соединениями посредством числовой адресной схемы стало весьма затруднительно. Такие адреса было тяжело запоминать. Более того, с ростом масштаба сетей управление назначениями отдельных IP-адресов заметно усложнилось.

В 1982 году соглашение об именовании, известное как Domain Name System, было разработано для разрешения сложившейся ситуации. Определенная в RFC 819, концепция предполагала переход от простого метода идентификации пользователь@хост к более сложной иерархической структуре имен доменов пользователь@домен.

В 1982 году доктор Поль Мокапетрис изложил в RFC 882 и 883 базовые спецификации для реализации DNS. В 1987 г. он написал современную спецификацию DNS в RFC 1034 и 1035. Эти спецификации позволяют присвоить отдельному хосту имя наряду с соответствующим IP-адресом, относительно которого данное имя разрешается. (Список RFC, касающихся DNS, см. в Таблице 1.)

Как указано в RFC 1034, серверы DNS организуются в иерархическую структуру в виде опрокинутого дерева с одним корневым узлом "." в вершине; этот узел разветвляется на другие узлы (см. Рисунок 1). Вся структура имен доменов в целом известна как пространство имен доменов. Каждый узел имеет имя, часть которого представляет собой имя родительских ветвей. Например, доменное имя server1.suds.com идентифицирует хост server1 внутри домена suds, который в свою очередь находится в домене com.

Рисунок 1.
Как указывается в RFC 1034, серверы DNS упорядочиваются в виде опрокинутого дерева, где единственный корневой узел расположен вверху. Вся структура имен доменов в целом известна как пространство имен доменов.

Верхние ветви, связанные с корневым доменом ".", называются доменами верхнего уровня. Примерами доменов верхнего уровня могут служить .gov (правительственные учреждения), .mil (военные структуры), .com (коммерческие компании), .edu (образовательные институты), .org (некоммерческие организации), .net (сетевые сообщества) и .int (международные структуры). Некоторые домены верхнего уровня, такие как .us и .ru, образуются в соответствии с географическим принципом, благодаря чему необходимые структуры доменов могут быть созданы внутри данной страны или региона.

Домены второго уровня отождествляют имя лица или организации внутри данной ветви домена верхнего уровня. Например, mfi.com определяет имя домена mfi внутри домена .com. Дальнейшая детализация производится с помощью имен поддоменов, таких как whiz.mfi.com. Эти поддомены служат для идентификации подразделений или групп внутри включающего домена.

Данная методология может использоваться также для идентификации конкретных хостов и таких ресурсов, как proserver.whiz.mfi.com., где конечная точка "." указывает, что это полное доменное имя (Fully Qualified Domain Name, FQDN). FQDN начинается с корня и продолжается полным и исчерпывающим доменным именем. (Иерархия имен доменов читается справа налево, при этом домен верхнего уровня находится справа, за ним следуют имена поддоменов, а оканчивается запись именем хоста.)

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

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

Серверы имен получают запросы от клиентских приложений DNS (resolver). В среде TCP/IP эти приложения взаимодействуют с сервером для передачи общего запроса о поиске адреса или обработки одного из вариантов задачи определения имени/адреса. При получении и выполнении запроса данным сервером имен он узнает информацию о пространстве имен доменов и кэширует ее для последующего использования. Поэтому при получении сервером имен другого запроса, на аналогичный которому он уже отвечал, он предоставляет информацию непосредственно из своего собственного кэша, сокращая время отклика.

Кэширование данных производится на ограниченный период времени (Time-to-Live, TTL), измеряемый в секундах. Это значение определяет срок жизни, при превышении которого данные выходят из употребления. По истечении этого срока сервер имен запрашивает обновленные данные DNS от своего официального сервера. Для систем, в которых изменения имен доменов и IP-адресов внутри зоны происходят нечасто, значение TTL может быть задано равным нескольким дням. Системы с быстро меняющимися зонами должны обновляться через несколько часов или минут. Очевидно, что зоны с чрезвычайно коротким сроком TTL порождают гораздо больший сетевой трафик, чем системы со статичной конфигурацией. В сетях, где имеются и серверы DHCP, и серверы DDNS, период кэширования должен быть достаточно коротким, чтобы измененные назначения IP-адресов имели практический смысл.

Но DNS стала решением проблем, связанных с числовым представлением адресов в ранней Internet, то в последнее время она столкнулась с определенными ограничениями. Разработанная для поддержки относительно прямолинейного определения IP-адреса по имени хоста в средах со статической IP-адресацией, DNS оказалась не в состоянии удовлетворить потребности современных динамических систем IP-адресации.

DHCP (определенный в RFC 1541) представляет собой механизм, с помощью которого IP-хосты могут запрашивать определенную конфигурационную информацию, в том числе динамически назначаемые IP-адреса во время начальной загрузки и регистрации. Динамическое назначение адресов более эффективно в средах, где настольные или портативные ПК часто добавляются или перемещаются внутри сети, так как у администраторов отпадает необходимость отслеживать адреса конкретных клиентов.

Однако если спецификация DHCP обеспечивает механизм для преодоления административных проблем, связанных с фиксированными IP-адресами, она не предоставляет никаких средств для передачи информации о назначенных IP-адресах в DNS, чтобы последняя могла модифицировать FQDN и соответствующие IP-адреса хоста (в записях о ресурсах A и PTR). Такая несовместимость создает ситуации, когда данные в таблице поиска DNS не совпадают с недавно назначенными IP-адресами в таблице IP-адресов DHCP.

Из-за того, что стандарт DHCP разрабатывался без учета модификации DNS, механизм обновления соответствующих имен хостов и адресов еще предстоит создать. RFC 2136 Пола Викси и проект стандарта Internet Якова Рехтера "Взаимодействие между DHCP и DNS" (draft-ietf-dhc-dhcp-dns-04.txt, май 1997 г.) стали исходной точкой для разработки решений проблемы такой фундаментальной несовместимости DHCP и DNS. (Дополнительную информацию о взаимосвязи между DHCP и DNS смотри в статье "DHCP и DNS: динамический дуэт" в октябрьском номере журнала LAN.)

При получении клиентом DHCP нового IP-адреса серверы DNS должны произвести две различные транзакции: модификация FQDN в записи о ресурсах клиента и модификация адреса

PTR в записи о ресурсах. Рехтер указывает, что, теоретически, реализация DNS может использовать либо клиент DHCP, либо сервер DHCP для выполнения какой-то одной или обеих процедур модификации. Его проект стандарта предлагает две рабочие схемы. Согласно первой, клиент DHCP модифицирует запись о ресурсе "A", а сервер DHCP - запись о ресурсе PTR; согласно второй, сервер осуществляет обе модификации.

В динамической среде DHCP и DNS ставят определенные задачи в области защиты. Например, для обслуживания IP-адресов и модификаций имен хостов в динамической среде серверы DHCP и DDNS должны по определению быть открыты для доступа клиентским системам. К сожалению, это дает хакерам лазейку для атаки системы. Согласно своим базовым RFC, и DHCP, и DNS не имеют механизма клиент-серверной идентификации, в результате чего используемые ими процедуры модификации становятся уязвимы для атак по методу подмены. Новые стандарты ликвидируют недостатки защиты в исходной спецификации DHCP и DNS.

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

Недавно Дональд Истлейк, главный системный инженер в CyberCash написал два предложения относительно способа предотвращения атак по методу подмены. RFC 2065 вводит записи о защите ресурсов в рамках спецификации DNS, причем идентификация запросов о модификации осуществляется с помощью криптографических цифровых подписей. RFC 2137 описывает механизмы использования таких подписей в процессе обновления DDNS.

Как правило, современные реализации DNS базируются на BIND. В мае 1997 года Internet Software Consortium выпустил версию 8.1.1 этого комплекта приложений, причем она стала первой реализацией RFC 2136 с предложением по стандарту DDNS. Новая версия, предназначенная для сред Unix, поддерживает также оповещения об изменениях в DNS согласно RFC 1996. Также составленный Викси, RFC 1996 под заглавием "Механизм оповещения об изменениях в зоне" известен как DNS NOTIFY. (Информацию о реализации производителями DDNS, в частности, для NT смотри во врезке