Обновленная DNS

Современная система динамической IP-адресации приводит к проблемам с DNS. К счастью, новый стандарт и новая версия BIND модифицируют DNS должным образом.

ЕСЛИ ДОЛГО МУЧИТЬСЯ, ЧТО-НИБУДЬ ПОЛУЧИТСЯ
Предложения по DNS

РЕСУРСЫ DNS
Дополнительная информация

Сегодня вопросы имен доменов и управления 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.

ЗАЧЕМ ПОТРЕБОВАЛАСЬ DNS?

При навигации по Сети в поисках какой-либо новой странички о светлом пиве типа 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.

Верхние ветви, связанные с корневым доменом ".", называются доменами верхнего уровня. Примерами доменов верхнего уровня могут служить .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-адресов имели практический смысл.

ПОТРЕБНОСТЬ В DDNS

Но 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 смотри во врезке "Предложения по DNS".)

BIND был создан в Калифорнийском университете в Беркли (UCB) в качестве реализации спецификации DNS в рамках финансируемых правительством исследований по разработкам в области Internet. Вплоть до версии 4.8.3 BIND разрабатывался университетской группой по исследованию компьютерных систем. Версии 4.9 и 4.9.1 были выпущены Digital Equipment. Начиная с версии 4.9.2 все последующие редакции подготавливались Vixie Enterprise или Internet Software Consortium.

Версия 8.1.1 решает несколько важных проблем безопасности, которым предшествующие версии 4.x были подвержены. Версии BIND до 4.9.6, а также системы DNS на базе старых разновидностей BIND имели дыры в системе безопасности, вследствие которых сервер имен был уязвим для атак с отравленным кэшем. 13 августа 1997 года CERT обсудил доклад (CA-97.22) об уязвимости серверов имен, когда фиктивные данные от удаленного сервера имен предоставляются другому серверу имен, а он в свою очередь хранит вводящие в заблуждение данные в своем кэше. Предоставляя фальшивые имена и адреса хостов, атакующий может нарушить соответствие между именами и адресами, в результате чего данные в сети становятся открыты для сбора, анализа и, потенциально, порчи.

Учитывая подобную уязвимость, пользователям версий 4.x рекомендуется перейти на 8.1.1. Эта последняя редакция обеспечивает более защищенную среду для сервера имен за счет контроля доступа на основе IP-адресов при запросах, обновлениях и зонных пересылках в каждой зоне в отдельности. Новая версия BIND, благодаря более эффективным зонным пересылкам, имеет и лучшую масштабируемость даже в случае, когда серверы обслуживают тысячи зон.

INTERNET - ЭТО BIND?

Недавний доклад CERT касается уязвимости Internet для атак с отравленным кэшем и поднимает вопрос о защите DNS и DHCP в целом. Мы попросили ответить Истлейка и Викси на вопросы относительно того, как последующие версии BIND и DNS будут решать нарастающие словно снежный ком проблемы защиты.

Что касается вышеназванных задач защиты, Истлейк предлагает использовать последние редакции BIND, совместимые с новыми функциями защиты, которые DNS Security (DNSSEC) и RFC 2137 добавили к DDNS. Он напоминает также, что предложения по защите DHCP представлены в IETF.

"Защита DNS имеет несколько аспектов, - говорит он. - Я думаю, что обычному администратору DNS все чаще приходится сталкиваться с проблемой подмены DNS, в особенности если он не использует последнюю версию BIND. С повсеместным внедрением DNSSEC подмена станет практически невозможной".

Викси полагает, что, хотя DNSSEC - шаг в правильном направлении, спецификация не решает многих проблем. "Клиенты не осуществляют сквозное кэширование и проверку. Последний переход от рекурсивного сервера к запрашивающему клиенту является слабым звеном", - считает он.

Помимо вопросов защиты мы попросили Истлейка и Викси прокомментировать, каким образом растущее использование Internet для аудио- и видеоконференций отразится на DNS.

И Истлейк, и Викси озабочены потенциальным непониманием роли DNS в рамках Internet и потенциальным неправильным использованием системы. "DNS это служба имен, а не служба каталогов, - поясняет Истлейк. - DNS ищет только точные соответствия (или полные символы подстановки), в то время как служба каталогов должна обеспечивать множество функций определения приблизительного совпадения, например индексацию SOUNDEX".

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

Оба специалиста выразили мнение, что, хотя имена по типу адресов электронной почты могут использоваться для упрощения соединений при поддержке Internet-телефонов или конференций с применением DNS, другие протоколы типа LDAP или ODBC могут в конечном счете оказаться более эффективной средой для таких предприятий.

