«DNS и BIND»

1. Основы

История системы доменных имен

В семидесятых годах сеть ARPAnet представляла собой тесное сообщество из нескольких сотен узлов. Всю информацию по узлам, в частности необходимую для взаимных преобразований имен и адресов узлов ARPAnet, содержал единственный файл HOSTS.TXT. Известная UNIX-таблица узлов, /etc/hosts, прямо унаследовала свою структуру от файла HOSTS.TXT (в основном с помощью удаления ненужных на UNIX-системах полей).

За файл HOSTS.TXT отвечал Сетевой информационный центр (NIC, Network Information Center) Стэнфордского исследовательского института (SRI, Stanford Research Insitute). В тот период времени единственным источником, распространявшим файл, являлся узел SRI-NIC.1 Администраторы ARPAnet, как правило, просто посылали изменения электронной почтой в NIC и периодически синхронизировали свои файлы HOSTS.TXT с копией на узле SRI-NIC с помощью протокола FTP.

Присылаемые ими изменения добавлялись в файл HOSTS.TXT один или два раза в неделю. Однако по мере роста сети ARPAnet эта схема стала неработоспособной. Размер файла рос пропорционально количеству узлов ARPAnet. Еще быстрее рос информационный поток, связанный с необходимостью обновления файла на узлах: появление одного нового узла приводило не только к добавлению строки в HOSTS.TXT, но и к потенциальной необходимости синхронизации данных каждого узла с данными SRI-NIC.

После перехода ARPAnet на протоколы TCP/IP рост сети стал взрывным. Появился гордиев узел проблем, связанных с файлом HOSTS.TXT:

Нагрузка на SRI-NIC в смысле сетевого трафика и работы процессора, связанных с раздачей файла, приближалась к предельной.

Никакие два узла, описанные в файле HOSTS.TXT, не могли носить одинаковые имена. Организация NIC могла контролировать присваивание адресов способом, гарантирующим их уникальность, но не имела никакого влияния на имена узлов. Не было способа предотвратить добавление узла с уже существующим именем, при том что такое действие нарушало работу всей схемы. Так, добавление узла с именем, идентичным имени одного из крупных почтовых концентраторов, могло привести к нарушению работы почтовых служб большей части сети ARPAnet.

Синхронизация файлов в масштабах быстро растущей сети становилась все более сложной задачей. К тому моменту, когда обновленный файл HOSTS.TXT достигал самых далеких берегов выросшей ARPAnet, адреса отдельных узлов успевали измениться или же появлялись новые узлы.

Основная проблема заключалась в том, что схема с файлом HOSTS.TXT не поддавалась масштабированию. По иронии судьбы, успех ARPAnet как эксперимента вел к моральному устареванию и провалу механизма HOSTS.TXT.

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

Ответственным за разработку архитектуры новой системы стал Пол Мокапетрис, работавший тогда в Институте информационных наук (Information Sciences Institute). В 1984 году он издал документы RFC 882 и 883, в которых описывалась система доменных имен (Domain Name System, или DNS). Эти RFC-документы были обновлены документами RFC 1034 и 1035, которые и являются в настоящее время действующей спецификацией DNS.1 RFC 1034 и 1035 к настоящему времени дополняются многими другими подобными документами, в которых описаны потенциальные проблемы DNS с точки зрения сетевой безопасности, возможные трудности реализации, проблемы административного плана, механизмы динамического обновления DNS-серверов, обеспечение безопасности зональных данных и многое другое.