DNS – от технологии к сервису

Павел Храмцов

Из истории DNS и SLA

В далеком 1971 году Пегги Карп (Peggy Karp) решила, что запоминать номера компьютеров в сети сложно, а потому им нужно дать символьные обозначения. В результате появился документ RFC-226 (STANDARDIZATION OF HOST MNEUMONICS) и широко известный атрибут каталога /etc в Unix-системах и не только – файл HOSTS (в ранних версиях NIC SRI[1] – HOSTS.TXT).

Содержание файла было небольшим – 20 хостов с номерами и именами (см. таблицу 1).

Таблица 1. Содержание файла HOSTS.TXT из документа RFC-226

Документ был опубликован 20 сентября 1971 года. До 3 ноября принимались возражения, дополнения, замечания, а с 8 ноября предполагалось, как бы пафосно это ни звучало, внедрение этого новшества.

К слову сказать, 12 октября того же года вышел обновленный документ. В нем было уже 44 хоста, уточнялся формат файла и разъяснялся механизм конструирования имен. Первая дистрибуция файла HOSTS состоялась в 1972 году.

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

К этому моменту, кстати, еще не появились протоколы стека TCP/IP, и имена вводились для использования в программе удаленного доступа (терминала) Telnet, а не для записи имен хостов в адресах электронной почты, как в последующих документах. Тем не менее, с этого момента в именовании компьютеров будущего Интернета появилась централизация.

А еще в неявном виде появилась услуга, которой до этого времени не было – ведение централизованной базы доменных имен. Файл HOSTS.TXT по существу является предтечей современных реестров доменных имен.

Раз появилась услуга, то появился и ее поставщик в лице Пегги Карп и ее коллективный потребитель в лице администраторов хостов.

Сначала для дистрибуции файла HOSTS.TXT использовали BBS (Bulletin Board System) Tenex. Затем файл стали получать по ftp из архива NIC SRI. Обновления в файл вносили один или два раза в неделю. Довольно часто изменения запаздывали, содержание было неактуальным, что вызывало нарекания[2].

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

В сфере телекоммуникаций первые SLA (Service Level Agreement, дословно переводится как «Соглашение об уровне обслуживания (оказания услуги)») появились в конце 1980-х. Их стали включать в сервисные контракты операторы фиксированной связи.

SLA, в первую очередь, – это соглашение между поставщиком и потребителем услуги. Оно, с одной стороны, предоставляет потребителю сервис заданного качества (качество определяется числовыми параметрами сервиса, определенными в SLA), а с другой, защищает поставщика услуги от необоснованных требований и претензий потребителя. К слову сказать, кто тут в большем выигрыше – это большой вопрос. Обычно сервис, предоставляемый по договору, частью которого является SLA, стОит гораздо дороже аналогичного, у которого в договоре на его предоставление раздела SLA нет.

Кроме того, в SLA указываются не только технические параметры услуги, но и прочие параметры обслуживания, например, время реакции клиентских служб на запросы клиентов или/и время устранения неисправностей. Также услуга может относиться к категории высокой доступности, когда время плановых профилактических работ (ППР) включено в учет доступности услуги, или, наоборот, существует согласованный график таких работ и время ППР в расчет доступности не включено.

Но вернемся к сервису DNS. Соглашения об уровне обслуживания не было в 1980-е годы даже на уровне сервиса реестра доменных имен. Собственно, его и не могло быть, т.к. поставщика услуги и потребителя услуги в коммерческом понимании тогда не существовало, как, впрочем, и самого Интернета и системы доменных имен в привычном смысле.

Система доменных имен (Domain Name System – DNS) как понятие, спецификация и пробная реализация этой спецификации была разработана по контракту с DARPA в 1983 году[3]. Она пришла на смену HOSTS.TXT. Сделано это было в рамках проекта ARPANET Полом Мокапетрисом (Paul Mockapetris) под руководством Джона Постела (Jon Postel).

По воспоминаниям Мокапетриса[4], Постел поручил ему несколько иную задачу – свести пять различных предложений по улучшению работы с HOSTS.TXT к некоторому компромиссу. Среди них было как минимум три готовые системы: IEN116, Xerox Reepvine и Clearinghouse systems.

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

