ICANN vs VeriSign: скандал вокруг Site Finder
15 сентября 2003 года регистратор доменных имен, компания «VeriSign», ввела в зоны .com и .net записи с вайлдкардами (так как в русском языке нет аналога английского слова “wildcard” (по крайней мере, найти мне его не удалось), то здесь и далее, вайлдкардом будем называть групповой символ, использующийся для обозначения комбинации символов, например, «*.*»). Сделано это было для того, чтобы запустить новый поисковый сервис «Site Finder», призванный помочь ошибившимся при вводе адреса пользователям найти нужный сайт. Т.е. при вводе в браузере, скажем, адреса “www.abracadabra-bred.com” (или любого другого несуществующего), пользователь вместо сообщения об ошибке или других действий браузера (например, загрузки браузером поисковой страницы его производителя) в ответ получал поисковую страницу VeriSign с предложением найти интересующий сайт. С одной стороны, забота о пользователе — это, конечно же, всегда хорошо. Но с другой стороны, такое серьезное вмешательство в работу DNS вызвало много нареканий со стороны множества специалистов, во главе с ICANN. Как оказалось, их претензии были вовсе не безосновательными. 19 сентября координационный совет сети Интернет (IAB) опубликовал технический отчет, в котором «по полочкам» разложил все множество возникших из-за внедрения вайлдкард проблем.
официальный комментарий IAB к использованию DNS-вайлдкард
В работе DNS существует множество особенностей, не документированных в стандартах IETF, но от них зависит поведение протоколов и приложений Интернет. Эти особенности являются неотделимой частью сетевой архитектуры, в которой DNS — один из основных «винтиков».
Способы использования вайлдкард, изменяющие эти особенности, известны уже довольно давно.
Недавнее изменение, связанное с добавлением DNS-вайлдкард с А-записями на высоких уровнях дерева DNS показало на практике, что вмешательство в устоявшиеся принципы работы DNS может иметь весьма серьезные последствия. Дальше речь пойдет о том, как работают вайлдкарды DNS и как их необдуманное использование может ухудшить работу как отдельных приложений, так и всего Интернет в целом.
Вкратце, мы выступаем против применения DNS-вайлдкард оператором зоны до тех пор, пока он не будет иметь четкого представления о возможных рисках.
краткий справочник DNS-вайлдкард
Механизм вайлдкард DNS является частью протокола DNS еще с тех пор, как на него были написаны спецификации более 20-и лет назад. Тем не менее, до сих пор можно встретить ярые дискуссии по поводу того, как он должен реализовываться, и как должен или не должен использоваться. В данном разделе мы попытаемся вкратце объяснить читателю принципы работы механизма вайлдкард, но мы также настоятельно рекомендуем обратиться к спецификациям DNS (RFC 1034).
В общих чертах, вайлдкарды DNS — это правила, позволяющие серверу имен синтезировать записи ресурсов DNS на лету. Основной механизм довольно прост, сложности кроются в реализации деталей.
Как известно, основной и в то же время самой часто используемой операцией является простой запрос на записи, удовлетворяющие данному имени, классу и типу. Если для простоты предположить, что все программное и аппаратное обеспечение работает корректно, то подобный запрос приведет к трем возможным результатам:
— success — если система находит соответствие всем трем параметрам, она вернет нужную информацию;
— no data — если система находит соответствие имени и классу запроса, но не типу, она вернет ответ, что такое имя существует, но не существует никакой информации, соответствующей данному типу;
— no such name — если системе не удается найти соответствие данным имени и типу, она вернет сообщение, информирующее о том, что такого имени не существует.
Как правило, соответствия для всех трех параметров должны быть точными. Вот тут-то в дело вступают вайлдкарды.
Запись вайлдкард является особой записью DNS, в которой левая часть состоит из символа «*», например, «*.bar.example». Концептуально, звездочка обозначает одно или несколько слов с левого (наименее значительного) конца имени DNS.
При наличии записей вайлдкард, правила становятся гораздо более сложными. Например, если совпадает класс запроса, нет точного соответствия имени запроса, и ближайшее соответствие имени запроса является вайлдкардом, система синтезирует набор записей ресурсов, соответствующих имени запроса, на лету, рассматривая записи ресурсов в имени вайлдкард так, как если бы они были представлены в имени запроса. Таким образом, если имя вайлдкарда имеет соответствующие типу запроса записи, система вернет эти записи, точно так же как и в случае «успех» (success), описанном выше; в противном случае, система ответит, что имя существует, но не существует никакой информации, соответствующей данному типу запроса, аналогично случаю «нет информации» (no data). Т.е. ответ будет идентичным нормальному ответу «успех» для имени запроса. В итоге получается, что посылавший запрос не сможет определить по полученным результатам, что это результаты выражения вайлдкард.
Следует отметить, что при соответствии вайлдкард, случай «нет имени» (no such name) не может произойти, так как соответствие вайлдкард сводит вероятность его возникновения к нулю. Заметьте также, что для определения вайлдкард подходят только имя запроса и тип запроса: любой тип записи может соответствовать вайлдкарду, вне зависимости от того, соответствует ли тип записи типу запроса.
проблемы с записями вайлдкард
Одним из широко известных недостатков вайлдкард является то, что записи, содержащие их, плохо сказываются на использовании DNS, зависящем от ответов типа «нет имени». Список подобных применений достаточно велик и будет рассмотрен позже.
Еще одно неудобство вытекает из того, что метка вайлдкард будет соответствовать вообще всему, при условии, что не-вайлдкард имя внутри зоны является более близким соответствием имени запроса, чем вайлдкард. Это не кажется большой проблемой, но дело в том, что многие протоколы или соглашения предусматривают в некоторых случаях использование меток с левых (наименее значительных) концов имен в записях для различения записей, ассоциированных с различными сервисами, вместо использования разных типов записей. То есть, в этих случаях, различные службы используют один и тот же тип записи, а клиенты (или пользователи) должны использовать определенное имя, чтобы получить доступ к необходимой службе. Это относится к системе, описанной в специальных соглашениях (RFC 2219), например, www.foo.example и механизмам вроде типа записи SRV (RFC 2782), в которых схема присваивания имен является частью протокола. Когда имена этого типа закрываются вайлдкардом, как, например, запись адреса, названная, *.bar.example, подобный вайлдкард выдаст одинаковый адрес, несмотря на имя сервиса, закодированное в имени запроса. Так, ftp.foo.bar.example, mail.foo.bar.example, ntp.mail.bar.example будут заканчиваться на одну и ту же синтезированную запись адреса. Эта проблема становится еще серьезней в случае с SRV, так как имена вроде _finger._tcp.foo.bar.example являются частью протокола и также SRV записи содержат номера портов TCP и UDP. То есть клиент не будет знать, к какому хосту подключаться, и, вдобавок, к какому порту. Единственный способ избежать проблем с записями такого типа — это добавить явные записи для подобных имен в DNS.
Наконец, два вышеперечисленных фактора (эффект «соответствие всему» и плохое взаимодействие со всем, зависящим от ответов «нет имени») пересекаются с нормальными предсказуемыми человеческими ошибками, тем самым их действие распространяется далеко за установленные рамки. Точнее говоря, действие вайлдкард ограничено одной зоной, поскольку, по определению, записи вайлдкард не соответствует ни одно имя, реально не существующее в зоне, и, соответственно, не соответствует любое (не вайлдкард) делегирование порции именного пространства от родительской зоны дочерней.(NS-записи вайлдкард, теоретически возможны, но из-за их неестественной семантики их применение лучше ограничить дотошным тестированием DNS-софта). На первый взгляд может показаться, что администратор зоны может спокойно использовать вайлдкарды без беспокойства по поводу возможных эффектов в дочерней зоне. К сожалению, это не так. Дело в том, что пользовательские интерфейсы тесно взаимосвязаны с DNS-именами, а пользователям, как и всем людям свойственно ошибаться. Таким образом, делегирование зоны bar.example предотвратит влияние вайлдкард записи *.example на пользователя, написавшего по ошибке вместо foo.bar.example foi.bar.example, но в то же время не предотвратит, если пользователь напишет foo.bat.example. То есть с точки зрения пользователя, некоторые эффекты вайлдкард передаются от родительской зоны к дочерней. Это не представляет собой серьезной проблемы в случае, если родительская и дочерняя зоны принадлежат одной организации, но может вызвать большие сложности в случае, когда зоны ассоциированы с различными организациями, интересы которых не совпадают.
Описанное выше — это еще не полный список возможных проблем. Даже после двадцати лет опыта работы с DNS, эффекты от неправильного использования вайлдкард могут быть неожиданными, так как небольшие, но фундаментальные изменения, которые они вносят в правила разрешения имен, имеют возможные (а иногда и явные) негативные последствия для уже установленного ПО, использующего DNS.
По этим причинам использование вайлдкард было ограничено небольшим числом случаев, когда их применение полностью осознанно. Так, практически все применение вайлдкард ограничено записями MX. Так как записи MX используются для доставки электронной почты, вайлдкард записи MX довольно безопасны, особенно учитывая тот факт, что, как правило, организация, владеющая DNS-именем электронной почты, также владеет и остальной частью делегируемого дерева, и, тем самым, MX записи находятся в зонах, где эффекты их присутствия не пересекают границ владений разных организаций.
/* В наших реалиях возможен еще вариант использования вайлдкардов в «DNS-зоне для бедных» — когда у вас есть один хост с одним IP-адресом, и все сервисы крутятся на нем. — прим.ред */
Принимая во внимание рассмотренные выше проблемы, можно сделать вывод, что использование вайлдкард с типами записей, влияющими более чем на один протокол, должно производится с большой осторожностью. С еще большей осторожностью следует относиться к случаям, когда эффекты от использования вайлдкард могут пересекать границы владений разных организаций, и уж совсем аккуратно следует относиться к применению вайлдкард, если эффекты от их использования могут влиять на несколько протоколов и пересекать границы владений разных организаций.
базовые принципы архитектуры интернет-сетей
Для чтения дальнейшей части статьи желательно помнить о следующих основных принципах разработки архитектуры, которые служили Интернету в течение многих лет:
Принцип надежности: «Необходимо подходить консервативно к тому, что делаешь и быть либеральным к тому, что предлагают другие».
Принцип наименьшей неожиданности: «Программа всегда должна вести себя таким образом, чтобы быть наиболее предсказуемой для пользователя».
недавно замеченные проблемы с вайлдкардами
Мы имели возможность увидеть нежелательные и труднообъяснимые последствия внедрения вайлдкард в большие домены верхнего уровня. В этом разделе будет рассказано о проблемах, с которыми столкнулись пользователи сети и операторы по всему миру в результате этого внедрения.
В первую очередь необходимо отметить, что с технической точки зрения это было абсолютно законно и не нарушало спецификаций DNS. Тем не менее, мы считаем, что простого соблюдения спецификаций недостаточно, чтобы быть уверенным в том, что приложения, зависящие от DNS, продолжают стабильно работать.
Оператор добавил вайлдкард запись адреса в вершину каждой затронутой этой проблемой зоны. В результате произошли две вещи:
1. ответственные за эти две зоны серверы больше не выдают ответ «нет имени» для любых возможных имен в этих зонах, и
2. каждое возможное имя, которое до этого изменения не существовало вообще, теперь имеет синтезированную адресную запись, указывающую на «перенаправляющий» сервер оператора зоны.
Последствия этого простого изменения многочисленны и разнообразны. Нижеследующий список не является исчерпывающим:
посмотр веб-страниц
По всему миру веб-браузеры перестали отвечать «страница не найдена» на локальном языке и кодировке при вводе пользователями неправильных URL. Вместо этого браузеры теперь показывают поисковую страницу с сервера оператора зоны на английском языке.
Необходимо отметить, что языковые тэги в протоколе HTTP не всегда соответствуют языку, используемому локальным браузером. Таким образом, даже если глобальная поисковая страница является динамической и использует информацию в HTTP-запросе для определения нужного языка и скрипта, она все равно не сможет эмулировать то, что ожидал пользователь. Короче говоря, в протоколе HTTP недостаточно нужной информации для того, чтобы поисковый движок мог правильно генерировать поисковую страницу.
В большинстве случаев браузеры написаны таким образом, чтобы при неудаче запроса DNS помочь пользователю на его родном языке и с соблюдением различных местных традиций, соглашений и т.д. Теперь все подобные системы отключены, так как запрос к DNS никогда не бывает неудачным.
Даже если, несмотря на то, что подобный механизм плохо масштабируется, оператор вложит существенные ресурсы в конфигурирование сервера, пользователь все равно будет испытывать неудобства, получив сообщение «attempting to connect» и последующее ожидание вместо простого вывода на экран сообщения об ошибке.
электронная почта
Вся почта с несуществующими именами хостов теперь стекается к серверу оператора, где и происходит ее отброс. Некоторые операторы считают это неприемлемым и поэтому изменили конфигурацию своих почтовых систем для обхода «службы отброса», но абсолютное большинство почтовых серверов продолжают маршрутизировать почту для несуществующих имен на «отбрасывающий» сервер вместо того, чтобы уничтожить эти письма самостоятельно. В данном случае есть несколько нюансов:
— если операторы разрешают неправильной почте идти на «отбрасывающий» сервер, то у них наблюдается увеличенная почтовая нагрузка из-за маршрутизации почты на «отбрасывающий» сервер; если же операторы решили предотвратить подобную ситуацию, то им приходится тратить много сил на конфигурирование серверов;
— операторы, разрешающие почте идти на «отбрасывающий» сервер, теперь зависят от производительности этого сервера. Если «отбрасывающий» сервер медленный или с ним случается сбой, то почта, которую необходимо отбросить, заполняет очереди на SMTP узле. Из-за этого почта вместо того, чтобы вернуться к пользователю стоит в очереди. То есть, опечатки пользователя, которые раньше обнаружились бы сразу же, теперь могут быть не обнаружены в течение нескольких дней;
— операторы, разрешившие почте идти к «отбрасывающему» серверу, теперь также зависят от его работы. Если сервер начнет сбоить и, например, случится его перезагрузка или переполнение, то почта вообще может не вернуться пользователю, и он будет находиться в полной уверенности, что она дошла до получателя, хотя она исчезнет без следа.
В некоторых случаях, при наличии в наборе MX-записей, ассоциированных с обычным DNS-именем, записи, указывающей на несуществующий хост, добавление вайлдкард станет последней каплей, после которой хоть и неправильно сконфигурированная, но нормально работающая почтовая система развалится, так как несуществующее имя не выдаст ошибки.
Нормальный поток информации от клиента к SMTP-серверу, когда адрес имеет опечатку, следующий:
1. Клиент ищет IP-адрес исходящего SMTP-прокси /* здесь и далее под прокси понимается SMTP-сервер, на который пользователь обычно сбрасывает почту и который прописан у него в почтовом клиенте — прим. ред. */ в DNS.
2. Клиент открывает TCP-соединение с исходящим SMTP-прокси.
3. Клиент отправляет информацию о себе прокси.
4. Прокси решает, дать доступ или не дать.
5. Клиент отправляет информацию о получателе SMTP-прокси.
6. Прокси ищет в DNS конечный адрес и получает в ответ «нет имени».
7. Прокси отправляет клиенту информацию о том, что адрес неправильный.
При наличии вайлдкард, в данном случае произойдет следующее:
1. Клиент узнает IP-адрес исходящего SMTP-прокси в DNS.
2. Клиент открывает TCP-соединение с прокси.
3. Клиент посылает прокси информацию о себе.
4. Прокси решает, дать доступ или не дать.
5. Клиент отсылает информацию о получателе прокси.
6. Прокси ищет получателя в DNS и получает успешный ответ.
7. Прокси считает, что с сообщением все в порядке и закрывает соединение с клиентом.
8. Прокси открывает TCP соединение с «отбрасывающим» сервером.
9. «Отбрасывающий» сервер отвечает, что адрес получателя неправильный.
10. Прокси генерирует сообщение об ошибке, которое отсылается обратно отправителю.
Действия идут по другому сценарию, если SMTP-клиент был сконфигурирован с неправильным именем исходящего SMTP-прокси. Так как имя домена разрешается с использованием вайлдкард, клиент подключится к «отбрасывающему» серверу и начнет передавать почту ему. В результате «отбрасывающий» сервер (по IP-адресу вайлдкард) скажет, что адрес получателя неправильный, даже если фактически он указан верно. Сообщение об ошибке, отправленное пользователю, будет говорить не о неправильном адресе исходящего прокси, а о неправильном адресе получателя.
информирование пользователей об ошибках
Многие приложения проверяют имена доменов, прежде чем допустить к следующему шагу. В качестве примера можно привести почтовых клиентов, которые перед отправкой сообщения проверяют, разрешается ли домен в e-mail адресе или конфигурационные утилиты сетевых принтеров, проверяющие правильность ввода имени спулера перед принятием конфигурации. Раньше пользователи практически сразу получили бы сообщения о том, что ими допущены ошибки в имени домена. Теперь же, в случае электронной почты, ошибка не может быть опознана прямо во время отправки, а только после того, как сервер отбросит почту. В случае с настройкой принтера, ошибка не может быть замечена во время настройки, а только после того, как принтер откажется работать.
фильтры спама
Установка записей с вайлдкардами нарушила функционирование нескольких простых фильтров спама, используемых на входе почтовых серверов и также более сложных фильтров, проверяющих существование отправляющего домена для отброса несуществующих отправителей. Хотя такая техника рассылки спама и потеряла популярность благодаря подобным фильтрам, но некоторые операторы сообщают, что ее доля все еще составляет около 10%. Провайдеры могут усовершенствовать свои фильтры, добавив в них какие-то правила, например, проверки адреса, выдаваемого вайлдкард записями, однако подобные мероприятия не дешевы и увеличивают время работы фильтрующих программ.
взаимодействие с другими протоколами
Записи вайлдкард перехватывают запросы для сервисов, но в Интернете используется довольно много частных протоколов, с незарегистрированными в IANA портами. Количество сервисов таково, что для оператора зоны не представляется возможным создать и поддерживать работу перенаправляющего сервиса для каждого протокола. В нашем примере оператор зоны предоставил перенаправляющие сервисы только для HTTP (который перенаправляется на поисковую страницу) и на SMTP (который обрабатывается и отбрасывается). Все другие протоколы в лучшем случае получат «сброс» TCP, а, скорее всего, их пакеты просто потеряются. Любое приложение, использующее DNS, так или иначе обрабатывающее ответ «нет имени» и выдающее пользователю соответствующее предупреждение, теперь не может обнаружить, что введенное DNS-имя неправильное. Т.е. неправильное имя, попавшее под действие вайлдкард, не вызовет вообще никаких ошибок DNS. Вместо этого возникнут всяческие мистические ошибки вроде невозможности установить соединение или же недоступного направления в случае, если оператор зоны не установит для сервиса перенаправляющую систему. В некоторых случаях это может заставить приложение определить сбой не как «тяжелый», а как «легкий» и попытаться установить связь заново, как показано на примере электронной почты. Это может привести к очень большим задержкам (недели) прежде чем самые простые ошибки будут обнаружены пользователем. Транспортные протоколы, использующие UDP, также могут ждать до тех пор, пока не будет достигнуто максимально допустимое количество повторных попыток (особенно если ICMP сообщения блокируются файрволлом), что существенно больше, чем время, необходимое для сообщения пользователю об ошибке в адресе.
автоматические системы
Автоматические или встроенные системы, использующие HTTP, но не имеющие пользовательского интерфейса также могут «смутиться» от произведенных изменений, так как в случае какой-либо ошибки, они, не подозревая о ней и о том, что полученный HTTP-ответ идет от поисковой страницы оператора, будут пытаться подключится к ожидаемой ими странице. Такие системы могут теперь выдавать совершенно непредсказуемые сбои, и могут оказаться трудномодернизируемыми.
лишний трафик
Текущий ответ от сервиса занимает около 17 кб из-за того, что клиенту приходится открыть TCP-соединение и получить немалый объем данных. Ответ «нет информации» уложился бы в один пакет. В случае большого количества подобных «лишних» данных, клиенту придется платить лишние деньги.
снижение отказоустойчивости
Даже если перенаправляющий сервис будет работать так, как задумано, подобный сервис создает централизованную точку, от которой зависит функционирование всей системы, а, следовательно, снижается отказоустойчивость. Подобные точки могут стать лакомым кусочком для разного рода атак, начиная от настоящих и заканчивая «атаками», вызванными различными багами и ошибками конфигурации. Более того, IP-адрес, ассоциированный с такой точкой, также является привлекательным еще и для маршрутизационных атак, перенаправляющих IP-адрес на какой-либо другой сервер.
конфиденциальность
Перенаправляющий сервис серьезно нарушает принципы конфиденциальности, так как получаемый им трафик, очень интересный по определению, не идет туда, куда его задумывал направить пользователь. Опасность несанкционированного его использования в данном случае очень высока, так как сервис перехвата может привлечь внимание разного рода несознательных личностей.
зарезервированные имена
Подобный способ применения вайлдкард также несовместим и с любыми разновидностями использования DNS, имеющими отношение к резервированию имен путем их регистрации без добавления к самой зоне. В качестве примера можно привести подход к резервированию имен без регистрации в DNS, который основывается на том, что имена могут быть зарегистрированы только владельцем имени. Для того чтобы не «пугать» пользователей, подобные имена не должны вообще разрешаться (не в смысле «нельзя», а в смысле разрешения (resolve) имен в DNS). Этот подход абсолютно не совместим с рассматриваемым использованием вайлдкард, так как вайлдкард всегда будет возвращать ответ.
нежелательные затраты
Большинство провайдеров отреагировало на внедрение вайлдкард различными действиями. Некоторые из них модифицировали свои системы маршрутизации таким образом, чтобы пакеты, направленные перенаправляющему серверу оператора зоны отбрасывались в «черную дыру». Некоторые пропатчили DNS с целью обратить действие вайлдкард. Некоторые решили воспользоваться случаем и сыграть в ту же игру, что и оператор зоны, но по своим правилам. Все эти действия понятны и объяснимы, но ни одно из них не является хорошим. Самым плохим, пожалуй, является то, что разные провайдеры применили разные способы для решения проблемы, что может доставить лишнюю головную боль любому, кто столкнется с кросс-сетевым DNS и отладкой приложений.
принципы, выводы и рекомендации
Принцип обеспечения надежности говорит нам, что некоторые проблемы, описанные выше, могут быть истолкованы как причины ошибок. В качестве примера можно привести хотя бы фильтры спама.
Принцип снижения непредсказуемости: внедрение вайлдкард имело разрушительные и непредсказуемые последствия для многих пользователей.
Следует особо отметить то, что хоть вайлдкарды и являются частью протокола DNS, тем не менее, их необдуманное применение может иметь весьма печальные последствия. Как уже было отмечено выше, два ключевых момента внедрения вайлдкард следующие:
1. влияние на более чем один протокол;
2. их влияние распространилось по иерархии DNS, т.е. вышло из-под контроля организации, осуществившей внедрение.
Также следует отметить, что возникшие неполадки сами по себе не являлись непосредственно следствием внедрения вайлдкард. Они являлись следствиями изменения устоявшегося и обкатанного механизма.
В завершение можно привести рекомендацию, определяющую применение вайлдкард слишком рискованным.
Итак, рекомендация следующая: если вы хотите использовать вайлдкарды в вашей зоне и понимаете возможные риски, делайте это только с согласия объектов, делегированных в вашей зоне.
Основное правило, которое рекомендуется соблюдать — не применять вайлдкарды в случаях, когда они могут повлиять на более чем один протокол. В настоящее время, единственный тип записей, удовлетворяющий такой рекомендации — MX-записи.
Для делегирующих зон не рекомендуется использовать даже вайлдкарды MX-записей. Если их применения не избежать, то необходимо провести согласование со всеми остальными владельцами делегированных зон. Другими словами, оператор родительской зоны не должен перемаршрутизировать почту, направленную к дочерней зоне без разрешения дочерней зоны.
Конечно, полностью запрещать использование вайлдкард в зонах «реестрового» класса не стоит, однако следует еще раз напомнить, что вся ответственность по обеспечению безвредности вайлдкард и обеспечения отсутствия их влияния на стабильную работу DNS и предсказуемость работы приложений ложится на оператора «реестровой» зоны.
Итак, ICANN рекомендует всем доменам верхнего уровня, использующим вайлдкарды и нарушающим вышеописанные принципы и рекомендации, как можно быстрее убрать их.
timeline скандала
21 сентября VeriSign ответила президенту ICANN, что приняла к сведению доводы ICANN, но пока что отказывается отключить сервис до тех пор, пока не будет собрана и проанализирована информация.
22 сентября комиссией по безопасности и стабильности (security and stability advisory committee) был опубликован отчет по возникшей ситуации. В нем были еще раз отмечены проблемы, описанные выше, и сделаны следующие выводы:
Изменения, внесенные VeriSign, существенно снизили стабильность Интернет, вызвали некорректное поведение DNS, и, что самое плохое, стали причиной цепной реакции различных контр мер различных провайдеров, что внесло еще большую нестабильность в систему.
Изменения также повлияли на большое число существующих сервисов, зависящих от точной и стабильной работы DNS:
— возникли многочисленные незначительные ошибки конфигурации email стали фатальными после внедрения вайлдкард;
службы защиты от спама, зависящие от ответа RCODE 3 (при несуществующем отправителе) теперь не могут корректно функционировать;
в некоторых средах запросы к DNS выполняются поочередно: если один из сервисов не разрешается в DNS, приложение переходит к следующему сервису для поиска нужной информации. После внесения изменений, разрешение DNS никогда не бывает неудачным и нужная информация не получается.
После анализа последствий внедрения вайлдкард, комиссия по безопасности и стабильности предложила VeriSign добровольно отключить этот сервис.
Кроме проблем чисто технического плана, VeriSign столкнулась еще и с проблемами юридического характера. Причины, думаю, очевидны. Одна из них — нарушение правила регистрации доменов, из которого вытекает, что VeriSign не имеет права выдавать какую-то свою страницу на не существующие и не принадлежащие ей домены.
Итак, после долгих споров с остальным интернет-сообществом, 5 октября VeriSign все-таки согласилась временно приостановить действие злосчастного сервиса.
что же дальше?
Ключевым словом в прошлом абзаце является «временно». Будем, конечно, надеяться, что нет ничего более постоянного, чем временное, но все же. Что делать админам в случае, если VeriSign, несмотря на общественный протест, опять запустит «Site Finder»?. Не все потеряно, уже известно довольно много способов решения проблемы. Все необходимое, начиная от теоретических способов решения проблемы, до патчей к самым разным версиям ПО, можно найти по этому адресу: http://www.imperialviolet.org/dnsfix.html.
Дмитрий Герусс
официальный комментарий IAB к использованию DNS-вайлдкард
В работе DNS существует множество особенностей, не документированных в стандартах IETF, но от них зависит поведение протоколов и приложений Интернет. Эти особенности являются неотделимой частью сетевой архитектуры, в которой DNS — один из основных «винтиков».
Способы использования вайлдкард, изменяющие эти особенности, известны уже довольно давно.
Недавнее изменение, связанное с добавлением DNS-вайлдкард с А-записями на высоких уровнях дерева DNS показало на практике, что вмешательство в устоявшиеся принципы работы DNS может иметь весьма серьезные последствия. Дальше речь пойдет о том, как работают вайлдкарды DNS и как их необдуманное использование может ухудшить работу как отдельных приложений, так и всего Интернет в целом.
Вкратце, мы выступаем против применения DNS-вайлдкард оператором зоны до тех пор, пока он не будет иметь четкого представления о возможных рисках.
краткий справочник DNS-вайлдкард
Механизм вайлдкард DNS является частью протокола DNS еще с тех пор, как на него были написаны спецификации более 20-и лет назад. Тем не менее, до сих пор можно встретить ярые дискуссии по поводу того, как он должен реализовываться, и как должен или не должен использоваться. В данном разделе мы попытаемся вкратце объяснить читателю принципы работы механизма вайлдкард, но мы также настоятельно рекомендуем обратиться к спецификациям DNS (RFC 1034).
В общих чертах, вайлдкарды DNS — это правила, позволяющие серверу имен синтезировать записи ресурсов DNS на лету. Основной механизм довольно прост, сложности кроются в реализации деталей.
Как известно, основной и в то же время самой часто используемой операцией является простой запрос на записи, удовлетворяющие данному имени, классу и типу. Если для простоты предположить, что все программное и аппаратное обеспечение работает корректно, то подобный запрос приведет к трем возможным результатам:
— success — если система находит соответствие всем трем параметрам, она вернет нужную информацию;
— no data — если система находит соответствие имени и классу запроса, но не типу, она вернет ответ, что такое имя существует, но не существует никакой информации, соответствующей данному типу;
— no such name — если системе не удается найти соответствие данным имени и типу, она вернет сообщение, информирующее о том, что такого имени не существует.
Как правило, соответствия для всех трех параметров должны быть точными. Вот тут-то в дело вступают вайлдкарды.
Запись вайлдкард является особой записью DNS, в которой левая часть состоит из символа «*», например, «*.bar.example». Концептуально, звездочка обозначает одно или несколько слов с левого (наименее значительного) конца имени DNS.
При наличии записей вайлдкард, правила становятся гораздо более сложными. Например, если совпадает класс запроса, нет точного соответствия имени запроса, и ближайшее соответствие имени запроса является вайлдкардом, система синтезирует набор записей ресурсов, соответствующих имени запроса, на лету, рассматривая записи ресурсов в имени вайлдкард так, как если бы они были представлены в имени запроса. Таким образом, если имя вайлдкарда имеет соответствующие типу запроса записи, система вернет эти записи, точно так же как и в случае «успех» (success), описанном выше; в противном случае, система ответит, что имя существует, но не существует никакой информации, соответствующей данному типу запроса, аналогично случаю «нет информации» (no data). Т.е. ответ будет идентичным нормальному ответу «успех» для имени запроса. В итоге получается, что посылавший запрос не сможет определить по полученным результатам, что это результаты выражения вайлдкард.
Следует отметить, что при соответствии вайлдкард, случай «нет имени» (no such name) не может произойти, так как соответствие вайлдкард сводит вероятность его возникновения к нулю. Заметьте также, что для определения вайлдкард подходят только имя запроса и тип запроса: любой тип записи может соответствовать вайлдкарду, вне зависимости от того, соответствует ли тип записи типу запроса.
проблемы с записями вайлдкард
Одним из широко известных недостатков вайлдкард является то, что записи, содержащие их, плохо сказываются на использовании DNS, зависящем от ответов типа «нет имени». Список подобных применений достаточно велик и будет рассмотрен позже.
Еще одно неудобство вытекает из того, что метка вайлдкард будет соответствовать вообще всему, при условии, что не-вайлдкард имя внутри зоны является более близким соответствием имени запроса, чем вайлдкард. Это не кажется большой проблемой, но дело в том, что многие протоколы или соглашения предусматривают в некоторых случаях использование меток с левых (наименее значительных) концов имен в записях для различения записей, ассоциированных с различными сервисами, вместо использования разных типов записей. То есть, в этих случаях, различные службы используют один и тот же тип записи, а клиенты (или пользователи) должны использовать определенное имя, чтобы получить доступ к необходимой службе. Это относится к системе, описанной в специальных соглашениях (RFC 2219), например, www.foo.example и механизмам вроде типа записи SRV (RFC 2782), в которых схема присваивания имен является частью протокола. Когда имена этого типа закрываются вайлдкардом, как, например, запись адреса, названная, *.bar.example, подобный вайлдкард выдаст одинаковый адрес, несмотря на имя сервиса, закодированное в имени запроса. Так, ftp.foo.bar.example, mail.foo.bar.example, ntp.mail.bar.example будут заканчиваться на одну и ту же синтезированную запись адреса. Эта проблема становится еще серьезней в случае с SRV, так как имена вроде _finger._tcp.foo.bar.example являются частью протокола и также SRV записи содержат номера портов TCP и UDP. То есть клиент не будет знать, к какому хосту подключаться, и, вдобавок, к какому порту. Единственный способ избежать проблем с записями такого типа — это добавить явные записи для подобных имен в DNS.
Наконец, два вышеперечисленных фактора (эффект «соответствие всему» и плохое взаимодействие со всем, зависящим от ответов «нет имени») пересекаются с нормальными предсказуемыми человеческими ошибками, тем самым их действие распространяется далеко за установленные рамки. Точнее говоря, действие вайлдкард ограничено одной зоной, поскольку, по определению, записи вайлдкард не соответствует ни одно имя, реально не существующее в зоне, и, соответственно, не соответствует любое (не вайлдкард) делегирование порции именного пространства от родительской зоны дочерней.(NS-записи вайлдкард, теоретически возможны, но из-за их неестественной семантики их применение лучше ограничить дотошным тестированием DNS-софта). На первый взгляд может показаться, что администратор зоны может спокойно использовать вайлдкарды без беспокойства по поводу возможных эффектов в дочерней зоне. К сожалению, это не так. Дело в том, что пользовательские интерфейсы тесно взаимосвязаны с DNS-именами, а пользователям, как и всем людям свойственно ошибаться. Таким образом, делегирование зоны bar.example предотвратит влияние вайлдкард записи *.example на пользователя, написавшего по ошибке вместо foo.bar.example foi.bar.example, но в то же время не предотвратит, если пользователь напишет foo.bat.example. То есть с точки зрения пользователя, некоторые эффекты вайлдкард передаются от родительской зоны к дочерней. Это не представляет собой серьезной проблемы в случае, если родительская и дочерняя зоны принадлежат одной организации, но может вызвать большие сложности в случае, когда зоны ассоциированы с различными организациями, интересы которых не совпадают.
Описанное выше — это еще не полный список возможных проблем. Даже после двадцати лет опыта работы с DNS, эффекты от неправильного использования вайлдкард могут быть неожиданными, так как небольшие, но фундаментальные изменения, которые они вносят в правила разрешения имен, имеют возможные (а иногда и явные) негативные последствия для уже установленного ПО, использующего DNS.
По этим причинам использование вайлдкард было ограничено небольшим числом случаев, когда их применение полностью осознанно. Так, практически все применение вайлдкард ограничено записями MX. Так как записи MX используются для доставки электронной почты, вайлдкард записи MX довольно безопасны, особенно учитывая тот факт, что, как правило, организация, владеющая DNS-именем электронной почты, также владеет и остальной частью делегируемого дерева, и, тем самым, MX записи находятся в зонах, где эффекты их присутствия не пересекают границ владений разных организаций.
/* В наших реалиях возможен еще вариант использования вайлдкардов в «DNS-зоне для бедных» — когда у вас есть один хост с одним IP-адресом, и все сервисы крутятся на нем. — прим.ред */
Принимая во внимание рассмотренные выше проблемы, можно сделать вывод, что использование вайлдкард с типами записей, влияющими более чем на один протокол, должно производится с большой осторожностью. С еще большей осторожностью следует относиться к случаям, когда эффекты от использования вайлдкард могут пересекать границы владений разных организаций, и уж совсем аккуратно следует относиться к применению вайлдкард, если эффекты от их использования могут влиять на несколько протоколов и пересекать границы владений разных организаций.
базовые принципы архитектуры интернет-сетей
Для чтения дальнейшей части статьи желательно помнить о следующих основных принципах разработки архитектуры, которые служили Интернету в течение многих лет:
Принцип надежности: «Необходимо подходить консервативно к тому, что делаешь и быть либеральным к тому, что предлагают другие».
Принцип наименьшей неожиданности: «Программа всегда должна вести себя таким образом, чтобы быть наиболее предсказуемой для пользователя».
недавно замеченные проблемы с вайлдкардами
Мы имели возможность увидеть нежелательные и труднообъяснимые последствия внедрения вайлдкард в большие домены верхнего уровня. В этом разделе будет рассказано о проблемах, с которыми столкнулись пользователи сети и операторы по всему миру в результате этого внедрения.
В первую очередь необходимо отметить, что с технической точки зрения это было абсолютно законно и не нарушало спецификаций DNS. Тем не менее, мы считаем, что простого соблюдения спецификаций недостаточно, чтобы быть уверенным в том, что приложения, зависящие от DNS, продолжают стабильно работать.
Оператор добавил вайлдкард запись адреса в вершину каждой затронутой этой проблемой зоны. В результате произошли две вещи:
1. ответственные за эти две зоны серверы больше не выдают ответ «нет имени» для любых возможных имен в этих зонах, и
2. каждое возможное имя, которое до этого изменения не существовало вообще, теперь имеет синтезированную адресную запись, указывающую на «перенаправляющий» сервер оператора зоны.
Последствия этого простого изменения многочисленны и разнообразны. Нижеследующий список не является исчерпывающим:
посмотр веб-страниц
По всему миру веб-браузеры перестали отвечать «страница не найдена» на локальном языке и кодировке при вводе пользователями неправильных URL. Вместо этого браузеры теперь показывают поисковую страницу с сервера оператора зоны на английском языке.
Необходимо отметить, что языковые тэги в протоколе HTTP не всегда соответствуют языку, используемому локальным браузером. Таким образом, даже если глобальная поисковая страница является динамической и использует информацию в HTTP-запросе для определения нужного языка и скрипта, она все равно не сможет эмулировать то, что ожидал пользователь. Короче говоря, в протоколе HTTP недостаточно нужной информации для того, чтобы поисковый движок мог правильно генерировать поисковую страницу.
В большинстве случаев браузеры написаны таким образом, чтобы при неудаче запроса DNS помочь пользователю на его родном языке и с соблюдением различных местных традиций, соглашений и т.д. Теперь все подобные системы отключены, так как запрос к DNS никогда не бывает неудачным.
Даже если, несмотря на то, что подобный механизм плохо масштабируется, оператор вложит существенные ресурсы в конфигурирование сервера, пользователь все равно будет испытывать неудобства, получив сообщение «attempting to connect» и последующее ожидание вместо простого вывода на экран сообщения об ошибке.
электронная почта
Вся почта с несуществующими именами хостов теперь стекается к серверу оператора, где и происходит ее отброс. Некоторые операторы считают это неприемлемым и поэтому изменили конфигурацию своих почтовых систем для обхода «службы отброса», но абсолютное большинство почтовых серверов продолжают маршрутизировать почту для несуществующих имен на «отбрасывающий» сервер вместо того, чтобы уничтожить эти письма самостоятельно. В данном случае есть несколько нюансов:
— если операторы разрешают неправильной почте идти на «отбрасывающий» сервер, то у них наблюдается увеличенная почтовая нагрузка из-за маршрутизации почты на «отбрасывающий» сервер; если же операторы решили предотвратить подобную ситуацию, то им приходится тратить много сил на конфигурирование серверов;
— операторы, разрешающие почте идти на «отбрасывающий» сервер, теперь зависят от производительности этого сервера. Если «отбрасывающий» сервер медленный или с ним случается сбой, то почта, которую необходимо отбросить, заполняет очереди на SMTP узле. Из-за этого почта вместо того, чтобы вернуться к пользователю стоит в очереди. То есть, опечатки пользователя, которые раньше обнаружились бы сразу же, теперь могут быть не обнаружены в течение нескольких дней;
— операторы, разрешившие почте идти к «отбрасывающему» серверу, теперь также зависят от его работы. Если сервер начнет сбоить и, например, случится его перезагрузка или переполнение, то почта вообще может не вернуться пользователю, и он будет находиться в полной уверенности, что она дошла до получателя, хотя она исчезнет без следа.
В некоторых случаях, при наличии в наборе MX-записей, ассоциированных с обычным DNS-именем, записи, указывающей на несуществующий хост, добавление вайлдкард станет последней каплей, после которой хоть и неправильно сконфигурированная, но нормально работающая почтовая система развалится, так как несуществующее имя не выдаст ошибки.
Нормальный поток информации от клиента к SMTP-серверу, когда адрес имеет опечатку, следующий:
1. Клиент ищет IP-адрес исходящего SMTP-прокси /* здесь и далее под прокси понимается SMTP-сервер, на который пользователь обычно сбрасывает почту и который прописан у него в почтовом клиенте — прим. ред. */ в DNS.
2. Клиент открывает TCP-соединение с исходящим SMTP-прокси.
3. Клиент отправляет информацию о себе прокси.
4. Прокси решает, дать доступ или не дать.
5. Клиент отправляет информацию о получателе SMTP-прокси.
6. Прокси ищет в DNS конечный адрес и получает в ответ «нет имени».
7. Прокси отправляет клиенту информацию о том, что адрес неправильный.
При наличии вайлдкард, в данном случае произойдет следующее:
1. Клиент узнает IP-адрес исходящего SMTP-прокси в DNS.
2. Клиент открывает TCP-соединение с прокси.
3. Клиент посылает прокси информацию о себе.
4. Прокси решает, дать доступ или не дать.
5. Клиент отсылает информацию о получателе прокси.
6. Прокси ищет получателя в DNS и получает успешный ответ.
7. Прокси считает, что с сообщением все в порядке и закрывает соединение с клиентом.
8. Прокси открывает TCP соединение с «отбрасывающим» сервером.
9. «Отбрасывающий» сервер отвечает, что адрес получателя неправильный.
10. Прокси генерирует сообщение об ошибке, которое отсылается обратно отправителю.
Действия идут по другому сценарию, если SMTP-клиент был сконфигурирован с неправильным именем исходящего SMTP-прокси. Так как имя домена разрешается с использованием вайлдкард, клиент подключится к «отбрасывающему» серверу и начнет передавать почту ему. В результате «отбрасывающий» сервер (по IP-адресу вайлдкард) скажет, что адрес получателя неправильный, даже если фактически он указан верно. Сообщение об ошибке, отправленное пользователю, будет говорить не о неправильном адресе исходящего прокси, а о неправильном адресе получателя.
информирование пользователей об ошибках
Многие приложения проверяют имена доменов, прежде чем допустить к следующему шагу. В качестве примера можно привести почтовых клиентов, которые перед отправкой сообщения проверяют, разрешается ли домен в e-mail адресе или конфигурационные утилиты сетевых принтеров, проверяющие правильность ввода имени спулера перед принятием конфигурации. Раньше пользователи практически сразу получили бы сообщения о том, что ими допущены ошибки в имени домена. Теперь же, в случае электронной почты, ошибка не может быть опознана прямо во время отправки, а только после того, как сервер отбросит почту. В случае с настройкой принтера, ошибка не может быть замечена во время настройки, а только после того, как принтер откажется работать.
фильтры спама
Установка записей с вайлдкардами нарушила функционирование нескольких простых фильтров спама, используемых на входе почтовых серверов и также более сложных фильтров, проверяющих существование отправляющего домена для отброса несуществующих отправителей. Хотя такая техника рассылки спама и потеряла популярность благодаря подобным фильтрам, но некоторые операторы сообщают, что ее доля все еще составляет около 10%. Провайдеры могут усовершенствовать свои фильтры, добавив в них какие-то правила, например, проверки адреса, выдаваемого вайлдкард записями, однако подобные мероприятия не дешевы и увеличивают время работы фильтрующих программ.
взаимодействие с другими протоколами
Записи вайлдкард перехватывают запросы для сервисов, но в Интернете используется довольно много частных протоколов, с незарегистрированными в IANA портами. Количество сервисов таково, что для оператора зоны не представляется возможным создать и поддерживать работу перенаправляющего сервиса для каждого протокола. В нашем примере оператор зоны предоставил перенаправляющие сервисы только для HTTP (который перенаправляется на поисковую страницу) и на SMTP (который обрабатывается и отбрасывается). Все другие протоколы в лучшем случае получат «сброс» TCP, а, скорее всего, их пакеты просто потеряются. Любое приложение, использующее DNS, так или иначе обрабатывающее ответ «нет имени» и выдающее пользователю соответствующее предупреждение, теперь не может обнаружить, что введенное DNS-имя неправильное. Т.е. неправильное имя, попавшее под действие вайлдкард, не вызовет вообще никаких ошибок DNS. Вместо этого возникнут всяческие мистические ошибки вроде невозможности установить соединение или же недоступного направления в случае, если оператор зоны не установит для сервиса перенаправляющую систему. В некоторых случаях это может заставить приложение определить сбой не как «тяжелый», а как «легкий» и попытаться установить связь заново, как показано на примере электронной почты. Это может привести к очень большим задержкам (недели) прежде чем самые простые ошибки будут обнаружены пользователем. Транспортные протоколы, использующие UDP, также могут ждать до тех пор, пока не будет достигнуто максимально допустимое количество повторных попыток (особенно если ICMP сообщения блокируются файрволлом), что существенно больше, чем время, необходимое для сообщения пользователю об ошибке в адресе.
автоматические системы
Автоматические или встроенные системы, использующие HTTP, но не имеющие пользовательского интерфейса также могут «смутиться» от произведенных изменений, так как в случае какой-либо ошибки, они, не подозревая о ней и о том, что полученный HTTP-ответ идет от поисковой страницы оператора, будут пытаться подключится к ожидаемой ими странице. Такие системы могут теперь выдавать совершенно непредсказуемые сбои, и могут оказаться трудномодернизируемыми.
лишний трафик
Текущий ответ от сервиса занимает около 17 кб из-за того, что клиенту приходится открыть TCP-соединение и получить немалый объем данных. Ответ «нет информации» уложился бы в один пакет. В случае большого количества подобных «лишних» данных, клиенту придется платить лишние деньги.
снижение отказоустойчивости
Даже если перенаправляющий сервис будет работать так, как задумано, подобный сервис создает централизованную точку, от которой зависит функционирование всей системы, а, следовательно, снижается отказоустойчивость. Подобные точки могут стать лакомым кусочком для разного рода атак, начиная от настоящих и заканчивая «атаками», вызванными различными багами и ошибками конфигурации. Более того, IP-адрес, ассоциированный с такой точкой, также является привлекательным еще и для маршрутизационных атак, перенаправляющих IP-адрес на какой-либо другой сервер.
конфиденциальность
Перенаправляющий сервис серьезно нарушает принципы конфиденциальности, так как получаемый им трафик, очень интересный по определению, не идет туда, куда его задумывал направить пользователь. Опасность несанкционированного его использования в данном случае очень высока, так как сервис перехвата может привлечь внимание разного рода несознательных личностей.
зарезервированные имена
Подобный способ применения вайлдкард также несовместим и с любыми разновидностями использования DNS, имеющими отношение к резервированию имен путем их регистрации без добавления к самой зоне. В качестве примера можно привести подход к резервированию имен без регистрации в DNS, который основывается на том, что имена могут быть зарегистрированы только владельцем имени. Для того чтобы не «пугать» пользователей, подобные имена не должны вообще разрешаться (не в смысле «нельзя», а в смысле разрешения (resolve) имен в DNS). Этот подход абсолютно не совместим с рассматриваемым использованием вайлдкард, так как вайлдкард всегда будет возвращать ответ.
нежелательные затраты
Большинство провайдеров отреагировало на внедрение вайлдкард различными действиями. Некоторые из них модифицировали свои системы маршрутизации таким образом, чтобы пакеты, направленные перенаправляющему серверу оператора зоны отбрасывались в «черную дыру». Некоторые пропатчили DNS с целью обратить действие вайлдкард. Некоторые решили воспользоваться случаем и сыграть в ту же игру, что и оператор зоны, но по своим правилам. Все эти действия понятны и объяснимы, но ни одно из них не является хорошим. Самым плохим, пожалуй, является то, что разные провайдеры применили разные способы для решения проблемы, что может доставить лишнюю головную боль любому, кто столкнется с кросс-сетевым DNS и отладкой приложений.
принципы, выводы и рекомендации
Принцип обеспечения надежности говорит нам, что некоторые проблемы, описанные выше, могут быть истолкованы как причины ошибок. В качестве примера можно привести хотя бы фильтры спама.
Принцип снижения непредсказуемости: внедрение вайлдкард имело разрушительные и непредсказуемые последствия для многих пользователей.
Следует особо отметить то, что хоть вайлдкарды и являются частью протокола DNS, тем не менее, их необдуманное применение может иметь весьма печальные последствия. Как уже было отмечено выше, два ключевых момента внедрения вайлдкард следующие:
1. влияние на более чем один протокол;
2. их влияние распространилось по иерархии DNS, т.е. вышло из-под контроля организации, осуществившей внедрение.
Также следует отметить, что возникшие неполадки сами по себе не являлись непосредственно следствием внедрения вайлдкард. Они являлись следствиями изменения устоявшегося и обкатанного механизма.
В завершение можно привести рекомендацию, определяющую применение вайлдкард слишком рискованным.
Итак, рекомендация следующая: если вы хотите использовать вайлдкарды в вашей зоне и понимаете возможные риски, делайте это только с согласия объектов, делегированных в вашей зоне.
Основное правило, которое рекомендуется соблюдать — не применять вайлдкарды в случаях, когда они могут повлиять на более чем один протокол. В настоящее время, единственный тип записей, удовлетворяющий такой рекомендации — MX-записи.
Для делегирующих зон не рекомендуется использовать даже вайлдкарды MX-записей. Если их применения не избежать, то необходимо провести согласование со всеми остальными владельцами делегированных зон. Другими словами, оператор родительской зоны не должен перемаршрутизировать почту, направленную к дочерней зоне без разрешения дочерней зоны.
Конечно, полностью запрещать использование вайлдкард в зонах «реестрового» класса не стоит, однако следует еще раз напомнить, что вся ответственность по обеспечению безвредности вайлдкард и обеспечения отсутствия их влияния на стабильную работу DNS и предсказуемость работы приложений ложится на оператора «реестровой» зоны.
Итак, ICANN рекомендует всем доменам верхнего уровня, использующим вайлдкарды и нарушающим вышеописанные принципы и рекомендации, как можно быстрее убрать их.
timeline скандала
21 сентября VeriSign ответила президенту ICANN, что приняла к сведению доводы ICANN, но пока что отказывается отключить сервис до тех пор, пока не будет собрана и проанализирована информация.
22 сентября комиссией по безопасности и стабильности (security and stability advisory committee) был опубликован отчет по возникшей ситуации. В нем были еще раз отмечены проблемы, описанные выше, и сделаны следующие выводы:
Изменения, внесенные VeriSign, существенно снизили стабильность Интернет, вызвали некорректное поведение DNS, и, что самое плохое, стали причиной цепной реакции различных контр мер различных провайдеров, что внесло еще большую нестабильность в систему.
Изменения также повлияли на большое число существующих сервисов, зависящих от точной и стабильной работы DNS:
— возникли многочисленные незначительные ошибки конфигурации email стали фатальными после внедрения вайлдкард;
службы защиты от спама, зависящие от ответа RCODE 3 (при несуществующем отправителе) теперь не могут корректно функционировать;
в некоторых средах запросы к DNS выполняются поочередно: если один из сервисов не разрешается в DNS, приложение переходит к следующему сервису для поиска нужной информации. После внесения изменений, разрешение DNS никогда не бывает неудачным и нужная информация не получается.
После анализа последствий внедрения вайлдкард, комиссия по безопасности и стабильности предложила VeriSign добровольно отключить этот сервис.
Кроме проблем чисто технического плана, VeriSign столкнулась еще и с проблемами юридического характера. Причины, думаю, очевидны. Одна из них — нарушение правила регистрации доменов, из которого вытекает, что VeriSign не имеет права выдавать какую-то свою страницу на не существующие и не принадлежащие ей домены.
Итак, после долгих споров с остальным интернет-сообществом, 5 октября VeriSign все-таки согласилась временно приостановить действие злосчастного сервиса.
что же дальше?
Ключевым словом в прошлом абзаце является «временно». Будем, конечно, надеяться, что нет ничего более постоянного, чем временное, но все же. Что делать админам в случае, если VeriSign, несмотря на общественный протест, опять запустит «Site Finder»?. Не все потеряно, уже известно довольно много способов решения проблемы. Все необходимое, начиная от теоретических способов решения проблемы, до патчей к самым разным версиям ПО, можно найти по этому адресу: http://www.imperialviolet.org/dnsfix.html.
Дмитрий Герусс
Сетевые решения. Статья была опубликована в номере 10 за 2003 год в рубрике мнение
