Содержание статьи
«Доменные имена знают все, а моего имени не знает никто», — грустно пошутил мой собеседник. Действительно, DNS кажется такой утилитарной и привычной вещью, что никому и в голову не приходит задаться вопросом о том, как все это создавалось и кто за этим стоит.
До DNS и интернета
Часто со мной говорят так, будто интернет застыл, и больше никто ничего не делает, чтобы его изменить. Это не так. Нам еще многое предстоит сделать, но давайте поговорим об эпохе «динозавров».
Возможно, начало 1980-х и есть то, что люди называют «освоением интернета».
В то время интернет был ARPANET’ом, и до появления DNS адреса хостов хранились следующим образом: существовала таблица, которой управляла организация или SRI. Если вам требовалось занять домен, вы звонили им и говорили: «Привет, можно я возьму вот это имя? Вы можете присвоить ему этот адрес?» И они могли дать вам имя.
- Окончил MIT. Получил докторскую степень в Калифорнийском университете.
- Лауреат ряда премий и наград, в том числе IEEE Internet Award и SIGCOMM Award.
Если возникала проблема, то не существовало механизма, позволявшего его решить, к примеру, ночью. Нужно было звонить в SRI, а те закрывались в пять часов вечера.
Невозможно было получить новый адрес хоста в шесть часов вечера или на Рождество.Поэтому требовалось решение, при котором регистрация доменов происходила децентрализовано, автономно, но все это по-прежнему оставалось бы единой системой. Каждый элемент этой системы должен был иметь возможность взаимодействовать со всеми остальными.
Дистрибуция тоже была крайне важна, ведь она позволяла системе ни от чего не зависеть. Те, кому требовалось быстро развернуть и настроить свою сеть, получили такую возможность. Не было центральной единицы (организации), вынуждающей участников процесса стоять в очереди и ждать, чтобы сделать что-либо.
Представлял ли я, как именно будет использоваться эта система? Конечно, нет. Если бы я мог понять все варианты использования, она не была бы универсальной.
DNS, по сути, система доставки. Ведь вам не нужна система, которая способна доставлять только квадратные предметы или же только круглые. Существует лишь точное ограничение размера. Так, в грузовик можно уместить ровно столько, сколько в нем есть места, а в DNS вместить все, для чего хватает объема данных.
DNS довольно мощная штука. В основе лежит простая идея, к которой люди могут добавить что-то свое.
Я создал изначально универсальную систему, позволяющую хранить любые данные, вместо того чтобы создавать узкозаточенное решение для хранения адресов хостов или только адресов маршрутизаторов.
За прошедшие годы люди многое добавили в систему DNS. Реально работало меньше половины из этих добавлений, зато эта половина оказалась очень значимой.
Хакер #173. Уязвимости Ruby on Rails
Идея
Как появился DNS? Проектом руководил Джон Пастел. В прошлом я уже работал под его началом. Однажды он пришел ко мне в офис и сказал: «Почему бы тебе не поработать над этой проблемой? Есть пять вариантов ее решения».
Итак, существовало пять уже придуманных вариантов решения проблемы. Я изучил их и понял, что ни один мне не нравится. Я должен был найти компромисс между пятью разными идеями.
В итоге я просто создал свое решение, и никто этого не заметил, пока не стало слишком поздно.
- В доменных зонах .com и .net на начало 2013 года насчитывалось порядка 123,1 миллиона активных доменных имен
- Symbolics.com - первый зарегистрированный домен в истории. В январе 1985 года он был присвоен одноименной компании, занимавшейся производством LISP-машин.
- 13 миллионов долларов - за такую сумму в 2010 году был продан sex.com, самый дорогой домен в истории.
Идея пришла из моего прежнего опыта. Когда я учился в Массачусетском технологическом институте, я сотрудничал с Николасом Негропонте. Сейчас он всем известен по проекту One Laptop Per Child, разрабатывающим образовательные компьютеры для детей в бедных странах. Но тогда он еще не был такой крупной фигурой.
В MIT я понял, как заставить несколько компьютеров работать вместе. То, что сейчас назвали бы облачной вычислительной системой. Несколько компьютеров, связанные между собой с помощью дополнительного оборудования, выполняли задачу, предназначенную для большего компьютера. Это и привело меня к идее распределенной системы из нескольких ресурсов. В таких системах часто нарушалась работа одного из компьютеров, и нам приходилось решать возникавшие проблемы. Этот проект на меня заметно повлиял.
Также я работал в Калифорнийском университете с Дейвом Фарбером над распределенной вычислительной системой, которая объединяла два разных компьютера по сети. Уже тогда сообщения отправлялись не на адрес машины, а на ее имя.
Словом, у меня уже были идеи по поводу присваивания имен в распределенных системах.
В университете я создал ОС для хранения файлов на основе распределенных машин, и мы сделали так, чтобы каждое имя файла состояло из двух больших частей: название папки и название самого файла. Это оказалось ошибкой, ведь при такой записи нельзя было создавать, например, подпапки. В результате я понял, что двух уровней мало, ограничивать их количество в принципе нельзя. В DNS везде лимитирована длина имени, но можно создать столько уровней, сколько войдет в этот огромный лимит.
Многие считают, что мои идеи основаны на тех системах записи имен, которые уже существовали. Но многое все-таки основывалось на моем личном опыте. Скажем, у Xerox в то время была очень мощная система присваивания имен, но у нее было три уровня, фиксированно. Это ошибка, которую я совершил раньше и не хочу повторять.
Еще одна важная идея DNS: всегда нужно иметь резервные серверы. Если один не сработает, остальные будут продолжать выполнять свою задачу. Прежние интернет-протоколы работали так: если что-то не получалось, они просто пытались снова и снова, пока не добивались ответа. Но если хост упал или здание, в котором хост находится, разрушилось при внезапном землетрясении, тогда такой подход не сработает. А вам все равно нужно, чтобы сервисы продолжали работать, несмотря на поломку одного из элементов. Думаю, DNS был одним из первых воплощений этой философии.
Также вам, конечно, знаком почтовый протокол SMTP (Simple Mail Transfer Protocol).Благодаря мне в его названии появилась буква S: simple. До окончания университета я работал над почтовым протоколом. Он тогда назывался MTP, был очень сложным и завязанным на FTP. Я решил, что нужно выкинуть все лишнее, и он превратился в простой почтовый протокол.
Дело в том, что я убежден: создавая что-либо, ты должен сделать это простым и понятным. Можно создавать вещи, которых сам не понимаешь, но это все равно, что обезьяне печатать на машинке. Занимает много времени, а на выходе будет куча ошибок. Суметь создать понятный дизайн важно не только для автора, но и для пользователя.
Поэтому я пытался объяснить первоначальный RFC. Пытался простейшим образом объяснить DNS, считая, что другим людям важно понять его и использовать на других машинах. Теперь он, конечно, стал сложнее, но основные идеи были максимально просты.
Я часто говорю, что DNS похож на здание. Я заложил фундамент и построил первые два этажа. Другие люди продолжили мою работу и построили следующие 20–30 этажей.
Если вы обратите внимание на RFC, я написал около ста страниц RFC, которые стали основой. Не знаю, сколько тысяч страниц я написал после, описывая различные решения на базе DNS и так далее. (RFC - Request For Comments, манифест, описывающий тот или иной интернет-стандарт, прим. ред.)
Разработка
Первый RFC я опубликовал в 1983 году. В 1982 году я окончил университет. До этого я написал кучу RFC, но там не указывалось мое имя, поскольку я еще учился. Так часто бывает в университетах. Так что в 1983 году мое имя впервые появилось под RFC.
Я начал думать об этом еще в 1982 году. Была пара набросков, созданных до публикации RFC. Но первый RFC вышел в 1983-м. Если прочете его, заметите сходство с нынешним DNS. Мы установили его на нескольких различных машинах и многое поняли, поэтому современные реализации ближе к тому, что было опубликовано уже в 1986-м.
На все ушло около трех лет экспериментов. По сегодняшним меркам трехлетний путь от планирования стандарта к его реализации в интернете — совсем неплохо.
По большей части DNS был написан на Pascal и Assembler. Одна из интересных особенностей компьютеров PDP-10 заключалась в том, что это были 36-разрядные машины, использовавшие 7-битную кодировку. В начале мы пытались пользоваться исключительно 8-битными кодировками. Предполагалось, что, когда понадобится работать с другими языками, мы перейдем на юникод. Однако интернет развивался, и появилась куча других кодировок, и процесс заметно затянулся.
Около 300 строк на языке Assembler было написано для частей, которые должны были быть очень быстрыми. Скажем, обращением к базам данных. Первые эксперименты также основывались на сложной структуре сервера доменных имен. Потому что я считал, что скоро мы начнем пользоваться многопроцессорными системами. Серверы доменных имен были в одном процессе, а резолверы в другом, для них были предусмотрены механизмы совместного доступа к памяти. Сейчас такая архитектура используется всеми, потому что у всех есть система с несколькими процессорами.
Первая реализация DNS распространилась широко. С ней работали большинство исследователей и другие пользователи ARPANET, что было очень важно в то время.
А потом PDP-10 вышли из употребления. И люди постепенно перешли на систему UNIX, в частности версия от университета Беркли (BSD), и начали пользоваться реализацией DNS под названием BIND. И многие до сих пор используют опенсорсные варианты BIND.
То, что DNS был установлен на первых версиях UNIX, помогло его распространению. К 1988 году почти каждая операционка должна была иметь ПО для IP/TCP и DNS, чтобы оставаться конкурентоспособной.
Всегда важно, чтобы технология решала какую-то проблему.
К примеру, когда-то существовало пять или шесть различных типов адресов электронной почты. Если вы хотели отправить кому-то письмо, нужно было либо использовать тот же тип, либо понять, как отослать письмо посреднику, который выполнил бы пересылку.
Необходимо было понимать оба формата, чтобы знать, какой шлюз использовать. Одной из моих работ до окончания университета было определение шлюза для отправки писем из Великобритании в США. Имена выглядели немного похожими на доменные имена, но в Англии они шли в перевернутом порядке. Напоминает их левостороннее движение.
Я работал над этим шлюзом некоторое время и считал его ужасным: людям приходилось разбираться в деталях. В конечном счете мы решили переложить задачу на DNS. Это позволило автоматически отправлять почту.
Мы доработали DNS, чтобы система могла сама это делать. Кто угодно в мире мог получить доменное имя user@domain, находясь в другой системе. Все поняли, что можно или понимать пять различных адресных форматов и то, как их конвертировать, или просто использовать доменные имена для отправки электронной почты. Конечно, юзеры сказали: «То есть я могу ковыряться с кучей разных стандартов, а могу просто использовать один-единственный. Верно, такой у нас „выбор“?».
Сначала новое решение приглянулось людям, интересующимся разработками в области электронной почты. А после стало общим языком для отправки писем. Другие форматы теперь представляют лишь исторический интерес.
DNS давал простой способ получение контента. Так было легче попасть на сайт, легче отправить почту. Вполне естественно, что люди сказали: «Эй, я хочу это!» А когда что-то становится востребованным, другие системы просто отмирают. Существовала конкурирующая система директорий X.500 — международный стандарт, которым пользовались бы все, если бы она могла сама себя организовывать. Первое, что делал DNS, — запоминал имена, так, чтобы можно было найти каждую часть пространства имени, каждого пользователя, все было соединено. X.500 не могла управлять сама собой. Приходилось пользоваться различными конфигурациями, чтобы объяснить ей, как попасть в то или иное место. В DNS все это происходило автоматически. Вы автоматически подключались ко всем. Эти свойства позволили DNS широко распространиться.
Можно спорить об элегантности или остроумности тех или иных протоколов. Но в итоге пользуются простыми и понятными решениями.
О МОНИТОРИНГЕ DNS
Когда я начал работать в Nominum, бизнес-модель компании была следующей: они писали опенсорсный софт (например, bind9) и раздавали его бесплатно. Даже и не знаю почему, но у компании заканчивались деньги.
«Круто, конечно, но в чем здесь бизнес?» — спросил я. И мы начали сотрудничать с операторами связи, вроде Comcast, AT&T и Telstrom. Мы разрабатываем решения на базе DNS, заточенные под нужды этих компаний. Наше ПО обрабатывает до 1,5 триллиона запросов в день, миллионы запросов в секунду. Помню, в 1986 году я думал, что DNS-серверы будут обрабатывать максимум по 100 запросов в секунду.
Наши решения для операторов занимаются мониторингом DNS в их сетях. Скажем, у Comcast миллионы абонентов — и среди них могут оказаться злоумышленники. Провайдеру приходится защищать свою сеть как от внешних угроз, так и от внутренних.
С мобильными сетями все еще интереснее. Допустим, на десктоп еще можно поставить антивирус. Но как быть с мобильными устройствами? Решения на уровне DNS позволяют не только выявить, скажем, спам-активность, но и блокировать ее. Конечно, это не вылечит зараженные устройства, но все равно лучше, чем ничего. Сети, способные сами себя анализировать и автоматически устранять возникающие проблемы, — это очень интересно.
Безопасность
Было ошибкой не добавить защиту DNS на начальном этапе. Когда я говорю «на начальном этапе», я имею в виду 1983 год. Нам стоило добавить защиту и в 1990-м. Но мы, к сожалению, пришли к этому только сейчас.
Я мог бы взять вину на себя, но я предлагал добавить защиту еще в те годы, когда был простым научным сотрудником. Мое руководство сказало: «Хватит уже ковыряться с DNS, тут больше нечего делать». Это, конечно, было до того, как DNS стал применяться в телефонных сетях, до того, как Интернет вырос до нынешних масштабов. И я не могу взять на себя всю вину. Думаю, если бы раньше у нас была возможность, мы решили бы многие проблемы безопасности из тех, что существуют сейчас.
Сейчас у нас есть технология DNSSEC, полагаю, она будет набирать популярность. Мы собираемся использовать ее для высшего уровня. К примеру, люди обращаются к DNS для защиты данных, которыми обмениваются операторы. Речь идет о BGP и о том, как они обмениваются данными, о таблицах маршрутизации (им нужно ее проверять). Например, я оператор сети, я отвечаю за эту сеть, и если могу ее проверить, то я сумею избежать ряда вещей, вроде «плохих данных» BGP, которые могут отправить что-то в Китай. Полагаю, DNSSEC будет использоваться для решения подобных проблем все чаще и чаще.
DNS — еще один способ передачи секретной информации. DNSSEC — способ передачи документов, противоположных инфраструктуре X.501. Мы стараемся сделать вещи доступными для наших клиентов, упростить им движение вперед.
Но существует и другая проблема: когда в вашей системе все двери без замков. Сейчас вы ставите замки на двери, и люди вынуждены привыкать носить с собой ключи. А что, если заперты те двери, которые не должны быть заперты?
Многие люди понимают систему. Это одна из вещей, которые я помню с первых дней DNS. DNS был глобальным, он позволял создавать столько адресов, сколько захотите, столько частей данных, сколько хотите, привязанных к любому имени. У моего ПО было место для одного адреса, но как мне справиться с двумя? И люди тратили время, пытаясь понять, как это сделать. Когда представляешь новый концепт, ты должен заставить его работать со старым.
Тогда мы тратили много времени, поскольку соединение распадалось на части. Сейчас надежность куда выше и можно достучаться до почти любого узла в Интернете. Мы потратили много времени на выстраивание структур соединения. Сейчас это уже не важно. Сегодня мы имеем дело с переходом от IPv4 кIPv6, с возможностью перевода с одного на другой. А через двадцать лет и вся эта работа станет неважной. Все будут двигаться дальше.
О современном интернете
Некогда ходило много споров, поскольку доменами верхнего уровня по интернациональному стандарту должны были стать коды стран. Но кто-то считал, что доменами верхнего уровня должны стать просто провайдеры, то есть имена ISP, AT&T или MCI. Они находили это прекрасной идеей, потому что тогда смогли бы контролировать своих клиентов. Я счел, что технически мы должны реализовать и то и другое.
Было неправильно ограничивать выбор. Я был убежден, что у многих стран было право и власть сказать: «У России должно быть собственное доменное имя. У Китая должно быть собственное доменное имя. У США...». Я хотел дать возможность каждой стране иметь собственный домен верхнего уровня, которыми они управляли бы по своему усмотрению.
Единственная причина существования зоны .com — у меня вышел спор с представителем правительства. Они считали, что .com — это глупость, никто не будет им пользоваться. Тогда я спросил: «Если никто не будет им пользоваться, то какая разница? Мы сделаем его, а если он никому не понадобится, то уж точно никому не принесет вреда». Но правительство тогда немного ошиблось насчет популярности .com :).
Почти везде в мире есть DNS-фильтры, поскольку почти все провайдеры фильтруют DNS. Где-то меньше, где-то сильнее. Вопрос уже скорее в том, насколько серьезна фильтрация в каждом отдельном случае.
По этому поводу я хотел бы сказать две вещи. В первую очередь, как пользователь, я хотел бы иметь DNS-фильтры, чтобы случайно не попасть на сайты с вредоносным ПО. Мы живем в мире, где при нажатии на ссылку «плохого» веб-сайта наш компьютер может заразиться. Это опасно. Также я хотел бы видеть фильтр сайтов с плохой репутацией, чтобы случайно не попасть и на них.
Но я считаю, что процессы фильтрации должен контролировать сам пользователь. Я сам должен решать, могут ли мои дети поиграть в Minecraft вместо домашней работы или нет. Но и правительство тоже хочет контролировать все это.
Не стану говорить, как должна поступать Россия. Я пытался подсказать США, как им нужно вести себя в данном вопросе, но меня не послушали. Не знаю, с чего они должны были решить, что я прав на сто процентов, так что тем более не могу говорить о другой стране.
Для одного нашего клиента в Австралии мы сделали следующее: взяли список Интерпола «500 худших сайтов» и поставили фильтр для них. Если вы, как австралийцы, захотите защитить свой личный или общественный сервер, вы можете защитить себя от 500 худших сайтов. Но при желании эту защиту можно не использовать. Люди могут сами решать, чего хотят, и хорошо, если они понимают техническую сторону дела. Но ведь никто не рассказывает людям о технической стороне, никто не говорит им, что сделали другие клиенты.
Мы не пытаемся влиять на политику. Мы просто хотим, чтобы люди понимали технологии. И лично я не отказался бы от фильтра для моего собственного интернет-подключения.