Первое программное обеспечение DNS появилось в 1983 году. Это был сервер «Jeeves» (отсылка к персонажу новелл сэра Пе́лама Гре́нвилла Ву́дхауса[5]), написанный Полом Мокапетрисом. Позже былнаписан DNS-сервер для Unix-машин, The Berkeley Internet Name Domain (BIND) package.

С 1983 по 1987 год ARPANET была тестовой площадкой для новой технологии. В 1987 году появились классические стандарты DNS – RFC-1034 (Domain Names-Concepts and Facilities) и RFC-1035 (DomainNames-Implementation and Specification), которыми разработчики ПО для сервиса DNS пользуются до сих пор.

Наличие контрактов с DARPA, а позже с NSF (National Scientific Foundation) не подразумевали каких-либо соглашений об уровне предоставления услуг. Это были исследовательские контракты, в которых главным результатом была разработка технологий. Собственно, в это время и начались трения между «заказчиком» и «исполнителем». Дух исследования преобладал над качеством, которое и определяется соглашением об уровне предоставления услуги.

Все должна была изменить приватизация Интернета. 30 апреля 1995 была отключена магистраль NSF, что поставило точку в приватизации инфраструктуры. Но оставалась еще система доменных имен, а точнее, порядок управления этой частью информационной инфраструктуры.

Для того, чтобы оценить, насколько DNS была скорее исследовательским проектом, чем коммерческим предприятием, следует вспомнить историю «тестовой смены» корня, которая произошла в 1998 году[6].

К тому времени уже вовсю шли баталии вокруг коммерциализации доменных имен. Регистрация имен по $100 за имя в Network Solution Inc многим, в первую очередь, в США, не давала покоя. Администрация Клинтона была озабочена экономическим рывком за счет интернет-технологий. Уже готовилась реформа, в результате которой появится ICANN. И вот на фоне этой суеты Джон Постел решил провести «тест».

К тому времени primary DNS корневой зоны управлялся NSI[7] (A сервер). Остальные авторитативные серверы корневой зоны (Secondary DNS) копировали с него эту зону и далее отвечали на запросы кэширующих серверов, тем самым поддерживали процедуру разрешения доменных имен в Интернете.

Джон Постел в январе 1998 года попросил Джима Кода и Пола Викси (Paul Vixie) развернуть реплику primary DNS в ISI[8]. 28 января 1998 года Джон Постел направил администраторам восьми авторитативных серверов корневой зоны, которые не были в зоне прямого контроля администрации США, письмо с указаниями получения корневой зоны не с А-сервера NSI, а с B-сервера ISI.

Айра Магазайнер (Ira Magaziner), который отвечал в администрации президента Клинтона за реорганизацию Интернета, после переключения серверов был довольно быстро извещен службой безопасности о том, что авторитативные серверы DNS перенаправлены[9] с А-сервера на В-сервер. Он связался с Постелом и руководством USС и пообещал проблемы не только Джону Постелу, но и университету в целом, если Постел не вернет все в исходное положение.

Это была рекомендация, которую Джон Постел не мог не выполнить. Считается, что определение действий Постела администрацией президента США как «тест» системы DNS было способом «сохранить лицо» в данной ситуации для такого гуру Интернета как Джон Постел.

Возможно, что демарш Постела был реакцией на действия администрации президента США, которые привели к тому, что 18 сентября 1998 года была учреждена ICANN (Internet Corporation for Assigned Names and Numbers), и ее устав был зарегистрирован 30 сентября 1998 года[10].

С момента появления ICANN в системе доменных имен появились «хозяйствующие субъекты» (business entities): регистратуры, независимые регистраторы, операторы реестров, операторы DNS-инфраструктуры, депозитарии и резервные операторы регистратур.

Т.е. появились коммерческие услуги и компании, которые эти услуги оказывают. И с этого момента начался отсчет формирования соглашений об уровне предоставления этих услуг. Давайте же совершим краткий исторический экскурс в историю управления IT-услугами. Точнее, мы остановимся только на одном аспекте этого управления, а именно на соглашении об уровне предоставления сервиса или Service Level Agreement (SLA).

Корневая зона и домены верхнего уровня и SLA

Требования к параметрам сервиса DNS для доменов верхнего уровня и корневой зоны появились далеко не сразу. Первый документ на эту тему был разработан в виде RFC-2010[11] в 1996 году, т.е. до появления ICANN.