Частичный ответ на вопрос, как DNS может использоваться для поддержки усовершенствованных аудио- и видеоконференций на базе Internet, дает RFC 2168 ("Отождествление универсальных идентификаторов ресурсов с помощью системы имен доменов", Р. Даниэль, июнь 1997 года). Он предлагает экспериментальный протокол для новой записи о ресурсах DNS под названием Naming Authority Pointer (NAPTR). Данная запись о ресурсах будет использоваться для отождествления частей универсальных идентификаторов ресурсов (Uniform Resource Identifier, URI). URI - это широкая классификация, включающая как универсальные локаторы ресурсов (Uniform Resource Locator, URL), так и универсальные имена ресурсов (Uniform Resource Name, URN). Хотя и предназначенная для обеспечения независимости от местонахождения, а также для функций обновления и отказоустойчивости при операциях с Web, опция записи о ресурсах NAPTR в спецификации DNS может также использоваться для поддержки универсальных сервисов конференций на базе Internet.

РАСШИРЕНИЯ DNS

С началом процесса стандартизации и с появлением предложений от множества разработчиков приложений IP-управления и DNS/BIND для широкого спектра сетевых ОС будущее DNS выглядит многообещающе. По мере того как все большее число разработчиков Unix модифицируют свои системы в соответствии с новыми стандартами BIND 8.1.1, проблемы защиты будут отступать на задний план. Тот факт, что многие из них предлагают также исключительно надежные продукты для Windows NT, должен снять бремя сомнений с администраторов, связывающих свое будущее с Microsoft.

ЕСЛИ ДОЛГО МУЧИТЬСЯ, ЧТО-НИБУДЬ ПОЛУЧИТСЯ

Предложения по DNS

Повсеместное принятие BIND в качестве стандартной реализации DNS в мире Unix сделало BIND ориентиром для разработчиков в других средах. Предложенные реализации DNS от IBM, Microsoft, Apple, Quadritek и Bay Networks - все они опираются на стандарт BIND (предшествующие версии по отношению к 8.1.1).

Если сравнивать со скоростью разработок на рынке DNS вообще, то Microsoft предлагает усовершенствования для своей Windows NT DNS со значительным опозданием. Выпущенная недавно в виде бета-версии, NT 5.0 имеет Active Directory (модификацию NT Directory Services), ставшую первым экспериментом Microsoft в области Dynamic DNS. Кроме того, по всей видимости, она свидетельствует об отходе от межсетевой службы имен Windows (Windows Internet Name Service, WINS). В базовой документации утверждается, что "Dynamic DNS исключает необходимость в других службах имен Internet, таких как WINS". Чтобы воспользоваться функциями NT 5.0 Active Directory, пользователи Windows 95 должны будут добавить клиентское приложение Active Directory. Системы под управлением NT Server 5.0, NT Workstation 5.0 и Windows 98 будут иметь клиента Active Directory в комплекте поставки.

Любопытно отметить, что во время написания статьи список поддерживаемых стандартов и предложений RFC в NT 5.0 не включал RFC 1996, 2065, 2136 или 2137, хотя они определяют различные функции обновления и защиты DDNS. Если это действительно так и код DNS в NT 5.0 не соответствует этим спецификациям, то команда Билла Гейтса значительно отстает в области защиты и модификации DNS. Учитывая, что продукты других производителей (поддерживающие в настоящее время NT 4.0) уже соответствуют этой спецификации, остается только удивляться, почему Microsoft столь пассивна в разработке динамической защищенной DNS для своей операционной системы, учитывая, что далеко не блестящая поддержка DNS в NT Server 4.0 заставила многих администраторов NT обратиться к поиску альтернативных решений.

Два из них были предложены Software.com и MetaInfo, причем обе опираются на новую версию BIND за номером 8.1.1. Bind for NT предоставляется Software.com бесплатно. Система предназначена специально для малоопытных администраторов. Инсталляция осуществляется с помощью Install Shield, а кроме того, она имеет апплет с панелью управления пользователями и контроля статуса.

Недавно MetaInfo объявила о своих предложениях в области DHCP и DDNS для среды NT на базе BIND 8.1.1. В августе 1997 года компания выпустила свой комплект Meta IP 3.0, включающий Meta IP/DNS, Meta IP/DHCP и Meta IP/Manager.

MetaInfo заявляет, что она стала первым производителем, предложившим DNS для NT на базе последней редакции BIND 8.1.1. Серверы Meta IP DNS и DHCP модифицируют друг друга с помощью базы данных Microsoft Access, обеспечивая все возможности обновления DNS и DHCP даже в смешанной сетевой среде, что позволяет преодолеть присущие NT Server 4.0 ограничения WINS. Meta IP/Manager выполняется как апплет Java, предлагая пользователям межплатформенную поддержку для Unix и NT с помощью одного и того же интерфейса контроля. Система Meta IP имеет также возможности модификации DNS в реальном времени и поддерживает новые стандарты протоколов IPv6, - одной из первых предлагая такую комбинацию возможностей.

РЕСУРСЫ DNS

Дополнительная информация

Сведения о BIND можно найти на сервере Internet Software Consortium Web по адресу: www.isc.org. Информацию о RFC можно получить от Internic в ds.internic.net/rfc/. Проекты стандартов Internet смотрите также на узле ftp Института информационных наук по адресу: ftp://ftp.isi.edu/internet-drafts.