Чем примечателен этот документ? В нем определены основные технические параметры и требования к времени реакции технического персонала (администратора сервера DNS) на запросы, т.е. типичный набор требований SLA уже наличествует.

Производительность сервера определялась в 1200 запросов в секунду (qps), что по современным меркам довольно скромно, а вот время ответа на запрос должно было быть не более 5 ms, что и по современным меркам очень хорошо. Современный SLA для new gTLD, например, требует время отклика для транспорта UDP не более 500 ms.

В документе, правда, по поводу времени отклика есть оговорка, что сеть растет быстро и требование производительности может быть увеличено до 2000 qps, но при этом желательно сохранять задержку с ответом в 5 ms.

Интересно, что требование 5 ms на ответ в 1996 году характеризует размер сети, в которой такое время отклика было достижимо: это норма для локальной сети, но не для сети, распределенной по всем континентам.

При этом время реагирования администратора по электронной почте на запросы, связанные с проблемами функционирования сервера, не должно было превышать 24 часов.

Позже, уже в 2000 году, по рекомендациям RSSAC (Root Server System Advisory Committee) требования RFC-2010 были заменены на требования RFC-2870[12]. Из документа убрали производительность и время отклика и ввели требование поддержки DNSSEC и регламенты проведения плановых профилактических работ (ППР), а также сняли требование применения ПО, рекомендованного командой primary DNS. В 2014 году RSSAC опубликовали проект документа «Servers Expectation of Root Servers»[13]. В этом документе появилось понятие «доступность сервиса», но у него еще отсутствовали конкретные параметры. В основном речь шла только о регламентах, которые должны соблюдаться командами root-серверов. Параллельно был опубликован проект документа «Measurements of the Root Server System», который ввел список измеряемых параметров. Документы были приняты в 2015 году и с тех пор регулярно обновляются. В 2020 году в этих документах появилась новация, связанная со временем распространения корневой зоны по root-серверам. За время распространения стали считать время, за которое новую редакцию корневой зоны начинают поддерживать 95% экземпляров root-серверов.  Здесь имеет смысл сделать пояснение, что формально мы имеем 13 корневых серверов по количеству IPv4-адресов и Ipv6-адресов. Но реальных физических и виртуальных экземпляров DNS-серверов, которые выполняют функции корневых серверов (авторитативных серверов корневой зоны), гораздо больше. Каждый адрес – это Anycast-облако географически и типологически распределенных хостов.

В 2022 году RSSAC выпустил документ RSSAC047v2: RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System[14].

Этот документ замечателен тем, что в нем появилась методика расчета доступности сервиса DNS для корневой зоны. В основу методики исследования надежности была положена довольно распространённая модель системы «k из n».

RSSAC рекомендовал использовать для определения необходимого числа root-серверов формулу [1]:

[1] K = [2/3(n-1)];

Где n – общее количество авторитативных серверов корневой зоны;

К – требуемое для надежной работы количество серверов корневой зоны.

В настоящее время n равно 13 и, соответственное, K равно 8.

Рекомендованный порог надежности (доступности) для одного root-сервера (IPv4- или IPv6-адрес) установлен в 96%, соответственно, общая доступность сервиса при таком допущении при расчете по формуле [2]:

[2] A=aⁱ(1-a) ^(n-i);

Где n=13,

k=8,

a=96,

будет равна, соответственно, A=99,999% (пять девяток), что в области телекоммуникаций в последнее время принято считать стандартным уровнем доступности сервиса, который прописывается в SLA.

В этом же документе установлен и порог для времени ответа на запросы root-сервером (IPv4- или IPv6-адрес):

– для UDP этот порог равен 250 ms;

– для TCP этот порог равен 500 ms.

Авторы документа отмечают, что обычно доступно более восьми серверов, следовательно, в этом случае доступность сервиса стремится к 100%, а порог для времени отклика всего сервиса может быть снижен.

Рекомендации по порогам для сервиса системы корневых серверов (Root server system, RSS) RSSACсформулированы следующим образом:

Таблица 2. Рекомендованные параметры уровня сервиса для сервиса авторитетных серверов корневой зоны DNS

RSS Availability – доступность сервиса;

RSS Response Latency – время отклика на DNS-запрос;

RSS Correctness – корректность сервиса (корректность ответов);

RSS Publication Latency – задержка при распространении зоны по серверам.

Однако считать этот документ SLA оснований нет. Это скорее OLA, т.е. соглашение об уровне эксплуатации, т.к. коммерческих договоров у ICANN или PTI[15] с операторами корневых (root) серверов нет.

Приведенный выше подход применяется в программе new gTLD[16]. В спецификации 10, разделе 2 к договору перечислены следующие технические SLA-параметры:

Таблица 3. Service Level Agreement Matrix

Конечно, время отклика на DNS-запрос в исторически первом RFC, посвященном этому вопросу, выглядит гораздо привлекательнее для пользователей DNS, но Интернет большой, и гарантировать ответ в 5 ms на любой DNS-запрос сейчас уже не решаются даже в ICANN. Тем не менее, такие требования от операторов связи поступают время от времени, и современные сервисы публичных DNS-резолверов постоянно к этому стремятся, но это уже тема следующего раздела нашей статьи.

Коммерческие услуги DNS и SLA

Долгое время сервис DNS своим клиентам предоставляли провайдеры подключения к сети Интернет (интернет-сервис провайдеры – Internet Service Provider, ISP). В первую очередь речь идет о предоставлении клиенту DNS-резолвера, т.е. программы, которая выполняет в Интернете поиск соответствия между доменными именами и адресами (классический случай). Адрес резолвера, как и адрес устройства пользователя, автоматически настраивается при подключении к сети провайдера. Именно резолвер имеют в виду в руководстве конечного пользователя ISP, когда ведут речь о сервере доменных имен.

В договоре на оказание услуг подключения к Интернету у российских ISP упоминания о DNS нет совсем. Соответственно, нет и SLA для этого сервиса. Единственным исключением является «Билайн», и то только потому, что «Билайн», хоть и формально, является регистратором доменных имен. Однако и здесь конкретных исчисляемых параметров, а также дисконтов при нарушении условий SLA не указано. В конце концов основная услуга ISP не DNS.

Если раньше (до Google DNS) кто-то регистрировал собственный домен, то найти DNS-провайдера было проблематично. Обычно либо поднимался собственный авторитативный сервер для своих доменов, либо использовались услуги DNS-сервиса хостинга. При наличии собственного сервера главной задачей было найти второй сервер для доменов второго уровня в .su и .ru.

Провайдеры хостинга предоставляют SLA на услугу хостинга, и для российских компаний значение доступности DNS сейчас находится где-то в диапазоне от 99,5[17] до 99,9[18].

Но есть в мире компании, которые специализируются на оказании услуг DNS – DNS дорос до того, чтобы стать коммерческой услугой. Как здесь обстоят дела с SLA? Насколько зрелой можно считать эту услугу?

В таблице 4 приведен сводный список параметров SLA ведущих DNS-провайдеров.

Таблица 4. Параметры SLA ведущих DNS-провайдеров

*Дисконт – это скидки провайдера сервиса для клиентов в соответствии с фактической доступностью сервиса.

В этом сводном списке контролируемых параметров услуги DNS следует обратить внимание на несколько моментов:

• во-первых, в отличие от DNS SLA для доменов верхнего уровня, здесь не обозначены ограничения на время отклика для конечного клиента или специального пробника, который измеряет доступность сервиса;
• во-вторых, не определена методика проверки доступности, а сам расчет является классическим расчетом времени доступности сервиса;
• в-третьих, сервис считается доступным, если получен ответ хотя бы от одного из авторитетных серверов зоны клиента.

Стоит обратить внимание на последнюю колонку (таблица 4). Это измерения доступности сервиса независимой службой DNSperf[19] на момент написания статьи.

Любопытно, что все компании, кроме Godaddy, не соблюдают свой SLA и должны предоставлять дисконт от ежемесячного платежа. Т.е., видимо, сбои в обслуживании клиентов есть, но так как «бодаться» с клиентами накладно, то проще предоставить дисконт на минимальную сумму при появлении рекламации, чем идти в суд. Это полезно и для маркетинга услуги: таким образом можно управлять скидками без ущерба имиджу компании.

С точки зрения зрелости сервиса эти «недостижимые» 100% доступности говорят о высокой технологичности, осознанном риске и соответствии стандартам других услуг сектора услуг телекоммуникаций, где доступность сервиса в последнее время обычно определяют в 99,999%

Вместо заключения

В 2023 году технологии DNS исполнится 40 лет. Она родилась тогда, когда Интернета не было не только в виде сети веб-сайтов, но в виде социальных сетей. Даже технология TCP/IP не была внедрена.

Сейчас на базе DNS предоставляется целый спектр коммерческих услуг, как традиционных для этой технологии, так и новых. Наличие подробных соглашений об уровне предоставления этих услуг говорит о технологической и коммерческой зрелости DNS.

В диаграмме «Хайпа» Гартнера (Кривая Гартнера, Gartner Hype Cycle[20], рисунок 1), которая описывает цикл зрелости IT-технологии, выделяют несколько этапов[21]:

• технологический триггер (англ.technology trigger) — появление инновации, первые публикации о новой технологии;
• пик чрезмерных ожиданий (Peak of Inflated Expectation) — от новой технологии ожидают революционных свойств, технология, благодаря новизне, становится популярной и предметом широкого обсуждения в сообществе;
• избавление от иллюзий (Trough of Disillusionment) — выявляются недостатки технологии, а утеря новизны не способствует восторженным публикациям, в сообществе отмечается разочарование новой технологией;
• преодоление недостатков (Slope of Enlightenment) — устраняются основные недостатки, интерес к технологии медленно возвращается, технология начинает внедряться в коммерческих проектах;
• плато продуктивности (Plateau of Productivity) — наступление зрелости технологии, сообщество воспринимает технологию как данность, осознавая её достоинства и ограничения.

Рисунок 1. Кривая зрелости IT-технологии Гартнера.

Кривая Гартнера – это руководство по вкладыванию или сворачиванию инвестиций в те или иные IT-направления.

В 1983 году DNS как технология и услуга находилась в области технологического триггера. Пик популярности пришелся на период с 1995 по 2000 годы. Скандалы вокруг Network Solution Inc, образование ICANN, пузырь доткомов пришлись на этот период. Пик популярности порождает поиск уязвимостей и их устранение, разработку и внедрение DNSSEC, применение DNS в областях, которые раньше в этом не нуждались, например, в мобильной связи. Таким образом, к 2010 году DNS выходит на «склон просвещения» («Slop of Enlightenment» на рис.1).

За 40 лет своей истории технология DNS прошла все стадии зрелости и сейчас находится на «плато продуктивности». Согласно Гартнеру, это означает, что технология широко внедрена, ее место на рынке и области применения хорошо известны. И это также означает, что DNS сегодня не только и не столько технология, сколько зрелый сервис с определенными соглашениями об уровне его предоставления – хотя ряд важных параметров пока еще остаются «за скобками» SLA.

[1] Network Information Center of Stanford Research Institute

[2] https://iconia.com/before_the_dns.txt

[3] https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/mockapetris88.pdf

[4] https://historyofnetworking.s3.amazonaws.com/Paul+Mockapetris+-+Origins+Of+DNS.mp3
[5]
«Just like Wodehouse’s Jeeves guarding access to his master, there is a who;e my of digital doorkeepers patiently and continuously wathching over the internet (unless the are on strike).» The Server: A Media History from the Present to the Baroque
Авторы: Markus Krajewski

[6] https://www.icann.org/en/system/files/files/rssac-023-17jun20-en.pdf

[7] Network Solution Inc

[8] USC Information Sciences Institute (ISI)

[9] https://www.youtube.com/watch?v=yoCfWcd_dFM&t=1813s

[10] https://www.icann.org/en/system/files/files/articles-incorporation-30sep98-en.pdf

[11] https://datatracker.ietf.org/doc/html/rfc2010

[12] https://datatracker.ietf.org/doc/html/rfc2870

[13] https://www.icann.org/en/system/files/files/rssac-001-draft-02may13-en.pdf

[14] https://www.icann.org/en/system/files/files/rssac-047-03feb22-en.pdf

[15] https://pti.icann.org/

[16] https://newgtlds.icann.org/en/

[17] https://www.1gb.ru/services_premium_plan_sla.php

[18] https://timeweb.com/ru/services/hosting/sla/

[19] https://www.dnsperf.com

[20] https://www.gartner.com/en/research/methodologies/gartner-hype-cycle

[21] https://ru.wikipedia.org/wiki/Gartner